[arch-general] Timing issues when decrypting a USB drive during boot (/etc/crypttab)

[Tom Gundersen]

On Sat, May 12, 2012 at 4:47 PM, Julius Adorf <jeadorf at googlemail.com> wrote:
> Recently, I tried to automatically unlock an encrypted external USB
> hard drive on Arch Linux. I have done this by inserting an appropriate
> entry into /etc/crypttab. I chose the device to be unlocked by
> cryptsetup with a key file by UUID.
>
> Unfortunately, the unlocking failed at boot time ("device does not
> exist or access denied"). After some debugging via /etc/rc.sysinit, I
> found out that it is a timing issue and the USB drive which is a
> couple of years old was not ready yet at the time the /etc/crypttab
> was read and processed. A similar issue has been reported here:
> https://bbs.archlinux.org/viewtopic.php?id=137467
>
> For now, I have inserted a workaround into /etc/rc.local which unlocks
> the disk after an initial delay. This is still programming by
> coincidence; I wonder whether there is any better (i.e. reliable)
> solution to this problem?

This is a fundamental problem of how our initscripts work. systemd
does not have this problem, so one option is to switch to that.
Another option is to add a hook which basically does "sleep <random
amount of time>".

A third option would be to add some workaround to initscripts to make
this work more reliably. This is essentially the current state of
affairs:

When "udevadm --settle" returns it means that as far as udev knows all
devices (such as sata or pata devices) are ready. However, due to the
way USB works, udev won't know if all the connected usb devices have
been discovered yet, so have no way of knowing when they are all
ready.

What we could do, would be to add some logic that figures out what usb
devices we certainly need (parsing crypttab and fstab), and fave a
loop waiting for those to appear. I prefer not to do this in
initsrcipts itself (as it is a bit too ugly for my liking), but it
could easily be done in the form of a hook (which could be put on the
AUR).

Cheers,

Tom