[arch-general] Timing issues when decrypting a USB drive during boot (/etc/crypttab)
Hello, 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? Best, Julius
Julius Adorf <jeadorf@googlemail.com> writes:
Hello,
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?
I think systemd auto mount facility may be able to handle it. But you're probably won't want to use systemd only for this. -- Carl Lei (XeCycle) Department of Physics, Shanghai Jiao Tong University OpenPGP public key: 7795E591 Fingerprint: 1FB6 7F1F D45D F681 C845 27F7 8D71 8EC4 7795 E591
On Sat, May 12, 2012 at 5:17 PM, XeCycle <xecycle@gmail.com> wrote:
Julius Adorf <jeadorf@googlemail.com> writes:
I think systemd auto mount facility may be able to handle it. But you're probably won't want to use systemd only for this.
systemd was created specifically to avoid these kind of problems, so maybe you do want to use it only for this. I've already switched to systemd and I am quite satisfied with it. -- Rodrigo.
Thanks for your efforts.
systemd was created specifically to avoid these kind of problems, so maybe you do want to use it only for this.
As far as I am concerned, I'll leave the workaround on my local work station as it is for now. I was just wondering whether I overlooked something obvious; as soon as the situation asks for a more robust and reliable solution, I will give systemd+cryptsetup a try.
I prefer not to do this in initsrcipts itself (as it is a bit too ugly for my liking)
I have noticed that the symbolic link for the USB drive in /dev/disk/by-uuid has already been created at the time crypttab is processed in rc.sysinit; still the drive can only accessed and decrypted after some delay. I have only very superficial understanding of the initscripts. Yet, I think that inserting logic just to avoid such specific problems is probably no good, especially when it is dealing with asynchronous behaviour. Regards, Julius
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
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.
Udisks listens to udev events and sends dbus events, so you can make a "daemon" script, similar to that devmon shell that waits for your usb drive and then does what it needs to do. -- дамјан
On Sat, 12 May 2012 16:47:36 +0200 Julius Adorf wrote:
I wonder whether there is any better (i.e. reliable) solution to this problem?
until mounted (grep /proc/mounts); do sleep 5 mount Where do you store the key anyway?
On Mon, 14 May 2012 14:01:05 +0100 Kevin Chadwick wrote:
Where do you store the key anyway?
Sorry didn't read your message carefully. I assumed it was a system drive as you were using rc. Why not use a udev rule as дамјан mentioned. That's what systemd would use anyway. Or even a simple button in your gui to mount it.
Where do you store the key anyway?
The key itself is on an encrypted drive, an extra passphrase is not required for my purposes.
Sorry didn't read your message carefully. I assumed it was a system drive as you were using rc.
Nope, it is an external drive.
Why not use a udev rule as дамјан mentioned. That's what systemd would use anyway. Or even a simple button in your gui to mount it.
Thanks for reminding me of udev rules. I've now created a udev rule which triggers the decryption; even better than the rc.local solution since it will be decrypted whenever I plug the external drive in. The timing issue remains. My drive is really slow compared to a very new one; I will replace it eventually anyway, so it's just a matter of time that the problem disappears... J.
participants (6)
-
Damjan
-
Julius Adorf
-
Kevin Chadwick
-
Rodrigo Rivas
-
Tom Gundersen
-
XeCycle