[Pkg-cryptsetup-devel] Bug#465763: Bug#465763: Bug#465763: Bug#465763: cryptsetup: can't boot from USB device

[Jonas Meurer]

On 18/02/2008 Piotr Roszatycki wrote:
> 2008/2/18, Jonas Meurer <jonas at freesources.org>:
> > > Yes, indeed this delay is implemented in udev package, at least in
> > > sid. Even that, I think this is not the best option because it is hard
> > > to guess how much time the USB device starts up. I think the safe
> > > option is to check if the proper device will appear as /dev/sd? entry.
> >
> > Piotr, what do you think about adding the check to the udev script
> > instead of bloating cryptroot script with yet another delay?
> >
> > David pointed me to the fact that the proper fix would rather be to fix
> > the udev initramfs script, not to add yet another delay option to
> > cryptsetup initramfs script.
> >
> > The udev ROOTDELAY implementation already is at the right place, it just
> > needs to be extended to actually check for existence of the device.
> 
> I think the udev have completly no idea on what device is encrypted
> volume. Do you think the udev package should read /etc/crypttab file?
> If so, then please reassign this bugreport to udev package.

Hey Piotr,

you're right, the udev scripts should not know about /etc/crypttab at
all. But still some issues exist with your patch.

Here's the reply by David:

> I see Piotr's point, but there are still two issues:
> 
> 1) The rootdelay would be implemented in no less than 3 places
> 
> 2) Since udev uses it...if you set rootdelay to e.g. 20 seconds, udev
> will cause a 20 sec wait since root will be set to something like
> /dev/mapper/blabla and udev waits (if I remember correctly) for the
> device set as root to appear. So I still don't see the point in
> re-implementing it in cryptsetup...since you will get the maximum delay
> from udev long before the cryptsetup script is executed.
> 
> Let's take an example...let's say you know it takes 10 seconds for your
> slow disk to show up.
> 
> With Piotr's implementation (unless I misunderstood it), the minimum you
> could set rootdelay to would be 5 seconds (5 for udev, 5 for cryptsetup).
> If you do less, both will time out before the disk is ready. If you do
> between 5 and 10 seconds, you will get an "optimal" delay because udev will
> time out before the disk appears and cryptsetup will wait an "optimum"
> amount of time.
> 
> If you set the delay to more than 10 seconds, you will still have
> unnecessary waiting since udev will wait past the time when the disk has
> already shown up.
> 
> So the only effect is that if rootdelay is between 5 and 10 seconds, you
> can get the optimal waiting time of 10 seconds.
> 
> Sounds like a tiny benefit to me. Not that I'm going to argue the point.
> I feel it's quite uninteresting :)
> 
> If he is serious about it, perhaps it would be better to write a patch
> such that rootdelay could also (instead of) a time, specify a device path
> which would cause the boot to wait indefinately until said device path
> appears (say rootdelay=/dev/whatever).

what do you think about it?