Cannot boot on 24.04 with TPM encryption

Tested on a Maingear Vector Pro 2 I have, it is able to boot fine on the first boot but after updating and rebooting, it prompts for the recovery password again.

Tested on the Dell XPS 9530 15" and it has the same issue as my desktop where it immediately asks for recovery password on first boot.

Looks like the following GitHub issues are relevant as well:
https://github.com/canonical/ubuntu-desktop-provision/issues/577
https://github.com/canonical/ubuntu-desktop-installer/issues/2369

Also this is still happening on the daily image released today for 24.04.

Also still seeing this on the daily build 4/8 and 4/9.

Thanks for the report.
We need a capture of the logs from /var/log/installer to debug.

I have this exact issue with a Lenovo Yoga 9 laptop. It seems that the TPM goes in DA lockout mode on nearly every boot as I have always had to clear it manually before being able to install Ubuntu with TPM encryption. Lenovo's BIOS does not have any meaningful settings regarding TPM and TPM works as it should in Windows. It would be nice to be able to check the recovery password during the installation process as it is now possible to end up in a state where Ubuntu is permanently unbootable immediately after installation.

I think this should be put into the FDE specific bug reports link[1] shown in the 24.04 Release Notes[2].
As this is making TPM-backed FDE almost unusable.

[1] https://bugs.launchpad.net/bugs/+bugs?field.searchtext=&orderby=-importance&field.status%3Alist=NEW&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_commenter=&field.subscriber=&field.tag=fde&field.tags_combinator=ANY&field.status_upstream-empty-marker=1&field.has_cve.used=&field.omit_dupes.used=&field.omit_dupes=on&field.affects_me.used=&field.has_patch.used=&field.has_branches.used=&field.has_branches=on&field.has_no_branches.used=&field.has_no_branches=on&field.has_blueprints.used=&field.has_blueprints=on&field.has_no_blueprints.used=&field.has_no_blueprints=on&search=Search
[2] https://discourse.ubuntu.com/t/noble-numbat-release-notes/39890

Same on my Lenovo T14 gen 4 AMD

I attached sosreport from liveiso

Also var log from the /target OS

Seems I found workaround/solution for that. I needed to disable Absolute Persistence Module Activation in the EUFI config. See the screenshot.

After that previously install TPM based installation started to working.

I am blocked on using "Hardware Backed Encryption" installation procedure also. The repeatable experience is described best in the duplicate https://bugs.launchpad.net/ubuntu-desktop-provision/+bug/2063963

I have a Lenovo Thinkpad P1Gen6 with BIOS Version N3ZET41W (1.28). I upgraded from BIOS 1.16 which had the same problem.

Also worth noting when connected to the internet, the installer is updated to the latest with no effect.

I've disabled Absolute Persistence Module Activation without effect.

I'm using image: ubuntu-24.04-desktop-amd64.iso 2024-04-24 11:29

I retested again today on the ASUS ROG X670E Crosshair after updating BIOS to 2120 (Beta) which primarily updates AGESA firmware to 1.2.0.0, and TPM encryption works now!

Not sure if this was an AMD or ASUS specific issue but it's resolved now at least on my hardware.

Commenting to add another data point. We are running into the same issue with the Framework 13 with the AMD 7840U on the latest bios version 3.05 which includes AMD AGESA 1.1.0.2a.

Adding additional context:

We tested again today with the new Ubuntu 24.04.1 release ISO. While the install with TPM-backed encryption does work fine on an intel system, the same issue persists on AMD systems such as the Framework 13 AMD 7840U.

However, compared to 24.04 there is now more information shown during boot:

```
[ 2.893939] snap-bootstrap[315]: error: cannot read key data: open /run/mnt/ubuntu-boot/device/fde/ubuntu-data.sealed-key: no such file or directory
[FAILED] Failed to start snap-initramfs-mounts.service - Mount initial filesystems.
[DEPEND] Dependency failed for initrd-root-device.target - Initrd Root Device.
[FAILED] Failed to mount sysroot.mount - /sysroot.
[DEPEND] Dependency failed for populate-writable.service.
[DEPEND] Dependency failed for sysroot-writable.mount - /sysroot/writable.
Dependency failed for sysroot-writable.mount - /sysroot/writable.
```

