TPM-backed FDE: Take 2 minutes to help widen Ubuntu compatibility with your TPM configuration!

Project Discussion Desktop
, ,
21

Guys, on all my testing device models (corporate HP and DELL), the Ubuntu 26.04 Snapshot 3 has been successfully installed in TPM FDE mode.

  1. You need to disable Absolute:
    On DELL, it is Easy, just navigate to the firmware’s security settings and set Absolute to Disable, don’t select permanent disable, or to enable back, you will need to visit the service center :smiley: .
    On HP, it is harder; you need to install Windows or get WindowsPE, since PowerShell commands are based on WMIC.
    There is no single solution; you must read available firmware parameters and call the best one. On some models, you can use disable Absolute, on others, only permanent disable is available.
  2. Don’t forget to initiate TPM cleanup on next boot, or Ubuntu installer will suggest to initiate the same option, otherwise it will not beable to enable TPM FDE.
    That’s all, good luck!
22

The Ubuntu 26.04 Snapshot 3 has been successfully installed in TPM FDE mode, on VirtualBox 7.2.6.

1 Like
23

Dear, @didrocks Absolute starts Linux initial support early 2026, is there a chance, that Ubuntu will participate?

It will be enough to bypass the necessity to disable Absolute in firmware for TPM FDE.

Absolute Secure Endpoint Product Update - October 2025 https://community.absolute.com/s/article/Absolute-Secure-Endpoint-Product-Update-October-2025

24

Why isn’t it enough to just have the Absolute module in the “Inactive” state? In this state, he shouldn’t do anything, right? TPM FDE on Ubuntu worked like this before, so why not now?

I also wouldn’t want to permanently lose the ability to use it at some point in the future.

25

Because, if you try to install Ubuntu in TPM FDE mode it will warn that you must disable Absolute, even if it is in inactive state, and if you ignore the warning and finish the installation successfully, after reboot you will get the TPM lock, since even in inactive state, Absolute is trying to inject it’s rootkit into OS Bootloader, Secure Boot reports that something changed in PCR7 and you will get a lockout, this is how Absolute works, the inactive state means that it’s working but not configured.

Please distinguish, Absolute have two states, Disabled, which means you can enable it back, and Permanently Disabled, which means, only service center expert can enable it back.

Active and Inactive is about subscription and configuration.

26

Experimental TPM-backed FDE already worked in 24.04.3 LTS and Absolute module in “Inactive” state did not interfere with it. After reboot, the disk automatically unlocked normally and the laptop booted without any problems. Therefore, I would expect that inactive Absolute module (even if enabled) has no reason to try to inject something somewhere. But I don’t see deeper into this topic, I just tried what I could.

27

Please try Ubuntu 26.04 Snapshot 3, there are too many fixes for TPM.

29

@didrocks , Owner of https://www.acer.com/ua-uk/support/product-support/AN17-41/NH.QL1EU.003/ here, did the things to add my two answers to the form.
I was monkey-testing the Racoon Daily 2026-03-12 iso, to get TPM FDE variant, and got stuck with
PCR_UNUSABLE
error with secure boot policy (PCR7) measurements: generating secure boot profiles for systems with timestamp revocation (dbt) support is currently not supported
Anything I could do to help with this config?
I also showed up here: WithSecureBootPolicyProfile should accommodate systems that support timestamp revocation · Issue #306 · canonical/secboot · GitHub

30

What solved the issue for me (autoinstall, non interactive installation process):

  1. First I got the problem “Subiquity/apply_autoinstall_config: hybrid layout (with encryption) is not available: tpm-hierarchies-owned” - Solved by clearing TPM in BIOS.
  2. Then I got the issue: “Error: shim protocols not found” after the installation went through - Solved by removing fast boot.
  3. After that the computer boots up completely fine, with full disk encryption, working perfectly.

Only issue I am having now, is to somehow save the recovery key for the encryption, so that I can send it to AD through ldap.

Since snapd –show-key is no longer supported on Ubuntu 25.10+, I can’t pull the recovery key that way. Manually retrieving it through Security Center is not an option for large‑scale deployments.

I’m currently exploring whether it’s possible to generate a new recovery key and extract it through the snapd REST API instead.

