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

Bug #1154813 reported by Jean-Louis Dupond on 2013-03-13
32
This bug affects 5 people
Affects Status Importance Assigned to Milestone
initramfs-tools (Ubuntu)
Critical
Martin Pitt
systemd (Ubuntu)
Critical
Unassigned

Bug Description

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) wrote :

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

Changed in initramfs-tools (Ubuntu):
status: New → Confirmed
Steve Langasek (vorlon) on 2013-03-14
Changed in initramfs-tools (Ubuntu):
importance: Undecided → Critical
Harry (harry33) wrote :

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

Martin Pitt (pitti) on 2013-03-14
Changed in initramfs-tools (Ubuntu):
assignee: nobody → Martin Pitt (pitti)
Martin Pitt (pitti) wrote :

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.

affects: initramfs-tools (Ubuntu) → systemd (Ubuntu)
Changed in systemd (Ubuntu):
status: Confirmed → In Progress
Martin Pitt (pitti) wrote :

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) wrote :

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.

Changed in initramfs-tools (Ubuntu):
assignee: nobody → Martin Pitt (pitti)
importance: Undecided → Critical
status: New → In Progress
Martin Pitt (pitti) wrote :

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.

Changed in systemd (Ubuntu):
status: In Progress → Invalid
Harry (harry33) wrote :

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) on 2013-03-14
summary: - Boot broken with initramfs-tools 0.103ubuntu0.5b1
+ Boot broken with initramfs-tools 0.103ubuntu0.5b1 - wait-for-root
+ doesn't wait
Changed in systemd (Ubuntu):
assignee: Martin Pitt (pitti) → nobody
Martin Pitt (pitti) wrote :

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!

Changed in initramfs-tools (Ubuntu):
status: In Progress → Fix Released
Jean-Louis Dupond (dupondje) wrote :

Just tested this, and it seems to work fine.

Thanks for the fix!

Robbie Williamson (robbiew) wrote :

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

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers