Boot broken with initramfs-tools 0.103ubuntu0.5b1 - wait-for-root doesn't wait

[Jean-Louis Dupond]

Hi

Today I upgraded udev and initramfs-tools to version 0.103ubuntu0.5b1.

The update of initramfs-tools seems to cause boot issues.
As it doesn't wait long enough for /dev/by-uuid/ to come available, the boot cannot be completed.
You get dropped into initramfs busybox.

If you exit the busybox after some seconds, the system boots normally.

Downgrading initramfs-tools fixes the issue.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Harry (harry33)]

The newest update to initramfs-tools, version 0.103ubuntu0.6 did not help.
Still dropping to busybox.
Commanding "exit" helps.

[Martin Pitt (pitti)]

I run raring-proposed as well, and I cannot replicate this. But this does ring a bell. We got similar reports with earlier libudev0 versions as well, and eventually reverted an upstream commit:

http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu/quantal/udev/ubuntu/view/head:/debian/patches/libudev-revert-SOCK_NONBLOCK.patch

Unfortunately this never got debugged properly, as I never got access to a machine which exhibits this behaviour. Also, this works just fine on Debian, Fedora, Arch, and other distros, so I guess we have some bug in our initramfs-tools/upstart interaction which is exhibited by using a nonblocking socket. For now I'll apply that patch to libudev1.

[Martin Pitt (pitti)]

As for the actual culprit, there are not that many things in the initramfs which use libudev1; most of them are from cryptsetup, but the most likely one is sbin/wait-for-root. This also has ubuntu specific modifications, so it's very likely that this doesn't get along with SOCK_NONBLOCK.

[Martin Pitt (pitti)]

Ah, I got it. The documentation of udev_monitor_receive_device() says

  "The monitor socket is by default set to NONBLOCK. A variant of poll() on the file descriptor returned by udev_monitor_get_fd() should to be used to wake up when new devices arrive, or alternatively the file descriptor switched into blocking mode."

However, wait-for-root does

        while ((udev_device = udev_monitor_receive_device (udev_monitor)) != NULL) {

and then just exits. So switching the socket to blocking is indeed the right answer here.

[Martin Pitt (pitti)]

I went through http://codesearch.debian.net/search?q=udev_monitor_receive_device and checked other users of this, and they are all ok (they all call this from a callback). So let's fix this in wait-for-root, and get rid of this Ubuntu specific ABI change.

[Harry (harry33)]

Martin Pitt wrote:
"... but the most likely one is sbin/wait-for-root."

Exactly this is the issue.
The error message I get before dropping to busybox shell is
Gave up waiting for root.
And then I get the Alert that the root UUID does not exist.

[Martin Pitt (pitti)]

I uploaded a fix to raring-proposed:

initramfs-tools (0.103ubuntu0.7) raring; urgency=low

  * src/wait-for-root.c: Set udev monitor socket to blocking, as we want to
    wait for events. (LP: #1154813)

 -- Martin Pitt <email address hidden> Thu, 14 Mar 2013 07:08:06 +0100

I close the bug as this only affects raring-proposed, not raring. Jean-Louis, I'd be grateful if you could confirm that this works properly for you now?

Thanks, and sorry for the hassle!

[Jean-Louis Dupond (dupondje)]

Just tested this, and it seems to work fine.

Thanks for the fix!

[Robbie Williamson (robbiew)]

I can also confirm that the latest initramfs-tools fixes the problem for me.