What configuration, besides crypttab, determines which or how to decrypt storage devices at boot?

Both my root and swap partitions are encrypted with LUKS. So, when I boot up my laptop, I’m prompted to type in the passphrase to decrypt them. When installing Fedora, Anaconda set these partitions up to use the same passphrase. So normally, I would only have to enter the passphrase once while booting.

However, if mistype the passphrase on the first try, then I have separately enter it again for each encrypted partition. Even if I mistype only once, the minimum number of times I have to enter the passphrase jumps up from 1 to 3. When I changed my passphrase a little while ago and hadn’t fully committed the phrase to muscle memory, I could sometimes have to retype it many times before the system would finish booting.

I have already tried using cryptsetup to add an extra key to the swap encryption, and then editing /etc/crypttab to use that key file. But I’m still getting prompted for the swap’s passphrase whenever I restart my laptop. So it seems to me that systemd or Plymouth or something must have its own list of encrypted devices to decrypt at boot.

In hindsight, this maybe seems like a minor thing to complain about… So just to be clear, I’m more just curious about how systemd, Plymouth, GRUB2, or whatever else decides which and how things need to prompt the user for a passphrase. Because my understanding of the crypttab file is that I shouldn’t ever need to type a passphrase, when the two partitions look like this…

# /etc/crypttab
# name                                    device                                    key                    options
luks-<uuid_for_encrypted_root_partition>  UUID=<uuid_for_encrypted_root_partition>  none                   discard
luks-<uuid_for_encrypted_swap_partition>  UUID=<uuid_for_encrypted_swap_partition>  /root/<luks_swap_key>  discard

I have tried double checking basic things like the swap partition’s key file — it does exist, the path in crypttab is correct, and that key file does indeed decrypt the swap partition when manually running cryptsetup. It doesn’t seem to have changed the boot behavior, though, so I can still get prompted for the swap passphrase. :thinking::thinking::thinking:

Still currently on Fedora 31 Workstation edition x86_64, with current updates at least as of a few days ago, if that makes a difference… though I’d be surprised if this were a part of the system that changes very often.

  • kernel 5.6.6-200
  • cryptsetup 2.3.0-1
  • systemd 243.8-1
  • Plymouth 0.9.4-14.20200325gite31c81f
  • Grubby 8.4-36
  • GRUB2 2.02-108

I even tried changing root and swap partitions’ name field in crypttab, and appending ,noauto,nofail to the options field for the swap line, in both crypttab and fstab. However, Fedora still prompts me for a swap passphrase, and still decrypts/mounts the swap partition with the luks-<uuid> mapper name. Curiously, I can change the root partition’s crypttab mapper name, but the swap partition remains completely unaffected by any changes I make.

I also tried commenting the swap line out entirely, but that didn’t make any difference either.

I got it! The missing configuration was for GRUB2. In /etc/default/grub, the GRUB_CMD_LINUX= line contained the parameters

resume=/dev/mapper/luks-<uuid_for_encrypted_swap>  rd.luks.uuid=luks-<uuid_for_encrypted_swap>

So at boot time, GRUB2 was telling the kernel to decrypt the swap partition the usual way, and with the UUID-based mapper name, which I suppose the crypttab file couldn’t override.

I made a copy of the GRUB_CMD_LINUX= line in /etc/default/grub, and commented it, so I would have a backup for reference if needed in the future. But then in the uncommented version, I deleted those kernel parameters for the swap partition. Fedora now only ever prompts for the root partition’s LUKS passphrase; uses the keyfile specified in crypttab to decrypt swap; and uses the specified mapper names from crypttab for both root and swap.

:nerd_face: :partying_face: :sunglasses:

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.