On Sat, May 12, 2012 at 4:47 PM, Julius Adorf <jeadorf@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