This seems to mirror the experience in duplicate bug #2063963

We have performed more testing, of note this issue seems to be limited to AMD systems in our testing.

The following systems appear to WORK without issue (when absolute anti-theft is disabled)

- Lenovo Thinkpad T480s, 8th Gen Intel Core i7-8650U
- Dell XPS 13 9310, 11th Gen Intel Core i7-1165g7
- Dell XPS 13 9315, 12th Gen Intel Core i7-1250U
- Dell Precision 5470, 12th Gen Intel Core i7-12800H
- Framework 13, Core Ultra 7 155H

Based on this testing where we observed the feature working across multiple laptop vendors and generations of Intel CPUs, it seems safe to assume this is an AMD specific issue as noted by others and noted by the experience of nexusprism when upgrading to a newer BIOS on their AMD system.

Additionally, through our support contract, Canonical has indicated the following;

> [...] This is marked as an "experimental feature" in the installer and the release notes, so it is not something that is expected to work on all hardware. [...] this is not something that is expected to be resolved in the near term

This is very disheartening to see, and from an outsider perspective would seem to indicate this is being de-prioritised due to it only impacting AMD systems.

@glitchsecure Did you test Ubuntu 24.10 in the event some random change magically fixed it somehow?

Also did Framework put out any newer BIOS updates? I'm assuming it has something to do with AMD's fTPM implementation which got fixed in a newer AGESA version.

@nexusprism We have not tested 24.10, though it's unlikely to resolve this.

No new BIOS Updates are available for the AMD version of the Framework 13 yet. 3.05 is still the latest and what we used in testing.

From support conversations, initially they were hoping to have a new release at the end of September with a newer AMD PI version, but that is now postponed with no guarantee for a release date or if it will resolve this issue. Keeping our fingers crossed it'll come at the end of October, but in the meantime we are pivoting to using the Intel Core Ultra versions pending RMA of some of our unopened AMD ones.

We will report back here with the results of testing when the new BIOS for the AMD Framework 13 is generally available.

I’m seeing this issue on an 11th gen intel Framework. And a Lenovo with a 12 Gen Intel.

I have also found that if we use the automated install rather than interactive. It works just fine

@namato01

Are you ensuring you are clearing the TPM and putting it back to an unowned state as well as restoring Secure Boot to defaults each time? This was something we needed to do before each install to prevent issues in addition to disabling Absolute.

Did you see any other errors during the interactive installation?

You should share attach the install logs from both your attended and unattended installs here. We did not notice a difference between using the autoinstall vs interactive installation methods on any of our test devices.

Yes, we are always make sure we reset everything. There are never any errors shown. I will work on grabbing logs from both.

I also would not expect a difference in the unattended and interactive installs either. This is what confused us and we are unsure why it was happening

I have the same issue on Framework 13 AMD. Do you know any way to get recovery keys after installation before reboot?

I'm seeing the same failure on an HP EliteDesk 800 G8 with a Intel Core i5-11500T and TPM 2.0 when installing the minimal desktop image from a live CD, using the TPM enabled LUKS encryption option (Hybrid as the autoinstall YML would call it)

Absolute Persistence / Computrace was permanently disabled via HP Client Management Script Library for PowerShell and confirmed that flag is "YES" for permanent disablement.

HP SureBoot and HP Remote Management are also disabled in UEFI BIOS.

SecureBoot is enabled the the TPM was cleared and a full hard reboot performed before installing.

I have reproduced the error 6 times now, selecting every storage device (2) as the target, trying both connected to network and air-gapped to prevent updates, and with HP Sureboot enabled and disabled. Each time I clear the TPM and hard reboot.

Each time upon first boot after install I get three onscreen errors of /endentire with no verbose information, followed by a request for the encryption recovery key.

On every reinstall

@glitchsecure - It is very much happening with Intel machines too.

@namato01 - Can you share the autoinstal.yml that is working for you? Did you set any portion of the install to interactive?

