Beyond the Double Password: Auto-Unlocking LUKS with TPM2

We have all been there. You just finished a pristine, fresh installation of your favorite Linux distribution. You did the responsible thing: you checked the box for Full Disk Encryption (FDE). Your data is locked down, your laptop is secure, and you feel like an absolute cypherpunk.

Then, you reboot.

First, GRUB asks for your 20-character passphrase to unlock the bootloader. You type it in. You wait a few seconds as the kernel loads. Then, the system halts and asks for the exact same 20-character passphrase to mount your root partition before starting your desktop environment.

It is maddening. It is redundant. And the good news? You do not have to live with it.

By leveraging the hardware already inside your laptop—specifically the TPM2 (Trusted Platform Module) chip—we can securely automate that second password prompt. As long as your hardware hasn’t been tampered with, your laptop will boot smoothly straight to your login screen.

Here is the complete, jargon-free guide to taking back your boot sequence.

The Magic Trick: systemd-cryptenroll

#

Before we start typing commands, let’s briefly demystify what we are actually doing.

Your encrypted drive (which uses a standard called LUKS) has multiple “slots” for keys. Right now, slot 0 holds the password you memorized. We are going to use a brilliant tool called systemd-cryptenroll to generate a new, highly complex hardware key, store it securely inside your laptop’s TPM chip, and put that key into slot 1.

We will specifically bind this key to PCR 7. In plain English, PCR 7 is the part of your motherboard that constantly watches your Secure Boot state. If an attacker steals your laptop, boots from a malicious live USB, or alters your BIOS, the TPM detects the change, panics, and refuses to hand over the key. Your drive stays locked.

If nothing has been tampered with? The TPM quietly hands the key to the kernel, and you boot in seconds. It is the perfect balance of convenience and paranoia.

Phase 1: The Prerequisites

#

Before we touch the terminal, let’s make sure your hardware is ready for this. Open up your terminal.

1. Verify you have a TPM 2.0 chip:

systemd-cryptenroll --tpm2-device=list

If your system returns a device path (usually /dev/tpmrm0), you are golden. Almost all modern ThinkPads and laptops have this.

2. Verify you are using LUKS2:

sudo blkid | grep crypto_LUKS

This guide relies on modern LUKS2 architecture. If you are on an older LUKS1 setup, this specific systemd method will not work.

3. Ensure Secure Boot is Enabled: You can check this by running mokutil --sb-state. If it is disabled, you will need to turn it on in your motherboard’s UEFI/BIOS settings.

Phase 2: Identifying Your Drive

#

We need to tell the system exactly which encrypted drive to target. We don’t want to guess here.

Run the block device list command:

lsblk

Look at the output tree. You are searching for the main partition that holds your crypt or luks volume.

• On Fedora or Ubuntu, this is usually something like /dev/nvme0n1p3.
• On openSUSE Tumbleweed, your root Btrfs partition is usually the LUKS container itself (often /dev/nvme0n1p2).

Identify that specific /dev/ path. You will need it for the next step.

Phase 3: Enrolling the TPM

#

This is where the magic happens. We are going to ask systemd to generate the hardware key and bind it to PCR 7 (the Secure Boot watcher).

Run the following command, making sure to replace /dev/nvme0n1pX with the drive path you found in Phase 2:

sudo systemd-cryptenroll --tpm2-device=auto --tpm2-pcrs=7 /dev/nvme0n1pX

The terminal will ask you to enter your current LUKS passphrase. This is simply to prove you own the drive before it adds the new hardware key. Type it in and hit enter.

Phase 4: Updating the Boot Configuration

#

Your TPM now has the key, but your boot sequence doesn’t know it’s allowed to ask for it. We need to update your cryptography table.

Open /etc/crypttab in your favorite terminal editor:

sudo nano /etc/crypttab

You will see a line representing your encrypted drive. It usually looks like this: cr_root UUID=12345678-abcd... none x-initrd.attach

Move your cursor to the very end of that line, add a comma, and append tpm2-device=auto. It must look exactly like this:

cr_root  UUID=12345678-abcd...  none  x-initrd.attach,tpm2-device=auto

Save the file and exit (Ctrl+O, Enter, Ctrl+X).

Phase 5: Rebuilding the Initramfs

#

We have changed the fundamental rules of how the system boots. Now, we just need to recompile the initial ramdisk so the kernel is aware of the new rules on its very next startup.

The command you use depends entirely on which Linux distribution you are daily-driving:

For openSUSE, Fedora, and RHEL (Using dracut):

sudo dracut -f

For Arch Linux (Using mkinitcpio): Ensure systemd is included in the HOOKS array inside your /etc/mkinitcpio.conf file, then run:

sudo mkinitcpio -P

For Debian, Ubuntu, and Pop!_OS:

sudo update-initramfs -u

Once the process finishes, type reboot and cross your fingers.

The Reality Check (and the openSUSE Caveat)

#

If you are on Fedora, Arch, or Ubuntu with a standard unencrypted /boot partition, congratulations! Your laptop should have just booted completely silently, dropping you right at the login screen. You successfully bypassed the decryption prompt entirely.

If you are an openSUSE user, read this carefully: openSUSE does something incredibly secure, but slightly annoying by default: it encrypts the /boot partition as part of the root drive.

Because GRUB (the bootloader) runs before the Linux kernel, GRUB has absolutely no idea how to talk to a TPM chip. Therefore, GRUB will still ask you for your password once just to load the kernel.

However, once you type it into GRUB, the kernel takes over, realizes the TPM has the keys, and silently unlocks the rest of the system without asking you a second time. While it isn’t a completely passwordless boot, you have successfully eliminated the redundant second prompt, cutting your login friction in half without sacrificing the intense security of an encrypted bootloader.

What happens if I update my BIOS?

#

If you flash a new BIOS update or reset your Secure Boot keys, PCR 7 will change. The TPM will notice this change, assume you are being hacked, and lock down.

Do not panic. You haven’t lost your data.

The system will simply fall back to the old method and ask you to type in your manual password. Once you boot to your desktop, open your terminal and run the exact same systemd-cryptenroll command from Phase 3, but add --wipe-slot=tpm2 to it. This will erase the old TPM key and generate a fresh one mapped to your new BIOS state.