| Summary: | prefdm.service error when installed without X | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Kamil Rytarowski <n54> |
| Component: | RPM Packages | Assignee: | Mageia Bug Squad <bugsquad> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | major | ||
| Priority: | Normal | CC: | davidwhodgins, mageia |
| Version: | Cauldron | ||
| Target Milestone: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Source RPM: | systemd | CVE: | |
| Status comment: | |||
| Bug Depends on: | |||
| Bug Blocks: | 2120, 5184 | ||
| Attachments: | halt time errors - low quality | ||
|
Description
Kamil Rytarowski
2012-03-29 14:00:57 CEST
https://bugs.mageia.org/attachment.cgi?id=1883 boot time errors Created attachment 1884 [details]
halt time errors - low quality
Manuel Hiebel
2012-03-29 15:08:03 CEST
CC:
(none) =>
mageia The problem with halting is not related to prefdm, but LVM. /dev/dm-X are my partitions.
Kamil Rytarowski
2012-04-01 22:34:01 CEST
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 =>
RESOLVED |