Description of problem: Hi! I'm doing minimal installation (without X Window), and I got double prefdm errors: 1) the first one is at boot time 2) the latter is at halt time How reproducible: Steps to Reproduce: 1. network installation (nonfree iso) 2. minimal installation without X 3. see prefdm errors at boot time 4. see prefdm error at halt time
https://bugs.mageia.org/attachment.cgi?id=1883 boot time errors
Created attachment 1884 [details] halt time errors - low quality
CC: (none) => mageiaBlocks: (none) => 2120Source RPM: (none) => systemd
The problem with halting is not related to prefdm, but LVM. /dev/dm-X are my partitions.
Blocks: (none) => 5184
OK, so this isn't an error per-se. The real error is detecting what the default runlevel should be which is really a problem in the installer. If you don't install X, prefdm should start, fail and then run a failure unit which displays a message about why it failed and then (when you hit a key) switch from graphical.target to multi-user.target (the equiv of switching from runlevel 5 to 3). The network-up thing should be debugged to work out why it's taking so long (it will need someone suffering from this problem to hack the network-up script to debug it a bit...) The microcode issue is covered in another bug #4327 The LVM should be shutdown nicely on reboot.. Not sure why it's not :s Does regenerating the initrd help here? The installer will generate a big, generic initrd whereas if run later it will create a lean, hostonly initrd. If possible keep a backup of the big initrd to test again later :)
(In reply to comment #4) > The LVM should be shutdown nicely on reboot.. Not sure why it's not :s Blind guess - encrypted LVM partition? > Does > regenerating the initrd help here? No. I have installed additionally radeon-firmware (it's regenerating initrd), and the problem is still there.
(In reply to comment #5) > (In reply to comment #4) > > The LVM should be shutdown nicely on reboot.. Not sure why it's not :s > Blind guess - encrypted LVM partition? > And it's trying to umount dm-0 three times... and I can see that there is: dm-1 / (dm-2 swap?) dm-3 /home
Ahh it's encrypted? Interesting. Oh right, I didn't see the clone path on this bug :) Yeah so I'm not sure this particular bug is still needed (as the other issues aside form the LVM are covered elsewhere) If you agree, please close this one at leisure and we can look into the encrypted problem on #5184 FWIW, it will try and unmount in a loop until nothing can be changed and no more unmounts are possible, but lets keep the comments on the other bug specifically for this.
The dm-0 would be the partition that contains the lvm physical volume. My wag is that a lvm vgchange -a n command is being executed before the cryptsetup luksClose, so it fails as the device is busy.
CC: (none) => davidwhodgins
Keep in mind lvm physical volumes can be on an encrypted partition, or encrypted partitions can be on lvm (or both).
Closing for the prefdm part.
Status: NEW => RESOLVEDResolution: (none) => FIXED