Comment 26 for bug 818177

Quoting Stefan Bader (<email address hidden>):
> This looks quite like it is likely related to /usr/share/initramfs-
> tools/scripts/init-bottom/udev. How things should work is:

This is also where it appears to hang on my systems.

> - we got the initramfs mounted as initial /
> - udev gets started and left running until the real root device node becomes available
> - now udev gets stopped (used to be clubbed to death which caused even more problems) and /dev is tried to be
> moved to <realroot>/dev.
> - <newroot> bcomes /, restart udev, and things should proceed from there
>
> >From the serial console log of comment #18 it looks like things went ok
> until the time udev should stop. There is no error message there but
> somehow it looks like fsck in the new / does not find the uuid link for
> it. Unclear whether maybe the move of /dev did not work, or did the
> previous step resolve the uuid to dev without the symlink? As Adam
> mentioned before, allowing udev to settle helps. So the race is
> somewhere there. Whoever can reproduce this may want to add additional
> echo's to the init-bottom script.

(TBH I don't believe anyone can 'not reproduce it'. It sometimes takes
me 10 boots, but a standard ubuntu server kvm vm with a single primary
partition on virtio occasionally hangs there as well).

I've tried adding echos, but as near as I can tell, adding any echo
before the udevadm control --exit stops the hang. I rebooted 10 times
last night trying to do a 'ps -ef' before it, but that seemed to slow it
down just enough to stop the race.

I've tried (blindly) installing a recompiled udev which keeps handling
inotify events while waiting to exit, but that doesn't seem to be the
problem. It looks as though udevadm control --exit simply is hanging.

Perhaps some debug statements in udevd itself will be more helpful.
(will try)