FS#38842 - [systemd] systemd-cryptsetup randomly fails to unlock LUKS partition on boot via keyfile
Attached to Project:
Arch Linux
Opened by Jay Strict (jaystrictor) - Saturday, 08 February 2014, 15:51 GMT
Last edited by Gerardo Exequiel Pozzi (djgera) - Wednesday, 12 February 2014, 23:07 GMT
Opened by Jay Strict (jaystrictor) - Saturday, 08 February 2014, 15:51 GMT
Last edited by Gerardo Exequiel Pozzi (djgera) - Wednesday, 12 February 2014, 23:07 GMT
|
Details
Description:
I have an encrypted /home partition and I have written a keyfile to the second partition of a USB stick and added the respective information to /etc/crypttab, in order to automatically unlock /home on bootup. After rebooting the system, one of two possible situations occur randomly: 1) During boot, the LUKS partition (/home) is correctly unlocked and the system boots without need for interaction. This is the intended behavior. 2) During boot, the LUKS partition is not unlocked. Instead, the boot sequence is interrupted, systemd-cryptsetup asks for a passphrase (for a different LUKS keyslot). This is the faulty behavior. Situation 2) seems to occur randomly in perceived 50% of all system bootups. I have tested this with two different USB sticks. Same result. Is there some race condition here? Maybe the file /dev/disk/by-id/usb-...-part2 is not yet available in case 2) I have censored some of the attached logs in this bug report. I apologize for the possible inconvenience. I am also not sure whether this bugreport belongs here or upstream systemd. Additional info: This is archlinux on x86_64 with linux 3.12.9-2 systemd 208-10 cryptsetup 1.6.3-2 libgcrypt 1.6.1-1 /etc/crypttab: ====================================================================== home /dev/sda9 /dev/disk/by-id/usb-...-part2 keyfile-offset=0,keyfile-size=512 ====================================================================== Steps to reproduce: 0. Have your /home partition as a LUKS encrypted partition in /dev/sda9 1. fdisk a usb stick and create two partitions sdb1 and sdb2 (size of sdb2 very small, 60MiB in my case). 2. dd if=/dev/urandom of=/dev/sdb2 3. cryptsetup luksAddKey /dev/sda9 /dev/sdb2 --new-keyfile-offset=0 --new-keyfile-size=512 4. echo "home /dev/sda9 /dev/disk/by-id/usb-...-part2 keyfile-offset=0,keyfile-size=512" > /etc/crypttab 5. Reboot, reboot, reboot, several times, don't remove the USB stick 
logs.txt
(9.9 KiB)
|
This task depends upon
Closed by Gerardo Exequiel Pozzi (djgera)
Wednesday, 12 February 2014, 23:07 GMT
Reason for closing: Fixed
Additional comments about closing: 208-11
Wednesday, 12 February 2014, 23:07 GMT
Reason for closing: Fixed
Additional comments about closing: 208-11
I'll bet that you can solve this with a dropin. Create "/etc/systemd/system/cryptsetup@home.service.d/keyfile.conf", with contents:
[Unit]
Requires=dev-disk-by\x2did-.......part2.device
After=dev-disk-by\x2did-.......part2.device
I can't help you with the exact values since you've decided to remove the data from your logs.
http://cgit.freedesktop.org/systemd/systemd/commit/?id=66a5dbdf282
Thank you for solving this so quickly and sorry for my late reply.
Unfortunately, now with this 208-11 patch, there is a new problem.
Now systemd always waits for the device to become ready and does not fall back to other LUKS keyslots.
So if I do not carry my USB stick with me, the system does not ask for a passphrase of some other LUKS keyslot
(which it did before the patch). Instead it times out and asks for the root password, saying that it couldn't finish booting and that I should resolve the issue by hand.
Would it be possible to add a timeout value to the Requires/After dependency, such that if the system can't find the USB stick for, say 10 seconds, it falls back to asking for the passphrase?
Anyways, the situation now is far better than before, and if there is too much work involved, then you can mark this bug as solved. I can live with the regression.