No success grabbing the recovery key through CLI so far.

31

Thanks a lot for everyone’s participation!

WIth latest beta image for resolute being out, with some manual update, you are able to test the latest state of our TPM/FDE detection. We would be really interested to get your feedback and remaining configurations where some adjustements are needed.

All the instructions are available in this new poll. Thanks a lot in advance for your participation!

1 Like
32

TPM FDE works perfectly on corporate HP and Dell laptops, expect two cases:

  1. In case of any HP EliteBook, ProBook and ZBook (all models are Ubuntu certified) the Absolute software was in Inactive state, and it crushing the installation, to disable it we need to use an WMI based commans in PowerShell. But the painful point is that in the last two generations, the “disable” option is gone, we can use only “permanently disable” option.
  2. Because of Snap Kernel (I tested Beta image with Linux 7 kernel) I faced a “dummy output” for audio devices on latest two generations of laptops, older ones aren’t affected.
2 Likes
33

Tuxedo Pulse 14 4gen + 26.04 + self-signed

running the command I got:

This platform is not suitable for FDE because of the following problem:
error with secure boot policy (PCR7) measurements: cannot read current Boot0005 load option from log: cannot read load option from event data: unexpected EOF

34

Hi I am new to this forum, long time Ubuntu user and was looking forward to TPM FDE. Downloaded 26.04 within the first hour of its release on Thursday, using Lenovo M720Q. I am dual booting windows 11 on a second drive with bitlocker.

I tried to install with a full disk erase and tpm FDE option but firstly got a message about TPM_RC_VALUE being out of range or unrecognised so I tracked down a TPM firmware update from Lenovo which (it is a Nuvoton chip), since the update I’m now getting a bootguard acm not active message.

As this thread seems to be very well established with some key influence on tpm FDE I would like to both ask how can I overcome this error, and explore what the future holds for FDE.

I see potentially two different options for tpm FDE in the future, strict enforcement as now, and a slightly more relaxed option which still enables tpm FDE with warnings about any stages that cannot pass the process and checking the user is happy to continue?

Thanks for any help on this.

35

A bit worried because currently FDE looks to be way too restricting due to, it seems, the Intel BootGuard requisite. If I understood right, this entails:

  1. It won’t work on any “homemade”, non OEM, PC. In my case, the test threw “error with TPM2 device: TPM2 device is present but it is not a PC-Client TPM”
  2. You’ll need an Intel CPU as BootGuard extensions are Intel only.
  3. OEM manufacturer must have configured BootGuard before and only before shipping the device. Otherwise, no positive action of any kind is possible? I tried installing Ubuntu 26.04 on a second, modern OEM machine, but FDE setting returned “error with system security: encountered an error when checking Intel BootGuard configuration: no hardware root-of-trust properly configured: BootGuard ACM is not active”

In my view, point 3 points towards nothing but the most sensitive endeavors (the military, prime minister’s office … ?). I hope you are considering relaxing a bit this prerequisites now that FDE is stable and well. But, are you?

Thank you so much and kind regards.

IMG_20260424_153508
IMG_20260424_1535081920×1440 111 KB

36

Thanks a lot to all of you reporting your concerns on TPM/FDE and where things don’t align with the expectation.

Indeed, the Boot Guard requirements seems to be one of the main blocker (a restriction that Windows doesn’t have). For people interested in the details, the installer page has a link when your system is not eligible to https://documentation.ubuntu.com/desktop/en/latest/reference/hardware-backed-disk-encryption-requirements/, which shows the various requirements. You will see there that Boot Guard is required on Intel system, but we have the equivalent for AMD too (after checking with the AMD folks when working on this feature).

Also, that page has a link to open bugs on models that should support TPM/FDE but doesn’t due to detection bugs. Please, if this is the case (and only if this is the case, because the flood of bugs might delay the whole response rate, so don’t file one if your system doesn’t match the requirements written in that page), please file it, with all the system information you can have. We are looking at them and trying to fix as many of them as possible for 26.04.1.

On the root of trust requirements, we are discussing this again with our Security Team to see if we can make or not this step skippable (as other actions already exist to allow the user to ignore the “less secure setup“ and take potential risks). I will keep you posted on that one.

7 Likes
37

Thank you so much. What are those other actions you mention?

