Comment 7 for bug 802626

In my opinion, there is a fundamental problem wrt interworking between udev and lvm during the init phase. Looking at scripts and source code I found nothing which prevents the following to happen:

1) kernel boots with initial ramdisk
2) udevd of initial ramdisk is started by initrd.img/scripts/init-top/udev
3) udevd handles the initial events of the block devices (partitions) produced by "udevadm trigger --action=add ..." invoked by "initrd.img/scripts/init-top/udev". Please note that this is executed in the background using "&".
4) /lib/udev/rules.d/85-lvm2.rules intercepts add events for LVM partitions and issues "watershed sh -c '/sbin/lvm vgscan; /sbin/lvm vgchange -a y'"
5) "lvm vgchange -a y" sends a LV resume request to the device-mapper in the kernel and waits for completition notification by udevd via semaphore
6) initrd.img/scripts/init-bottom/udev gets executed which invokes "udevadm control --exit". After this point, the initrd-udevd is not handling events anymore.
7) kernel delivers the mapper-task-completion-event to udevd which does not handle events anymore, and therefore does not decrement the semaphore
8) having already waited 60 seconds (event_timeout) for "watershed sh -c '/sbin/lvm vgscan; /sbin/lvm vgchange -a y'" to complete, udevd just gives up and continues termination
9) according to udev-173/udev/udevd.c:1631 the remaining queued events (including the semaphore decrement) are discarded by means of "event_queue_cleanup".
10) after termination of udevd "udevadm control --exit" also terminates and the boot process continues

In the end, the rootfs-udevd does not see the semaphore decrement event anymore, so "lvm vgscan -a y" still hangs. Some other bugs like #631795 #797226 #581566 might be related to this timing problem.

Also adding udev to the bug. Please set to invalid if e.g. lvm is required to wait for the logical volume setup to finish in initrd.img/scripts/init-premount/lvm2.