Arch Linux

Description:

The purpose of the rootdelay kernel parameter is to cause the kernel to delay for the specified number of seconds before mounting the root device, to allow devices which need to be discovered before the mount can succeed to be discovered.

The init script and filesystem hook of the initcpio scripts (located in /lib/initcpio, and used by mkinitcpio to create the boot ramdisk image) also use rootdelay to pause before using the root device, for the same reason.

The thing about this delay is, if it's done by the initial ramdisk init scripts, then it doesn't need to be done by the kernel - the device, if the ramdisk init scripts ensure that it is valid (which they do), does not need to be waited on by the kernel as well.

The end result is an extra unnecessary delay in bootup. One of the great things about Arch Linux is how fast it boots, and an unnecessary 8 second (or more) delay kind of sucks.

I can think of three ways to solve this problem:

1) The easy way: just have the initcpio scripts base their delay off of a parameter that does not conflict with the kernel's rootdelay parameter. For example, rename it to "udevdelay". I tested this solution in my own Arch installation and it works perfectly. I just set a kernel parameter "udevdelay=8" and *don't* set any rootdelay parameter, and also modified the initcpio scripts to expect udevdelay instead of rootdelay, and - bingo, my device is properly waited on and the initcpio scripts work fine, and then the kernel doesn't bother to do any extra delay before mounting root and my boot works perfectly and is faster.

2) Continue to use rootdelay but have some way to strip it from the kernel's parameters before continuing on to the part where the kernel mounts the root filesystem. I don't know if this is even possible, but it would allow the rootdelay parameter to be used exclusively by the initcpio scripts. I don't think this is a very attractive solution anyway.

3) Implement "wait" logic for causing the initcpio scripts to poll for the existence of the root disk device rather than doing what they currently do, which is to (optionally) wait a specified length of time and then try to manually create the device if it doesn't exist. This could be a new behavior invoked by a kernel argument like "waitroot=30", which if set, would cause the initcpio scripts do invoke this logic (the 30 means wait at most 30 seconds) instead of the normal test-and-create-root-device logic:

COUNTER=0
while [ ! -b "${root}" -a $COUNTER -lt "${waitroot}" ]; do
sleep 1;
done

I think this is the best solution of all, because it gives users the option to simply wait until their root device is detected, rather than having to guess a delay that may often be much more than needed, but sometimes still not be enough.

Additional info:
* package version(s)
* config and/or log files etc.

Relevent packages:

kernel26 2.6.24.4-1
mkinitcpio 0.5.18.1-1
grub 0.97-12

Steps to reproduce:

Add a parameter "rootdelay=10" to your grub kernel line.

Boot from a USB device (this problem may not be evident if you are booting from a device which is immediately known to the kernel rather than having to be queried for, because I think the initcpio scripts detect when the device is already there and don't do the rootdelay).

Observe that there is a 10 second pause during the initcpio script run (which is acceptable), and also that the kernel later pauses before mounting the root device (which is unnecessary and slows the boot down).