38

@didrocks Brilliant thanks and I’m delighted you’re able to talk with the security team. I think allowing the bootguard step to be skipped, perhaps with a warning, is a great middle ground. The irony with a heavily strict enforcement is users may decide not to encrypt at all, especially new users who are uncomfortable adding the drive key to TPM themselves and find entering a passphrase inconvenient so skip drive encryption entirely.

3 Likes
39

I thought I’d post my experience here incase it helps others, albeit unfortunately a bad one in my case.

I’d tried get the TPM FDE functionality working the other day, on a Gigabyte x570 UD motherboard (2019 model, AM4 socket), running the latest firmware available for it (2025).

Windows 11 had no issues with TPM backed Bitlocker on this system, but Ubuntu 26.04 had two main issues

  1. Ubuntu couldn’t clear the TPM despite offering 3 different options in the installer to try. That’s fine, the TPM could be reset in the UEFI/BIOS itself, which the installer also detailed as an option if the easier built-in routes didn’t work.

  2. Ubuntu kept stating the system needed to be in “deployed mode”, which lead me down several hours of figuring out what that meant, because the same configuration worked fine with Windows 11, which claimed Secure Boot was enabled fine, as well as other tools in Linux like mokutil -–sb-state, systemd-bootctl and others, also saying secure boot was enabled.

After various hours learning about tools like systemd-analyze pcrs and getting a better understanding about how this all fits together, alongside clearing the CMOS a few times and downgrading and upgrading firmware, alongside resetting the factory keys in the UEFI repeatedly, I’d eventually noticed what I think the error was:

  1. this is a 2019 motherboard, but Microsoft released a new signing key 2023

  2. restoring the factory keys would install the 2023 Microsoft KEK above

  3. the KEK keys would unset the deployed mode bit, because the firmware seemingly doesn’t trust its own factory keys (a big defect!)

I’d been told elsewhere that strictly only the PK key needs to be enrolled. Being about 12 hours into this I wasn’t really expecting the that removing all the other keys but the PK keys would be fatal,

  1. with just the PK but no KEK keys installed, the system would show as verified, finally (presumably meaning the deployable bit was fixed)

  2. the system would now reboot and be fatally broken, logically I’d have to assume that it now no longer trusts itself, and refuses to boot entirely

Trying to reset the firmware the manual way (these motherboards can rewrite the firmware without a CPU installed) doesn’t work at all. I’m cautious that the firmware doesn’t trust it’s own code sufficiently, and so, is basically bricked.

As a result I’m currently without a desktop and trying to get everything done on a phone :joy:.

In any case, would it be possible for Ubuntu, like Windows, to simply ignore the deployable bit if the rest of the chain can be validated? It does mean my PC has been running in not quite secure mode for years apparently, since unsigned bootloaders would have still been able to run, but I’m presuming Microsoft’s logic is that the system can still tell it’s the wrong bootloader and the FDE isn’t compromised because in such a situation the system wouldn’t leak keys anyway. Given the amount of Windows users, I imagine this must have been common enough for Microsoft to work around it for the sake of user experience.

Tl;Dr

Can we possibly lighten up on the deployable mode restrictions like Windows does?

40

Seconding what others said above: if the policies could be relaxed to the same level as Windows, that would be great (my main use case for TPM-based encryption is a - relatively - hassle-free way to have FDE for my personal computers).

That being said, the error message on a Lenovo Thinkpad E16 (Gen2, AMD) is slightly more encouraging, but there still seems to be a blocker:

This platform may be suitable for FDE if the following problem is fixed:
error with TPM2 device: one or more of the TPM hierarchies is already owned:

  • TPM_RH_LOCKOUT has an authorization value
  • TPM_RH_LOCKOUT has an authorization policy

Edit:

After finishing the setup of said Thinkpads, it seems there are unfortunately other issues created by Secure Boot. I was seeing lockups after periods of inactivity (I suspect when the system was trying to switch off the screen), accompanied by a series of AMD GPU-related errors in the journalctl log. After disabling Secure Boot, I was unable to reproduce these lockups.

1 Like
41

This message on the contrary is announcing that the installer will allowing you to clear out the TPM and let ubuntu owning it. Was it not the case for you?