Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#30966 - [linux] 3.5.0 sometimes doesn't find root LVM volume at boot

Attached to Project: Arch Linux
Opened by Marti (intgr) - Wednesday, 01 August 2012, 18:44 GMT
Last edited by Tobias Powalowski (tpowa) - Wednesday, 27 February 2013, 14:20 GMT
Task Type Bug Report
Category Packages: Testing
Status Closed
Assigned To Tobias Powalowski (tpowa)
Thomas Bächler (brain0)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 45
Private No


I have an interesting problem on my laptop: about 1 in 3 times during boot, the initrd fails to find the root file system, which is located on LVM. I'm quite sure that this started after upgrading to linux 3.5.0-1

Booting via EFI on Dell Latitude E6410, disks configured in AHCI mode, x86_64, using systemd.
Root FS is not encrypted, but I'm using /etc/crypttab for other file systems
Kernel command line: /vmlinuz-linux root=/dev/mapper/larcvg-larc--root ro quiet

More information here:
This task depends upon

Closed by  Tobias Powalowski (tpowa)
Wednesday, 27 February 2013, 14:20 GMT
Reason for closing:  No response
Comment by Thomas Bächler (brain0) - Wednesday, 01 August 2012, 19:56 GMT Comment by Dave Reisner (falconindy) - Tuesday, 14 August 2012, 15:27 GMT
Does this still exist with 3.5.1?
Comment by Dr Sushanth Somayaji (rksomayaji) - Saturday, 18 August 2012, 08:14 GMT
This is still present in the testing 3.5.2, but didnt find it in 3.5.1, I have the /usr partition on LVM and on booting it goes to kernel panic. Had to downgrade it to 3.4.9 present in core.
Comment by Michael Laß (Bevan) - Tuesday, 28 August 2012, 12:06 GMT
I also can't boot from an LVM root device using kernel 3.5.3.

I found a solution for this in the following thread:

I changed my lvm2 hook as descrtibed in that thread (add 'lvm pvscan' after msg "Activating logical volumes..."). This solved the problem for me.
Comment by Thomas Bächler (brain0) - Tuesday, 28 August 2012, 12:31 GMT
The extra pvscan is unnecessary and we're not going to add it. Unfortunately, nobody has yet provided us with the real cause of the problem or any way to reproduce it, thus we cannot fix it.
Comment by Siot (siot) - Wednesday, 29 August 2012, 15:07 GMT
After the upgrade to kernel 3.5.3 a message says that fsck can't find my root partition during every boot.

The root partition is on lvm above raid and none of my configuration files where changed. Actually runs ok after downgrading to 3.4.9
Comment by Dave Reisner (falconindy) - Wednesday, 29 August 2012, 15:30 GMT
Yes, thanks for reiterating what's already been said multiple times in this bug report. If you have nothing useful to add, there's a vote button you can click.
Comment by Nesser (Decepteiskon) - Wednesday, 29 August 2012, 20:49 GMT
Same as many of you, after the upgrade to the 3.5.3-1 kernel (from 3.4.9-1) i can't boot, i get dropped to a shell waiting for commands, with the message "No volume groups found". The lvmwait=/dev/sdaX (partition of the lvm container) workaround, added to the grub cmd line, worked.
Comment by Thomas Bächler (brain0) - Sunday, 09 September 2012, 09:38 GMT
Okay, is there anyone who can NOT solve this issue with the lvmwait= parameter? I suggested this to a number of people on IRC and elsewhere and it worked for all of them. The last comment here also suggests that this was the problem.

I'd like to close this, because apart from waiting with lvmwait=, I don't see a way to solve this problem.
Comment by Marti (intgr) - Sunday, 09 September 2012, 12:11 GMT
> I don't see a way to solve this problem.

Well how do the other distros do it?
Comment by Thomas Bächler (brain0) - Sunday, 09 September 2012, 12:55 GMT
I guess they don't. The problem only appeared in such an extreme way since 3.5, which nobody else uses.

The problem is, of course, that LVM and device-mapper don't properly work with the Linux hotplug model, something that the udev/systemd people have been complaining about for years, and that the device-mapper people apparently refuse to fix.
Comment by Vítor Ferreira (archimast) - Sunday, 14 October 2012, 01:28 GMT
In the following thread mid-page 2:, there is a patch, which applied to /usr/lib/initcpio/hooks/lvm2 seems to solve the problem indicated in this bug report. It removes a directory test for /etc/lvm before doing lvm vgscan. Apparently, for some unknown (at least to me) reason, /etc/lvm doesn't exist at early boot. This voids the need for the lvmwait workaround.
Comment by Thomas Bächler (brain0) - Sunday, 14 October 2012, 09:14 GMT
If /etc/lvm is missing, then vgchange automatically calls vgscan, so this isn't necessary. As I mentioned many many times, this is a timing issue, and lvmwait is the only proper solution (apart from finally fixing lvm to support proper hotplugging).
Comment by Thomas Bächler (brain0) - Thursday, 01 November 2012, 09:36 GMT
Please try the device-mapper and lvm2 packages from testing. LVM setup is completely different now, please read for details.

In short: Everything should "just work" now.