Comment 8 for bug 332270

Greetings,

I also have this problem, and I think I might be able to shed some light on what's going wrong.

I'm running a slightly unusual configuration -- my root filesystem on my ThinkPad is on LVM, as it my home filesystem. Only a small /boot is stored on a conventional DOS partition. When I boot the latest Jaunty with the 138-1 udev updates, the boot stalls -- with constant disk activity -- during the initial udev device discovery stage.

I found that pressing CTRL-ALT-DELETE interrupts this process, but rather than rebooting the machine, causes the initial udev device settling process to abort and the boot sequence to continue.

The constant disk activity is caused by the LVM udev rules constantly firing.

I note from the changelog that udev introduces a new mechanism: it uses inotify to track changes to block devices; this is so that it can keep /dev/by-uuid/* and /dev/by-label/* links up to date.

I hypothesize that the constant disk activity on the (root) LVM filesystem is causing the LVM udev rules to constantly fire, thus resulting in more disk activity... which never (or seldom) stops long enough for the loop to be broken. And because of this loop, the udev settling process never terminates, so the machine is unable to finish booting.

Reverting the use-inotify-to-watch-LVM-volumes addition to udev would probably be a good idea until this can be sorted out. In the mean time, I'm going to see if I can find a binary package to downgrade to...

Cheers,
David