This week, I installed Ubuntu 24.04 on a Minisforum UM750L and tried out the TPM-backed FDE option. The initial experience was quite smooth!
After the first successful boot, I grabbed the recovery key by running sudo snap recovery --show-keys and stashed it in my password manager. I confirmed subsequent reboots unlocked the disk automatically.
Today, I replaced the Mediatek WiFi card that came with the box with a proper Intel one. As one might expect, the next boot after that prompted for the recovery key. I entered it, and the system booted.
Great! Up to this point, the experience has been exactly what I expected.
I then rebooted again.
I expected the system to unlock the disk automatically.
Instead, I was prompted again for the recovery key. I entered it, and the system booted.
Questions:
Is the the user experience the team expects?
How can I manually re-seal the FDE key against the current hardware state so I don’t have to enter the recovery key on every boot?
I should also add — I haven’t done anything to attempt to “fix” this, and I’m happy to share any logs or other information that might help diagnose why this is behaving this way if it’s not the expected behavior.
I would like to share what I have found from a Google search for “ubuntu refresh tpm fde.” It is an AI overview. Look for the heading called “Steps to Refresh/Rest (Experimental)
I have seen some very good official documentation relating to TPM FDE but I do not see anything about Refreshing the TPM. Perhaps it is because it is still experimental. And I cannot provide links to the documentation the the AI is sucking its information from.
Refreshing Ubuntu’s TPM-backed Full Disk Encryption (FDE) involves
ensuring Secure Boot and TPM are enabled in your BIOS/UEFI, potentially wiping the TPM from the BIOS for a clean state, and running fwupd tools to align your system firmware and TPM state for the newer FDE standards, often using commands like echo 5 | sudo tee /sys/class/tpm/tpm0/ppi/request for a reset, as this feature in Ubuntu (especially 23.10/25.10+) links disk unlocking to verified system integrity.
Key Concepts
TPM-backed FDE: Encrypts your drive using keys managed by the hardware Trusted Platform Module (TPM), verifying the system’s early boot components (firmware, OS loader) before unlocking data, preventing pre-boot attacks.
Secure Boot: Required for TPM FDE; it ensures only signed, trusted code runs during boot.
Steps to Refresh/Reset (Experimental)
Enable Secure Boot & TPM in BIOS/UEFI: Ensure both are turned on in your system’s firmware settings.
Wipe the TPM:
From BIOS/UEFI: Look for a “Clear TPM” or “Reset TPM” option.
From Ubuntu (if available): echo 5 | sudo tee /sys/class/tpm/tpm0/ppi/request then reboot.
Ensure Firmware (fwupd) Compatibility: Use fwupdtool commands (e.g., install-blob) to update firmware, as TPM FDE relies on proper firmware chains.
Check Compatibility: Ubuntu 25.10+ has improved checks; you might need to run specific commands (like installing a test snap) to report compatibility, helping Canonical refine the feature.
Important Considerations
Experimental: This feature is often experimental and may require specific hardware or BIOS settings; it’s not always a simple “on” switch.
Data Loss Risk: Always have backups, as incorrect TPM/FDE setup can lead to permanent data loss.
Upgrade Path: Upgrading between Ubuntu versions with TPM FDE enabled can be complex; wait for official support in newer releases like 25.10/25.11 for smoother upgrades.
Oh well. I was hoping someone who has worked directly on this feature might lurk here and be able to at least say “yeah, that’s not possible, but we’ve addressed it in 25.10”.
Anyway, this was clearly flagged as experimental. I guess I’ll see how 26.04 looks and either upgrade or do a fresh install if no upgrade path exists for the 24.04 TPM-backed FDE approach there.
I probably wasn’t very clear in my original post. I certainly did not expect the disk to unlock automatically after changing the hardware configuration. But I did expect that after entering the recovery key, the system software would use that key to update the information stored in the TPM such that the next boot on the same hardware configuration would not require manual key entry.
This seemed like such a basic thing to me that I thought the behavior I encountered might be a bug (hence posting here). Perhaps next time I’ll just file a bug report in launchpad.