ROOTDELAY= causes unnecessary delay in boot

This change was made by a bot.

Does this issue also happen with Xenial or earlier kernels?

I just launched 1 instance of xenial and of trusty with the same user-data, both of these were 'Standard_D1_v2' type. They do not seem to have such bad performance. trusty does not have systemd-analyze, but i've included 'dmesg | grep sda1.*mounted' for each, which shows quite a difference to the point where sda1 is mounted (and then re-mounted rw).

I've also included the initramfs-tools version as xenial and yakkety are actually running the same kernel version. So something else is at play here.

# Trusty

uptime: 49.59 seconds
you launched me at: Mon, 22 Aug 2016 18:24:45 +0000
it is now : Mon, 22 Aug 2016 18:27:08 +0000
kernel booted : Mon, 22 Aug 2016 18:26:19 +0000
launch to kernel boot: 94 seconds
launch to user-data : 143 seconds

$ dmesg | grep sda1.*mounted
[ 3.860600] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null)
[ 6.797368] EXT4-fs (sda1): re-mounted. Opts: discard

$ uname -r
4.4.0-34-generic

$ dpkg-query --show initramfs-tools
initramfs-tools 0.103ubuntu4.4

# xenial
uptime: 47.52 seconds
you launched me at: Mon, 22 Aug 2016 18:23:50 +0000
it is now : Mon, 22 Aug 2016 18:26:34 +0000
kernel booted : Mon, 22 Aug 2016 18:25:47 +0000
launch to kernel boot: 117 seconds
launch to user-data : 164 seconds
$ systemd-analyze
Startup finished in 7.597s (kernel) + 40.875s (userspace) = 48.472s

$ dmesg | grep sda1.*mounted
[ 5.795233] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null)
[ 12.130461] EXT4-fs (sda1): re-mounted. Opts: discard

$ uname -r
4.4.0-34-generic
$ dpkg-query --show initramfs-tools
initramfs-tools 0.122ubuntu8.1

# yakkety
$ dmesg | grep sda1.*mounted[ 305.882955] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null)
[ 306.921043] EXT4-fs (sda1): re-mounted. Opts: discard

$ uname -r
4.4.0-34-generic
$ dpkg-query --show initramfs-tools
initramfs-tools 0.125ubuntu2

I moved this to initramfs-tools. I made the following change, ran 'update-grub' and rebooted. after reboot:
$ dmesg | grep 'sda1.*mou'
[ 5.614279] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null)
[ 6.452427] EXT4-fs (sda1): re-mounted. Opts: discard

$ diff -u /etc/default/grub.d/50-cloudimg-settings.cfg.orig /etc/default/grub.d/50-cloudimg-settings.cfg
--- /etc/default/grub.d/50-cloudimg-settings.cfg.orig 2016-08-22 18:47:12.878049696 +0000
+++ /etc/default/grub.d/50-cloudimg-settings.cfg 2016-08-22 18:47:18.306335571 +0000
@@ -2,7 +2,7 @@
 # CLOUD_IMG: This file was created/modified by the Cloud Image build process

 # Set the default commandline
-GRUB_CMDLINE_LINUX_DEFAULT="console=tty1 console=ttyS0 earlyprintk=ttyS0 rootdelay=300"
+GRUB_CMDLINE_LINUX_DEFAULT="console=tty1 console=ttyS0 earlyprintk=ttyS0"

 # Set the grub console type
 GRUB_TERMINAL=serial

it seems that ROOTDELAY is the culprit here, and there were changes brought that mention rootdelay with yakkety merged initramfs-tools with debian.

some discussion https://irclogs.ubuntu.com/2016/08/23/%23ubuntu-devel.html#t11:36 including an un-tested fix from me.

> pitti smoser: ah, I remember -- indeed, this rootdelay= thing is FUBAR; TBH I don't see how to salvage it to anything remotely useful
> pitti smoser: IIRC, the problem was to define what "the necessary device" actually is
> pitti i. e. not just waiting for the root device, which we've done with udev's wait-for-root since 2006 or so
> pitti so if someone actually wants to use it, it's just a plain sleep(given_number) in the initramfs ATM, as there is no other definition of what it should do

Martin, there may not be any sort of definition upstream in Debian for what this did, but it has well-established semantics in Ubuntu that this is the *maximum* time that the initramfs should wait for the root device to be available, and if the timeout is hit the initramfs should drop you to a shell; but it should not cause the initramfs to wait longer. So this is certainly a regression. Can you please follow up on this?

Right, as I said on IRC I'm more than happy to just entirely drop the static sleep in /usr/share/initramfs-tools/init, as this is a completely broken/useless concept. Using it in the wait-for-root call in /usr/share/initramfs-tools/scripts/local similar to the wait-for-root call in /usr/share/initramfs-tools/scripts/local-premount/fixrtc seems good indeed.

Scott's patch in http://paste.ubuntu.com/23081737/ LGTM, I'll test/apply it ASAP. Thanks!

This bug was fixed in the package initramfs-tools - 0.125ubuntu3

---------------
initramfs-tools (0.125ubuntu3) yakkety; urgency=medium

  * init: Revert Debian commit ab91306. Interpreting "rootdelay" as a static
    sleep is complete nonsense. (LP: #1615751)
  * scripts/local: Let rootdelay determine the wait-for-root timeout instead
    of the shell polling loop that comes after it, as we should never hit the
    latter in Ubuntu (where we require udev everywhere). Thanks to Scott Moser
    for this patch!

 -- Martin Pitt <email address hidden> Fri, 26 Aug 2016 12:54:37 +0200

Verified this is fixed. Thank you!