The boot stop with message: "Starting block device (LVM, RAID)" but it seems to do nothing. After around 30s the system failed claiming wrong it failed to resolve dependencies (/var, /tmp... they are on lvm indeed like /, not /boot). I enter root password, just type "mount -a", then "service network start", and after one or two minutes the system more or less start (X login appear). I think the "network start" just trigger systemd. This is really annoying since a lot of server will be affected by this issue.
Blocks: (none) => 2120
CC: (none) => thierry.vignaudAssignee: bugsquad => mageia
Is this using systemd but with an mkinitrd generated ramdisk? If so, just install dracut and generate a new ramdisk. It's expected that systemd fails with an mkinitrd generated ramdisk as this older tool does not use udev and runs vgchange itself which ultimately makes it impossible for udev to know about it and thus systemd does not get the necessary info about LVM volumes in the udev db. Dracut is more modern and starts udev in the ramdisk so the metadata from LVM volumes is preserved. This was detailed on the mailing list a few months back and I've posted about it recently (in the last couple days) too. Please let me know how you get on.
Status: NEW => ASSIGNED
To solve the issue I had to: - install dracut - run dracut -f - create a group named 'lock'. I think we must switch to dracut in order to switch to systemd as the systemm can't properly boot otherwise. The issue about the group was reported has "no such file or directory". For people having problem with systemd: * Boot with 'nodkmsboot' and '1' to have messages and a shell quickly to the system. * Booting with init instead systemd is possible by removing init=/bin/systemd. Regards
Yes I think we do need to switch to dracut too, that's why I've been working on it so much of late and have said I'll do exactly this on the mailing list :D Did things actually fail hard when you didn't have the lock group? If so then this is something we'll have to resolve in our lockdev package. It's slightly more tricky than it first appears (which is why I've not fixed it yet!): http://lists.freedesktop.org/archives/systemd-devel/2011-March/001823.html https://bugzilla.redhat.com/show_bug.cgi?id=581884 http://pkgs.fedoraproject.org/gitweb/?p=lockdev.git;a=tree;h=refs/heads/master;hb=refs/heads/master It does need to be done at some point tho'.
For reference, dracut should be forced on everyone now Mwaaa hahahahahaha!
Yup, without a group "lock" systemd fail hard. It's impossible to gain control on the computer in runlevel 5. The status message is "no such file or directory", not helping to understand.
OK, the LVM issue itself is solved, so I'll close this bug. The lockdev stuff is still a bug but it's separate. FWIW, I have done several installs where this is not a hard failure, so not sure if that bit of it was a red herring.
Status: ASSIGNED => RESOLVEDResolution: (none) => FIXED