You are not logged in.

#1 2019-08-14 16:41:42

Registered: 2014-10-07
Posts: 16

3rd HDD (LUKS) randomly not unlocked by crypttab.initramfs


Recently I've replaced DVD-RW on Asus K75 with 3rd hard disk (actually, I moved 2nd HDD to DVD bay and installed new HDD as 2nd - it's important 'cause there were no troubles with the previous setup).
All disks are LUKS on LVM and they have the common passphrase to unlock them; systemd init with "sd-encrypt sd-lvm2".


root_luks	/dev/disk/by-partlabel/ROOT	none
home_luks	/dev/disk/by-partlabel/HOME	none
ext_luks	/dev/disk/by-partlabel/EXT	none

With 2 disks setup systemd always asked for a passphrase for root_luks and then unlocked home_luks with the cached passphrase. There were no troubles for years.

But with 3rd disk added, systemd asks randomly for root_luks or home_luks passphrase (why the order from crypttab.initramfs is ignored?) and if it was root_luks, there is about 25% chance that ext_luks will not be unlocked. After asking a pass for home_luks, it always (so far) unlocks ext_luks.

So, my questions are:

1) why systemd doesn't respect unlock order from crypttab.initramfs? If unlock key for other drives were on root_luks, the system will fail to boot about 50% times.

2) why ext_luks is not unlocked randomly? At the time when init drops to maintenance console, /dev/sdc (where ext_luks is located) is accessible.

Any help is appreciated.


#2 2019-08-15 10:40:00

From: Athens, Greece
Registered: 2009-05-26
Posts: 223

Re: 3rd HDD (LUKS) randomly not unlocked by crypttab.initramfs

[I am guessing here] so when system is booting, disks are psedo-random get an order (disk1, disk2, disk3) and due to this random order, we are using LABELs or even better UUIDs to map disks to persistent order in our system (fstab/cryptsetup etc). Now here is the trick that Luks does,  luks keep the latest passphrase in memory in order to unlock disks. If your disks have the same passphrase in the correct order, then your disks will auto-decrypted by luks without asking, but if the order is not correct then it will ask a passphrase. If your setup is not interactively then it will fail and boot without unlocking the disk (in best case) or pause/crash/whatever in worst case.

Personally I only decrypt the rootfs disk and use keys to encrypt/decrypt the other encrypted disks in boot by mapping UUIDs with these keys.
Hope that helps you a bit.
Linux System Engineer - Registered Linux User #420129


Board footer

Powered by FluxBB