Why are you here? You are screwed, to be honest. Out of the jokes,
TPM-backed disk encryptionon Ubuntu 26.04 is one of those things that sounds like a checkbox in a release notes page and turns out to be a multi-day fight against your own graphics card and BIOS. Welcome.
Ubuntu 26.04 shipped native TPM-backed Full Disk Encryption as a headline feature. The pitch: select "Use hardware-backed encryption" in the installer, and the disk auto-unlocks at boot using the TPM chip, no passphrase typed daily. Sounds great, reaaaally great, but, It does not work on half or more of our fleet, and this doc explains why, how we found out, and what we actually did about it.
In case you don't know what a TPM is or why we even bother with disk encryption, go see SysAdmin doc → Security → Disk Encryption. If you're here because a laptop is stuck at boot asking for a passphrase it shouldn't be asking for, skip to the Clevis section near the end.
The Problem
We tried to enable native TPM-FDE on an HP laptop with an NVIDIA RTX 4060 Mobile. The installer refused. Not with a helpful message, just a refusal. So, being the professionals or masochists that we are, we went looking for the actual reason instead of just giving up and shipping laptops unencrypted like animals.
Finding Out What Was Actually Wrong
Canonical ships a diagnostic snap for exactly this. It's not on the stable channel, because of course it isn't:
sudo snap install --edge --devmode test-ubuntu-tpmfde-compat
sudo test-ubuntu-tpmfde-compat
The output actually told us something useful, which was refreshing:
This platform may be suitable for FDE if the following problem is fixed:
addon drivers were detected:
- [no description] path=\PciRoot(0x0)\Pci(0x1,0x0)\Pci(0x0,0x0)
Translation, after some digging: the NVIDIA GPU loads its own firmware (an EFI option ROM, aka its VBIOS) during boot, and the TPM notices this and goes "who the hell is this" and refuses to let Ubuntu predict what the boot measurements will look like. No prediction, no pre-sealed key, no encryption.
If we'd stopped there, that would've been an annoying-but-solvable problem: disable the GPU, done. Except we need the GPU, this laptop runs robotics simulation, so "just turn off the graphics card" was not on the table. Also I like my job.
We kept pushing anyway, tried the installer's advanced encryption path, and it threw a second, completely unrelated error:
PCR_UNUSABLE: generating secure boot profiles for systems with
timestamp revocation (dbt) is currently not supported
So now we had two independent problems, in two different layers of the boot stack, either one enough to block encryption on its own, both present at the same time on the exact same laptop. The GPU issue: nobody has a fix, it's a known upstream limitation. The BIOS dbt issue: tracked in an open Canonical bug since 2024, maybe fixed in a point release later this year. Maybe.
We were not going to wait for "maybe."
The Search For A Way Around It
The native installer tries to predict what the TPM's measurements will look like before the system has ever booted, so it can pre-seal a key to that prediction. That's the part that chokes on the graphics card and the BIOS quirk — it can't predict something it doesn't recognize.
Turns out there's a completely different tool that does the same job in a smarter way: Clevis. Instead of predicting the future, Clevis waits until the system has actually booted successfully, looks at what the TPM measurements actually are right now, and seals the key against that. It doesn't care what produced those measurements. Graphics card, weird BIOS feature, whatever — Clevis just shrugs and seals against reality instead of a guess.
This is the way.
Doing It With Clevis (The Part That Actually Works)
Step 1 — Install with a normal passphrase
In the Ubuntu 26.04 installer, when it asks about encryption, do not pick "Use hardware backend encryption" — that's the broken native path. Pick:
Encrypt with a passphrase
Set a strong passphrase, write it down somewhere that isn't a sticky note on the laptop. This passphrase becomes your permanent recovery key if the TPM ever refuses to cooperate — which, spoiler, it will, the day someone updates the BIOS.
Step 2 — Install Clevis after first boot
sudo apt install clevis clevis-luks clevis-tpm2 clevis-initramfs cryptsetup-initramfs
Step 3 — Find your LUKS partition
lsblk -f
Look for whatever partition shows crypto_LUKS under FSTYPE. Usually something like nvme0n1p3.
Step 4 — Bind it to the TPM
Here's where the first pitfall shows up. The obvious command is this:
sudo clevis luks bind -d /dev/nvme0n1p3 tpm2 '{"pcr_ids":"0,7"}'
And it will fail, with a message about the sha1 bank. Because of course our TPMs only populate the sha256 bank and Clevis, by default, tries sha1 first like it's still 2015. The actual working command:
sudo clevis luks bind -d /dev/nvme0n1p3 tpm2 '{"pcr_ids":"0,7","pcr_bank":"sha256"}'
Write this exact command down somewhere permanent. You will need it again, probably sooner than you think.
Step 5 — The pitfall nobody warns you about
Before rebuilding the boot image, check one file:
cat /etc/crypttab
If this comes back empty, stop. Do not proceed. An empty crypttab means the next step will build a boot image with no way to decrypt anything, and you'll end up at a shell with no cryptsetup binary, staring into the void, questioning your career choices. It should show something like dm-crypt-0 UUID=... none luks. If it's empty, reinstall and start over — something went wrong earlier.
Also force this, because sometimes the boot image "forgets" to include the decryption tool even with a valid crypttab, for reasons nobody has adequately explained to me:
echo "CRYPTSETUP=y" | sudo tee -a /etc/cryptsetup-initramfs/conf-hook
Step 6 — Rebuild and reboot
sudo update-initramfs -u -k all
sudo reboot
If everything went right, the disk unlocks itself, silently, with the graphics card fully intact and no ritual sacrifice required.
A Cosmetic Thing That Will Freak Out Users
After all this, users will see a "Please unlock the disk" prompt at every single boot, even though nothing needs typing. This is not a bug, it's just Ubuntu's boot splash (Plymouth) showing the LUKS prompt on principle, while Clevis handles the actual unlock silently behind it in about two seconds. If you type nothing and it boots anyway, everything is fine. Tell your users this before they start filing tickets about it, or you'll spend an afternoon explaining that no, the laptop is not broken, it's just dramatic.
When It Breaks Again (And It Will)
Every time a laptop gets a BIOS or firmware update, the TPM's measurements change, permanently, and the old sealed key is dead. Not "might not work" — dead, cryptographically, forever. The laptop will drop back to asking for the passphrase every boot until someone re-seals it.
The fix is the same bind command, run again:
sudo clevis luks unbind -d /dev/nvme0n1p3 -s 1
sudo clevis luks bind -d /dev/nvme0n1p3 tpm2 '{"pcr_ids":"0,7","pcr_bank":"sha256"}'
sudo update-initramfs -u -k all
Rule to tattoo somewhere: any time fwupdmgr update or a manual BIOS flash actually installs something, run this before the next reboot, or the user is stuck typing a passphrase they've probably already forgotten.
If someone already rebooted and is now locked out because the TPM is sealed against measurements that no longer exist, that's a live-USB recovery job — chroot in, unlock with the passphrase, rebind, done. That's a whole separate headache and gets its own doc.
That's Part 1. Getting the disk to actually encrypt itself was, in hindsight, the easy part of this whole saga. Part 2 covers what happened when we tried to get domain login, YubiKey 2FA, and sudo working on top of this — which involved SSSD deciding sockets are optional, adsys learning to enforce policies it used to politely ignore, and the discovery that Ubuntu quietly replaced sudo itself with something that doesn't talk to our domain at all. That one's worse. Go get a coffee first.