Guys, we have about 40.000 HP EliteBook series laptops in production. I tested on models 840/850/860 G5/G6/G7/G8/G11, and the issue is the same. I manually selected the TPM FDE experimental option in the installer screen and finished the installation without any error. But on the first boot, it asks me for the recovery password.
Tested with Ubuntu 24.04.1, 24.10 and 25.04 daily.

P.S. To make the "TPM FDE experimental option" option active, I need to reset all security settings in BIOS/UEFI of the mentioned laptop models, this step will initiate the clear TPM option (it will not work if I just clear TPM without resetting all security settings to default).
Also, I updated the BIOS/UEFI version to the latest available (most recent versions are from Dec 2024).

I had the exact same problem (asking for the recovery key on boot after the install) on Thinkpad X1 Carbon Gen 9, trying to install Ubuntu 24.04. I have disabled "Disabled" the "Absolute Persistence", it no longer asks for a key, but only print "/EndEntire" at the top of the screen twice than reboot.

NOTE: I have re-installed the same version with Secure Boot but without disk encryption (confirmed with mokutil) and it works well. This is a disk encryption issue and not Secure Boot / certificate issue.

Does a key need to be added in the UEFI?
Does the "X.509 Canonical Lts. Secure Boot Signing" need to be deleted from the "Forbidden Signature Database (DBX)?
Does something need to be done during the install to make Ubuntu boot in Secure Boot mode?

For me the default was enough. Just set the certificates to the default.

This certificate you mentioned might be old and invalidated if there's
another one already in the list.

On Sun, 2 Feb 2025 at 19:15, Yves Dorfsman <email address hidden>
wrote:

> I had the exact same problem (asking for the recovery key on boot after
> the install) on Thinkpad X1 Carbon Gen 9, trying to install Ubuntu
> 24.04. I have disabled "Disabled" the "Absolute Persistence", it no
> longer asks for a key, but only print "/EndEntire" at the top of the
> screen twice than reboot.
>
> Does a key need to be added in the UEFI?
> Does the "X.509 Canonical Lts. Secure Boot Signing" need to be deleted
> from the "Forbidden Signature Database (DBX)?
> Does something need to be done during the install to make Ubuntu boot in
> Secure Boot mode?
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/2058147
>
> Title:
> Cannot boot on 24.04 with TPM encryption
>
> Status in subiquity:
> Confirmed
> Status in ubuntu-desktop-provision:
> Confirmed
>
> Bug description:
> I installed the daily 24.04 ISO to a spare SSD with TPM encryption,
> and on first boot it asks me for the recovery password. This also
> happens on 23.10 with ubuntu-desktop-installer.
>
> Secure Boot is enabled in BIOS and TPM was cleared prior to
> installation (to get rid of the DA lockout mode error).
>
> Hardware:
> AMD Ryzen 9 7950X
> ASUS X670E Crosshair Hero
> 96GB DDR5
> RX 7900 XTX
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/subiquity/+bug/2058147/+subscriptions
>
>

--
[image: Canonical-20th-anniversary]

Bartosz Woronicz

Field Engineer

Email:

<email address hidden>

Location:

Poland

Mobile:

+48 510498590

canonical.com

ubuntu.com

I can confirm that the Secure Boot + LVM + LUKS encryption works perfectly on the HP EliteBook 840/850/860 G5/G6/G7/G8/G11 series!
The issue only applies to the TPM FDE option.

At the same time, I can use the TPM FDE option without issues on Oracle VirtualBox v7.1.2 and 7.1.4 (7.1.6 is buggy).
The host machines are Windows 11 Pro with Intel 11-14 gen CPUs, and the guest OSs are Ubuntu 24.04.1, Ubuntu 24.10, and Ubuntu 25.04 daily.
I just wondering, why I can use TPM FDE only on VMs and have no success on any of my HP devices?

Hi all, I would suggest that this bug needs further Canonical investigation. When they prioritise it, hopefully there will be some data here to support it.

From what I can tell, the root cause is: when Ubuntu installs with TPM encryption, the installer needs to predict what the value of the TPM will be (i.e. "the contents of a PCR"). It then "seals" the encryption key to that value.

