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

[Reinhard Tartler]

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:
>>
>>>>> initramfs-tools already has a rootdelay parameter which is executed
>>>>> before the cryptsetup initramfs script. What is the advantage of
>>>>> duplicating that functionality?
>>>>
>>>>the rootdelay parameter makes the initramfs loop until the root device
>>>>appears. It does not help the cryptsetup hook in any way.
>>>
>>> Well, unless my memory serves me wrong, it does....with a rootdelay=5,
>>> initramfs-tools will sleep 5 secs extra before cryptsetup gets a chance
>>> of executing which might be enough for the USB device to show up.
>>
>>Looking at the code:
> ...
>>I fear your memory indeed does serve you wrong :(
>
> 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.

> 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.

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4