root on LVM broken since latest udev 136-2

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.

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.

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

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

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

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

LVM2 needs to be updated.

Fix Released with lvm2 2.02.39-0ubuntu5

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

/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.

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.

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

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.

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.

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.