root on LVM broken since latest udev 136-2

Bug #314879 reported by Luka Renko on 2009-01-07
This bug affects 5 people
Affects Status Importance Assigned to Milestone
devmapper (Ubuntu)
lvm2 (Ubuntu)
mdadm (Ubuntu)
watershed (Ubuntu)

Bug Description

Binary package hint: udev

I have Kubuntu Jaunty installation (based on clean Alpha2 install) and have both / and /home on LVM (+ /boot on /dev/sda1). System is up-to-date.
Today's udev upload has broken the system for me: kernel cannot find root device and I am dropped in BusyBox.

While exploring what could be wrong in initramfs, I have seen that /dev/udev/rules.d is not a directory, but actually a file.
When looking at the content, it matches the content of /etc/udev/rules.d/85-lvm2.rules. It does not get executed, therefore no LVM logical volumes are created.

Workaround for this problem is to execute the following command in BusyBox:

/sbin/lvm vgscan
/sbin/lvm vgchange -a y

This performs proper setup of LVM and the kernel can then boot properly.

P.S. Was not sure if the bug is in udev/lvm2/initramfs-tools package, but I thought udev is most likely as it was changed the last.

Related branches

Luka Renko (lure) on 2009-01-07
Changed in udev:
importance: Undecided → High
Anders Kaseorg (andersk) wrote :

Same here.

The latest udev update moved the default rules from /etc/udev/rules.d to /lib/udev/rules.d, and the initramfs-tools hook no longer creates the ${DESTDIR}/etc/udev/rules.d directory. Hence, the dmsetup and lvm2 hooks end up overwriting ${DESTDIR}/etc/udev/rules.d as a file rather than copying into it as a directory.

I am not sure if this is the only problem, because just adding mkdir ${DESTDIR}/etc/udev/rules.d to the udev hook and regenerating the initrd wasn’t enough to get my system to boot.

Changed in udev:
status: New → Confirmed
Loïc Minier (lool) wrote :

I'm using root on lvm on md.

I fixed the udev.d issue by adding:
# This directory is still used by lvm2 and other hooks
mkdir -p ${DESTDIR}/etc/udev/rules.d

to /usr/share/initramfs-tools/hooks/udev, before the "# Only copy across relevant rules" line.

AIUI, the /usr/share/initramfs-tools/scripts/init-premount/lvm2 file isn't very important anymore as /etc/udev/rules.d/85-lvm2.rules should trigger a "/sbin/lvm vgscan; /sbin/lvm vgchange -a y" whenever a device with a LVM signature appears. It seems this isn't run properly, or at a bad time as if I run these manually the devices appear under /dev/mapper, including the root device.

Loïc Minier (lool) wrote :

/lib/udev/vol_id --type /dev/md1 correctly yields LVM2_member.

Loïc Minier (lool) wrote :

I think udev stopped shipping a couple of conffiles, but these weren't removed on upgrade:
% dpkg-query -W -f='${Conffiles}' udev | grep obsolete
 /etc/udev/rules.d/05-udev-early.rules 01cc7968762a9a6590801ac94f585d44 obsolete
 /etc/udev/rules.d/66-persistent-storage-edd.rules 5dc9376604e2266886c6be1c7a467222 obsolete

Jamie Strandboge (jdstrand) wrote :

I too hit this today. I downgraded to udev 124-12 (after dpkg -r --force-depends watershed) and the initramfs works fine again.

Jamie Strandboge (jdstrand) wrote :

I forgot to mention that I reinstalled watershed after downgrading udev.

LVM2 needs to be updated.

Hew (hew) wrote :

Fix Released with lvm2 2.02.39-0ubuntu5

Changed in lvm2:
status: Confirmed → Fix Released
Loïc Minier (lool) wrote :

Still an issue with lvm2 2.02.39-0ubuntu6, watershed 2, udev 136-2; even after a manual update-initramfs -u.

Changed in lvm2:
status: Fix Released → Triaged
Albert Damen (albrt) wrote :

/lib/udev/rules.d/85-lvm2.rules contains RUN+="watershed sh -c '/sbin/lvm vgscan; /sbin/lvm vgchange -a y'" and
watershed needs /var/run.

Previously /var/run was created in the initramfs by /usr/share/initramfs-tools/hooks/udev.
Now watershed is a separate package, so I added "mkdir -p ${DESTDIR}/var/run" as last line in /usr/share/initramfs-tools/hooks/watershed. After running update-initramfs -u, the next reboot was successful.

Eric Shattow (eshattow) wrote :

Confirmed that adding "mkdir -p ${DESTDIR}/var/run" as last line in /usr/share/initramfs-tools/hooks/watershed allows boot to be successful. I did notice a non-fatal complaint about the lack of /etc/udev/rules.d/ directory.

Loïc Minier (lool) on 2009-01-11
Changed in lvm2:
status: Triaged → Fix Released
Changed in watershed:
status: New → Triaged
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package watershed - 3

watershed (3) jaunty; urgency=low

  * Create default statedir /var/run/watershed in initramfs hook; fixes boot
    with root on LVM; thanks Albert Damen; LP: #314879.
  * Update initramfs in postinst's configure if update-initramfs is available.

 -- Loic Minier <email address hidden> Sun, 11 Jan 2009 14:29:52 +0100

Changed in watershed:
status: Triaged → Fix Released
Changed in mdadm:
status: New → Fix Released
Changed in devmapper:
status: New → Fix Released
Bryan McLellan (btm) wrote :

Currently trying to upgrade intrepid to newer udev packages (for kvm) creates this issue. I've worked around it by also upgrading lvm2 and installing watershed. It'd be slick if the depends were updated in magical places, but I get that nobody is really interested in being able to backport this.

Bob McElrath (bob+ubuntu) wrote :

I hit this bug today (again) in upgrading from a jaunty alpha to the current jaunty. The symptom is:

(1)<mcelrath@tardis:initramfs-tools> sudo update-initramfs -u
update-initramfs: Generating /boot/initrd.img-2.6.28-11-generic
W:copy_exec: Not copying /lib/lvm-200/lvm to $DESTDIR/sbin/lvm, which is already a copy of /sbin/lvm
cpio: ./etc/udev/rules.d/*-lvm.rules: Cannot stat: No such file or directory
update-initramfs: failed for /boot/initrd.img-2.6.28-11-generic

It seems this is caused by a file /usr/share/initramfs-tools/hooks/lvm which was not removed when the lvm package became lvm2 and is controlled by /usr/share/initramfs-tools/hooks/lvm2. The lvm file has a date 2007-02-05 on my system, probably making it 8.04 or earlier. for me.

The lvm2 package should remove this file if it exists.

Loïc Minier (lool) wrote :

Bob, please file a new bug; this bug was fixed and I can confirm it still works for me (root on LVM on MD); you have a different bug.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers