Bug 3784

Summary:	cauldron fails to boot when system has lvm
Product:	Mageia	Reporter:	Olivier Thauvin <nanardon>
Component:	RPM Packages	Assignee:	Colin Guthrie <mageia>
Status:	RESOLVED FIXED	QA Contact:
Severity:	major
Priority:	Normal	CC:	thierry.vignaud
Version:	Cauldron
Target Milestone:	---
Hardware:	All
OS:	Linux
Whiteboard:
Source RPM:	systemd	CVE:
Status comment:
Bug Depends on:
Bug Blocks:	2120

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