Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

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
Task Type Bug Report
Category Upstream Bugs
Status Closed
Assigned To No-one
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


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

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
Comment by Dave Reisner (falconindy) - Saturday, 08 February 2014, 16:08 GMT
You've created a race condition because you haven't declared any dependency on the device that contains your keyfile.

I'll bet that you can solve this with a dropin. Create "/etc/systemd/system/cryptsetup@home.service.d/keyfile.conf", with contents:


I can't help you with the exact values since you've decided to remove the data from your logs.
Comment by Dave Reisner (falconindy) - Saturday, 08 February 2014, 18:54 GMT
This seems like something that could be solved in the cryptsetup-generator, so I've fixed this upstream:
Comment by Dave Reisner (falconindy) - Saturday, 08 February 2014, 19:34 GMT
You can try testing/systemd-208-11 which has this backported.
Comment by Dave Reisner (falconindy) - Tuesday, 11 February 2014, 14:08 GMT
Comment by Jay Strict (jaystrictor) - Wednesday, 12 February 2014, 11:48 GMT
Yes, with systemd-208-11 this now works in 100% of all boots.
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.