Comment 6 for bug 613273

This problem seemed to have intensified for me in my test system in Oneiric and we were finally able to track it down to /usr/share/initramfs-tools/scripts/init-bottom/udev. In there the boot process tries to stop udevd and then move all the special filesystems (/dev, /proc, and /sys) over to the new rootfs and finally switching to that before restarting udevd. However udevd is still launching processes to create devnodes at that point. And it seems in some rare cases the pkill (SIGTERM) fails to really kill all of the udevd processes, which leads to situation were the initramfs cannot be completely nuked and that triggers a panic.

In Oneiric udevadm has a way to stop udevd in a more sensible way which also waits until udev actually stopped (udevadm control --exit). Thought this is not possible with the versions of udev in Natty and Maverick. Making udevd at least not starting new processes (udevadm control --stop-exec-queue). Using that before the pkill would prevent a lot of those ugly "workers have been killed" and "/dev/null not found" messages. Unfortunately there still seemed to be a (much smaller) chance to hit the problem where udevd does not stop on SIGTERM.

So I am not sure which path is the better / simpler to implement one. Have the ability of using a --exit backported from newer udev packages or possibly retry the pkill a few times and if that does not remove the udev processes, switch to a more brutal signal before finally giving up... But either way it is not a kernel problem but udev or initramfs-tools side.