If its prediction is wrong, then on first boot, it won't be able to unseal the encryption key. Then it won't automatically unlock and will ask for the recovery key.

There are several reasons why the prediction is wrong, the most likely is because of hardware or firmware defects in the TPM. (Most vendors only test their TPM to make sure that Windows will boot...) Unfortunately there are many ways this can happen, and vendors are not motivated to fix them, especially for older hardware.

The reason it works in VirtualBox is because any defects in their virtual TPM have been reported and fixed. And probably because Canonical tests with it.

I ran a tool that Canonical wrote, I think it uses the same algorithm as the FDE installer: https://github.com/canonical/tcglog-parser/

I got errors like this (there were much more) which don't give me much hope:

*** FAIL ***: The following EV_EFI_BOOT_SERVICES_APPLICATION events contain digests that might be invalid:
        - Event 2 in PCR 4 (/boot/efi/EFI/ubuntu/grubx64.efi) has a digest for alg TPM_ALG_SHA1 that matches the file digest rather than the PE image digest (got: cc99a5ae9567ad6862fa09eecb9a1e82d45d7f1f, expected: ec49599026c979912d8f18cfd4b260516a4d4ac1)
        - Event 2 in PCR 4 (/boot/efi/EFI/ubuntu/grubx64.efi) has a digest for alg TPM_ALG_SHA256 that matches the file digest rather than the PE image digest (got: 076ceb4824b4bc71e898aaf10cefb738f4eb15efc5e6e951c150c1a265a47d36, expected: 5e8cb75acdf8e09e5fc14cc2d6ce0c2288af208976d97309851c661e91ec1e03)
        - Event 3 in PCR 4 (/boot/vmlinuz-6.8.0-41-generic) has a digest for alg TPM_ALG_SHA256 that matches the file digest rather than the PE image digest (got: 1e894dc26a939a7cb408ba8366e101f5572a5f85a90a6d74ab4cb55211460306, expected: d1e12ad054456cd2c354257f65df820ed2a6dc1901de8d2b173376a7a190fd02)
  - Event 3 in PCR 4 (/boot/vmlinuz-6.8.0-41-generic) has a digest for alg TPM_ALG_SHA1 that matches the file digest rather than the PE image digest (got: 11fa787e8af15392b2107e64562de00bf9469079, expected: b53e9b86332f33b755ea676d48b900b4e6936d06)
  Event digests that don't correspond to any PE image might be caused by a bug in the firmware or bootloader code responsible for performing the measurements, or might be because the image was loaded from a location that is not currently mounted at an expected path (/boot,/cdrom/EFI,/cdrom/casper), in which case it is not possible to determine if the digests are correct. The presence of file digests rather than PE image digests might be because the measuring bootloader is using the 1.2 version of the TCG EFI Protocol Specification rather than the 2.0 version (which could be because it is not provided by the firmware). It could also be because the measuring bootloader does not pass the appropriate flag to the firmwar...

I wanted to provide another data point here. I have similar issues described herein, but not on a laptop and without Absolute Persistence being involved. I've attached my tcglog-dump output in case it is useful.

My motherboard is an "Asus ROG STRIX Z790-A Gaming WiFi D4". Back when 24.04 LTS originally released, I was able to successfully do a TPM-backed FDE install without issues. For whatever reason, I ended up needing to reinstall and ever since then have not been able to replicate my early success. I now get stuck in the recovery keys prompt loop after clearing TPM state and doing a reinstall.

Subiquiti logs show the encryption setup appears to succeed. And prior to rebooting after the install, I can see the two expected crypto LUKS partitions `ubuntu-data-enc` and `ubuntu-save-enc` and can see they both have intact LUKS headers. But if I reboot, the disk unlocking presumably fails because I get the recovery keys prompt and I end up in DA lockout mode. I can clear lockout mode using the usual methods and do another install, with the same issue. This also happens after doing tpm clear from within UEFI.

After doing a clear of everything, and a fresh install, before leaving the initial post-install environment, I also built and ran tcglog-dump and wanted to share the info since it was different than Terence's above.

I presume this is something caused by the motherboard/TPM vendor, but I'm quite far out of my depth when it comes to TCG stuff.