[Pkg-cryptsetup-devel] Bug#488271: cryptsetup: use a loop to wait for the root device

[David Härdeman]

On Tue, Jul 01, 2008 at 10:03:23PM +0200, Reinhard Tartler wrote:
>David Härdeman <david at hardeman.nu> writes:
>> On Tue, Jul 01, 2008 at 08:28:52PM +0200, Reinhard Tartler wrote:
>>>David Härdeman <david at hardeman.nu> writes:
>> I think you missed /usr/share/initramfs-tools/scripts/init-premount/udev
>
>Oh, I needed to do some investiagtions about that file, it has been
>submitted by you as #414842. However, that particular patch has not been
>applied to ubuntu's udev.
>
>Scott, can you have a look at this patch:
>http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=udev-support_rootdelay.patch;att=1;bug=414842
>
>Is that acceptable for ubuntu?
>
>>>>> Do you see a better way solving the problem? 
>>>>
>>>> Yes, teach initramfs-tools to take a path as an argument to rootdelay
>>>> and make it wait until that path appears.
>>>
>>>If you can make the initramfs-tools maintainer refactor the code I cited
>>>above as a function and usable for cryptsetup, I'd agree with you.
>>
>> I don't think a rootdelay in cryptsetup is very satisfactory. There are
>> already two rootdelays, one before the cryptsetup script and one after
>> it. Adding a third will help in a quite limited way:
>
>(in ubuntu the one before does not exist)
>
>> a) Assume crypto-usb-stick takes 10 seconds to show up
>
>Can you be sure that it needs 'only' 10 seconds? Perhaps there are even
>slower devices out there?
>
>okay, you use 10 seconds as example, let's see
>
>> b) root= will be set to something which udev won't find
>>
>> c) rootdelay= is set
>>
>> Situation A - rootdelay < 10 secs
>>
>> 	udev times out, cryptsetup fails
>>
>> Situation B - rootdelay > 10 secs
>>
>> 	udev times out, cryptsetup works
>
>So in both situations the system fails to boot.

No, in situation B the system boots...udev times out after > 10 seconds 
which means the device has appeared when the cryptsetup script runs 
(after udev).

I actually suggested a completely different approach at one time to the 
udev maintainer...to let udev run a number of scripts for each new 
blockdev that appeared in the system until the rootdevice shows up 
(which would have the advantage of auto-executing cryptsetup's initramfs 
script on demand). But it was refused :)

>> d) With an additional rootdelay in cryptsetup
>>
>> Situation C - rootdelay < 5 secs
>> 
>> 	udev + cryptsetup times out, cryptsetup fails
>>
>> Situation D - rootdelay > 5 secs, rootdelay < 10 secs
>>
>> 	udev times out, cryptsetup waits minimum time, cryptsetup works
>>
>> Situation E - rootdelay > 10 secs
>>
>> 	udev times out, cryptsetup works
>>
>>
>> So you see..the patch saves a few seconds max...and the user still has
>> to pick an optimal rootdelay time...
>
>well, thats the purpose of the "3rd" (2nd in ubuntu) delay: the user
>doesn't need to specify magic boot parameters but make it 'just
>work'. At least on some more machines.

If a rootdelay= parameter is set it will behave exactly as I described 
above. The advantage of the patch is the magic delay if *no* rootdelay 
parameter is set...which will give a 3 minute additional boot time if 
e.g. the swap device is not available.

I'm not convinced, but if you want to go down this path I'd suggest a 
patch to initramfs-tools first which adds a delay() function, 
preferrably one that takes two arguments (a device and a timeout). Then 
initramfs-tools, cryptsetup and udev could use it.

Oh, also note that the current patch appears racy...you set the usplash 
timeout to e.g. 180 secs then run 1800 loop iterations in the cryptsetup 
script with a 0.1 sec sleep in each. If you get close to those 1800 
iterations it seems likely that you'll have spent more than 180 secs in 
cryptsetup (quite minor nitpick though considering that anything that 
happends close to the 180 sec mark is quite unlikely to be sane).

-- 
David Härdeman