On Tue, Jul 01, 2008 at 10:03:23PM +0200, Reinhard Tartler wrote:
David Härdeman <[EMAIL PROTECTED]> writes:
On Tue, Jul 01, 2008 at 08:28:52PM +0200, Reinhard Tartler wrote:
David Härdeman <[EMAIL PROTECTED]> 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
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
