LUKS decrypt for /home fails 80% of the time

Ask Fedora
1

Clean install of Fedora 44 using sdboot (systemd-boot). I have my partitions broken out to the following:
/boot/efi (VFAT)
/ (ext4)
/var (xfs)
/var/tmp (xfs)
/home (xfs)
/tmp (tmpfs; 2GB)

80% of the time (it does boot sometimes, just not most of the time) the /home partition ignores /etc/cryptsetup mapper names and gets decrypted by something else, so my fstab fails to mount /home since the defined /dev/mapper/path doesn’t exist. So, I feel there is a race condition of 2 things trying to decrypt /home . I assume it’s a systemd “service” of some kind.

All partitions have partition labels. I use a Yubikey with PIN for LUKS. If I boot into a USB rescue mode I can manually cryptsetup each partition using the /dev/disk/by-partlabel/ labels to a /dev/mapper/mapname and mount it manually. So, I know the LUKS part works and occasionally it will boot okay.

My /etc/crypsetup is of the following pattern:
luksPARTLABEL PARTLABEL=partlabel

ie: I don’t use UUIDs here.

My /etc/fstab uses the /dev/mapper/luksPARTLABEL path as the disk path

However, when the system fails to boot and drops me to a prompt the HOME partition isn’t mapped to /dev/mapper/luksHOME like cryptsetup says it should be, but instead is just /dev/mapper/dm-2

I did run dracut after changing cryptsetup and it seems to correctly unlock and mount all the other partitions without issue, so I don’t think it’s a syntax problem or that PARTLABEL can’t be used in cryptsetup.

I think systemd is trying to be “helpful” and I need to reconfigure “something”, but I don’t know what that “something” is. Thoughts?

2

When it doesn’t decrypt correctly, have you examined the journalctl output for the failing boot to see what is performing he decryption and/or any errors?

3

Maybe the device you list in /etc/crypttab is not a stable device name?
I had a Fedora upgrade that changed the order that devices where scanned and the fix in case was to use a stable device name.

4

Exactly.
This is why the automatic configs use the file system UUID for mounting. I think that is the only ‘stable’ ID that is always available for mounting/manipulating devices.

5

partition labels are certainly “stable”. They’re just a more “human readable” version of a UUID and way easier to deal with when you’re trying to figure out what’s what on a system.

for example, one can just mount /dev/disk/by-partlabel/USBDISK instead of having to remember a UUID or whatever /dev/sd[a-z] device something got assigned when it got plugged in.

No, the PARTLABEL not being “stable” isn’t the problem. Sure, one has to manually create them, but once created they’re not going to change or move even if the underlying disk moves from sda to sdc or even to a nvme disk.

That being said I re-powered on the laptop today and I haven’t been able to re-create the problem. It’s booted multiple times without issue until I fat fingered the PIN. I’ll play with it some more an update this thread if I get it barf again with any relevant journalctl output.

thanks.

6

The journal should have entries for the boots where LUKS decrypt failed. Worth checking to see if something has changed as opposed to a run of good luck with a race condition.