Bug 3784 - cauldron fails to boot when system has lvm
Summary: cauldron fails to boot when system has lvm
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: All Linux
Priority: Normal major
Target Milestone: ---
Assignee: Colin Guthrie
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 2120
  Show dependency treegraph
 
Reported: 2011-12-16 14:40 CET by Olivier Thauvin
Modified: 2012-01-12 20:32 CET (History)
1 user (show)

See Also:
Source RPM: systemd
CVE:
Status comment:


Attachments

Description Olivier Thauvin 2011-12-16 14:40:43 CET
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.
Manuel Hiebel 2011-12-16 19:40:18 CET

Blocks: (none) => 2120

Thierry Vignaud 2011-12-16 23:22:15 CET

CC: (none) => thierry.vignaud
Assignee: bugsquad => mageia

Comment 1 Colin Guthrie 2011-12-16 23:52:42 CET
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.
Colin Guthrie 2011-12-16 23:52:51 CET

Status: NEW => ASSIGNED

Comment 2 Olivier Thauvin 2011-12-18 16:11:03 CET
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
Comment 3 Colin Guthrie 2011-12-18 20:50:26 CET
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'.
Comment 4 Colin Guthrie 2011-12-18 21:47:36 CET
For reference, dracut should be forced on everyone now Mwaaa hahahahahaha!
Comment 5 Olivier Thauvin 2011-12-19 05:54:21 CET
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.
Comment 6 Colin Guthrie 2012-01-12 20:32:53 CET
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 => RESOLVED
Resolution: (none) => FIXED


Note You need to log in before you can comment on or make changes to this bug.