TPM Crashed

dootfs · 2026-07-05 04:49:02

Before booting, my computer throws up this message:

"Press Y to reset fTPM, if you have Bitlocker or encryption-enabled system, the system will not boot without a recovery key. Press N to keep previous fTPM record and continue system boot. fTPM will NOT be enabled with new cpu unless fTPM is (previously initialised) you could swap back to the old CPU to recover TPM related keys and data?" YES/NO

Selecting no starts the boot sequence and stops to call for the recovery key associated with the boot volume. Entering that key lets the boot process to continue. Same for the encrypted SWAP space.

In the terminal:

$ systemd-analyze has-tpm2
partial
-firmware
-driver
+system
+subsystem
+libraries

It appears that the tpm is down and that boot falls back to manual unlock instead of the PCR values stored in the TPM.

I'm not sure what the problem is with the TPM. Haven't tried re-enrolling using systemd because it looks like the PCR state is unreachable:

$ systemd-analyze pcrs
System lacks full TPM2 support, not showing PCR state.
NR NAME               
 0 platform-code
 1 platform-config
 2 external-code
 3 external-config
 4 boot-loader-code
 5 boot-loader-config
 6 host-platform
 7 secure-boot-policy
 8 -                  
 9 kernel-initrd
10 ima
11 kernel-boot
12 kernel-config
13 sysexts
14 shim-policy
15 system-identity
16 debug
17 -                  
18 -                  
19 -                  
20 -                  
21 -                  
22 -                  
23 application-support

Other than make a backup, I'm not sure what to do.

How to diagnose the problem? Could it be a hardware problem? How could the firmware break?

cryptearth · 2026-07-05 07:08:51

reset of an in-cpu fTPM is usually required after bios update
otherwise: if you'Re able to unlock by other means just kill the tpm and re-init it and then re-enroll the keys

dootfs · 2026-07-06 01:56:50

So maybe the Firmware TPM got confused by the UEFI update. According to the Dell product support page, there was a critical BIOS update on 12 June 2026. I power cycled the laptop a few times in the ~2 weeks between when the update released and when the error message appeared, so I don't know why it broke when it did.

Let me check the BIOS:

# dmidecode 3.7
Getting SMBIOS data from sysfs.
SMBIOS 3.6.0 present.
Table at 0x

Handle 0x0000, DMI type 0, 26 bytes
Platform Firmware Information
        Vendor: Dell Inc.
        Version: 1.5.1
        Release Date: 07/05/2024

Looks like it's out of date. The update isn't installed, but the TPM got messed up anyway.

Anyway, I would install the BIOS update and just redo the TPM bindings, but I got thrown off trying to download the BIOS update from the Dell website when the .RCV file download link sent me a page of garbled text. The .EXE file is only for Win, so I guess I'll try updating from the BIOS menu.

Probably a good moment to backup everything.

dootfs · 2026-07-09 23:58:22

This error is looking like it's calling for a BIOS update and a TPM reset and re-enroll.

The Dell support page wasn't helpful, but the Arch Wiki points to the fwupd tool.

fwupdmgr works, but it looks like the BIOS/UEFI firmware updates have to get manually applied.

Considering that the BIOS update is listed as 'critical' it's probably a good move to make that update. On the other hand, I'm not seeing an easy way to do that, because I deleted the recovery partition when installing Arch.

The Arch Wiki page for fwupd says in a Note:

Some hardware components may not be covered by fwupd and may require updates to be manually applied (such as downloading the required files, flashing them to a USB stick and then manually applying the update). This is specially the case for motherboard (BIOS/UEFI) firmware updates (which go through a process called "Q-Flash" or similar).

So it looks like I'll have to either skip the BIOS update and just reset the TPM, or get the BIOS file and do a "Q-Flash" - which I don't see anything about on the Wiki.

Well, it can't be that hard. I got a copy of the .RCV file from Dell support after enabling flash. Then formatting a USB drive to fat32. Then all I need to do is put the .RCV file on the drive and reboot into BIOS recovery mode and write the file to firmware. It should be easy, but I'm worried about bricking my laptop, so I have to make a backup.

Once that's done, then the last thing is to reset and re-enroll the TPM so that the system boots without having to unlock the main volume.

Do I have to sign the UKI file again?

I wonder if I could install coreboot instead?

cryptearth · 2026-07-10 01:30:38

my point about SecureBoot: unless you implement it completely - as in: all the way up to user land software and all data user land software interacts with ... like a payment terminal handling customer payment data ... and lock-down the entire system tightly - it doesn't serve any use -> just disable it and don't care about it

dootfs · 2026-07-10 17:26:10

Before this issue, my laptop was configured with LUKS encrypted root partition and swap space, with a signed .efi boot file, with all passwords enrolled with the TPM for quick bootup. I forget if I had secureboot on or off in the UEFI/BIOS settings.

What do you think of the completeness of security in that arrangement? Encrypted user land files and suspended flash memory SWAP plus measured boot.

Ultimately, I could just leave the BIOS outdated with the known vulnerability where the PCR registers stored on the TPM are retained after resetting the BIOS, or whatever the issue.

From Dell support page:

- Fixed the issue where the security keys are not reset after you restore the BIOS settings to default.

Then all I'd have to do is just reset the TPM and redo the bindings, right?

Last edited by dootfs (2026-07-10 17:33:55)

henni · 2026-07-11 05:59:21

I wouldn't assume the TPM hardware has failed yet. Since `systemd-analyze has-tpm2` reports `-firmware` and `-driver`, it looks more like the firmware isn't exposing the TPM correctly than a damaged TPM.

I'd start by checking whether there was a recent BIOS/UEFI update or whether the TPM/fTPM settings were reset. Also check `journalctl -k | grep -i tpm` and `dmesg | grep -iE "tpm|crb|msft"` for firmware or driver errors. If `/dev/tpm0` and `/dev/tpmrm0` are missing, that's another sign the kernel isn't seeing the TPM properly.

If everything worked before and no hardware changed, I'd suspect a firmware configuration issue before blaming the motherboard.

dootfs · 2026-07-11 23:56:09

BIOS update flash didn't work because the 'BIOS_IMG.RCV' file on the USB drive didn't show up in the recovery screen.

Can confirm that the '/dev/tpm0' and '/dev/tpmrm0' are missing. The kernel must not be seeing the TPM. Since no harware changed, how would you address a firmware configuration issue like this?

dootfs · 2026-07-12 21:40:04

Ok, given that the hardware is unchanged, one can assume that it's a firmware issue. For some reason, probably due to a BIOS update pushed from Dell, the firmware suddenly failed to expose the TPM correctly.

No luck with flashing the BIOS_IMG.rcv file from USB drive to board. It just doesn't see the file on the USB drive, so it can't locate the file to write it to the board.

The BIOS can see the /boot partition, so maybe I could put the BIOS_IMG.rcv file somewhere in /boot instead of the USB drive?

Anyway, if I just reset the fTPM, then there shouldn't be a problem as long as I accept the disclosed vulnerability. I won't let an adversary change BIOS settings to default and read my security keys stored on the TPM.

So, I'll just hit yes this time when the error message pops up before booting and let the fTPM reset and then just rebind everything.

dootfs · 2026-07-19 02:53:34

The quest to reflash the BIOS and rebind the TPM continues.

For users with Dell computers, Dell recommends Linux users flash their BIOS following information located here (in short, put the .EXE on a USB stick and use the F12 boot menu to access the firmware's flash utility).

So it looks like you're supposed to use the .EXE file and not the .rcv file that the Dell Support page provides.

Simply putting the .EXE file on a FAT32 USB was all it took to get the BIOS update flashed. That Dell support provides a .rcv file also is what made this so confusing.

The TPM is the next problem.

Before boot, turned on fTPM in BIOS settings, which re-enabled the TPM chip. The boot process still halted to ask for the drive encryption password for root and swap.

Now, with the TPM on, the PCR registers are visible. Then I guess I have to re-enroll the associated volumes.

Just looking at the Secure Boot wiki page

There are certain conditions making for an ideal setup of Secure boot:
1. UEFI considered mostly trusted (despite having some well known criticisms and vulnerabilities[1]) and necessarily protected by a strong password
2. Default manufacturer/third party keys are not in use, as they have been shown to weaken the security model of Secure Boot by a great margin[2]
3. UEFI directly loads a user-signed EFI boot stub-compatible unified kernel image (no boot manager), including microcode (if applicable) and initramfs so as to maintain throughout the boot process the chain of trust established by Secure Boot and reduce the attack surface
4. Use of full drive encryption, so that the tools and files involved in the kernel image creation and signing process cannot be accessed and tampered with by someone having physical access to the machine.
5. Some further improvements may be obtained by using a TPM.

It appears that my security is less than ideal. Though I use the TPM to streamline the boot procedure, use LUKS encryption on the drive, use a signed kernel image, I don't use my own keys, or have a password on the UEFI.

Ok, secureboot status:

$ sbctl status
Installed:	✓ sbctl is installed
Owner GUID:	12345
Setup Mode:	✗ Enabled
Secure Boot:	✗ Disabled
Vendor Keys:	microsoft builtin-db builtin-KEK

Using default microsoft keys and those keys were used to sign the boot files.

$ sbctl verify
Verifying file database and EFI images in /boot...
✓ /boot/EFI/BOOT/BOOTX64.EFI is signed
✓ /boot/EFI/systemd/systemd-bootx64.efi is signed
✓ /boot/EFI/Linux/arch-linux.efi is signed
failed to verify file /boot/EFI/dell/bios/recovery/BIOS_CUR.rcv: 
failed parsing pkcs7 signature from binary:
failed parsing authenticode: 
failed parsing certificates:
failed parsing certificates: 
x509:
negative serial number
✓ /boot/vmlinuz-linux is signed

I wonder why it failed to verify the BIOS_CUR.rcv file? I just installed that one from Dell. I guess the other fails are normal.

So I need to create new keys and re-sign the files without locking myself out. Where to start with that? cryptenroll? efitools? sbctl?

seth · 2026-07-19 06:44:47

Are you running into the same errors as https://github.com/systemd/systemd/issues/42725 ?

dootfs · 2026-07-19 19:09:54

Some of the same errors appear:

$ systemctl list-units --failed
  UNIT                             LOAD   ACTIVE SUB    DESCRIPTION                                       
● systemd-cryptsetup@swap.service  loaded failed failed Cryptography Setup for swap
● systemd-pcrlogin@1000.service    loaded failed failed TPM NvPCR Measurement of User Record for UID 1000
● systemd-pcrlogin@60578.service   loaded failed failed TPM NvPCR Measurement of User Record for UID 60578
● systemd-pcrproduct.service       loaded failed failed TPM NvPCR Product ID Measurement
● systemd-tpm2-setup-early.service loaded failed failed Early TPM SRK Setup
● systemd-tpm2-setup.service       loaded failed failed TPM SRK Setup

The journal shows that the stored PCR credentials are untrusted and the TPM fails on measurement:

$ journalctl -b -g nvpcr
Jul 19 11:18:07 archlinux systemd[1]: Received untrusted credentials: nvpcr-anchor.953e262aaff14470ab778e2b060483a8
Jul 19 11:18:24 vbqn systemd[1]: Received untrusted credentials: nvpcr-anchor.953e262aaff14470ab778e2b060483a8
Jul 19 11:18:25 vbqn systemd[1]: TPM PCR NvPCR Initialization Separator skipped, unmet condition check ConditionPathExists=/etc/initrd-release
Jul 19 11:18:25 vbqn systemd[1]: Starting TPM NvPCR Product ID Measurement...
Jul 19 11:18:25 vbqn systemd[1]: Failed to start TPM NvPCR Product ID Measurement.
Jul 19 11:18:30 vbqn systemd[1]: TPM PCR NvPCR Initialization Separator skipped, unmet condition check ConditionPathExists=/etc/initrd-release
Jul 19 11:18:30 vbqn systemd[1]: Starting TPM NvPCR Product ID Measurement...
Jul 19 11:18:30 vbqn systemd[1]: Failed to start TPM NvPCR Product ID Measurement.
Jul 19 11:18:31 vbqn systemd[1]: TPM PCR NvPCR Initialization Separator skipped, unmet condition check ConditionPathExists=/etc/initrd-release
Jul 19 11:18:31 vbqn systemd[1]: Starting TPM NvPCR Product ID Measurement...
Jul 19 11:18:31 vbqn systemd[1]: Failed to start TPM NvPCR Product ID Measurement.
Jul 19 11:18:49 vbqn systemd[1]: Starting TPM NvPCR Measurement of User Record for UID 60578...
Jul 19 11:18:49 vbqn systemd[1]: Failed to start TPM NvPCR Measurement of User Record for UID 60578.
Jul 19 11:18:57 vbqn systemd[1]: Starting TPM NvPCR Measurement of User Record for UID 1000...
Jul 19 11:18:57 vbqn systemd[1]: Failed to start TPM NvPCR Measurement of User Record for UID 1000.

Assuming I understand correctly, the BIOS firmware update broke the TPM firmware. The updated BIOS firmware now supports the TPM, but the PCR registers are storing untrusted keys generated by Microsoft. Even though the PCRs stored the old encryption keys for the volumes, the TPM is failing to unlock the volumes.

This suggests that the keys should get regenerated to replace the untrusted PCR credentials left over from before the BIOS update. Then rebuild the UKI so that measured boot will work.

The passwords associated with the boot volumes won't change in the process; only the keys will get regenerated. This means I can safely erase the Microsoft keys, right?

seth · 2026-07-19 19:12:44

Do you get any of the

juin 24 09:12:38 particle-2799-acbd systemd-tpm2-setup[196]: The TPM's NV index space is exhausted, skipping allocation of NvPCR 'verity' and any less important ones: No space left on device
juin 24 09:12:38 particle-2799-acbd systemd-tpm2-setup[196]: Skipped 4 lowest-priority NvPCR(s) because the TPM's NV index space is exhausted, proceeding anyway.

stuff?

dootfs · 2026-07-19 19:48:43

I don't see a match for that when I run:

$ journalctl -b -g nvpcr

The journal doesn't show TPM NV index space errors, only Failed to start TPM NvPCR Product Measurement.

I'm guessing this simply means the PCRs that verify initrd need to get reset?

seth · 2026-07-19 19:51:46

systemctl status systemd-pcrproduct.service systemd-tpm2-setup.service

("why does it fail?")

dootfs · 2026-07-19 20:04:13

$ systemctl status systemd-pcrproduct.service systemd-tpm2-setup.service
× systemd-pcrproduct.service - TPM NvPCR Product ID Measurement
     Loaded: loaded (/usr/lib/systemd/system/systemd-pcrproduct.service; static)
     Active: failed (Result: exit-code) since Sun 2026-07-19 11:18:31 PDT; 1h 37min ago
 Invocation: 037972291790483e8ceb90584ada4d77
       Docs: man:systemd-pcrproduct.service(8)
    Process: 1364 ExecStart=/usr/lib/systemd/systemd-pcrextend --graceful --product-id (code=exited, status=1/FAILURE)
   Main PID: 1364 (code=exited, status=1/FAILURE)
   Mem peak: 2.2M
        CPU: 10ms

Jul 19 11:18:31 vbqn systemd[1]: Starting TPM NvPCR Product ID Measurement...
Jul 19 11:18:31 vbqn systemd-pcrextend[1364]: WARNING:esys:src/tss2-esys/api/Esys_Load.c:324:Esys_Load_Finish() Received TPM Error
Jul 19 11:18:31 vbqn systemd-pcrextend[1364]: ERROR:esys:src/tss2-esys/api/Esys_Load.c:112:Esys_Load() Esys Finish ErrorCode (0x000001df)
Jul 19 11:18:31 vbqn systemd-pcrextend[1364]: TPM key integrity check failed. Key most likely does not belong to this TPM.
Jul 19 11:18:31 vbqn systemd[1]: systemd-pcrproduct.service: Main process exited, code=exited, status=1/FAILURE
Jul 19 11:18:31 vbqn systemd[1]: systemd-pcrproduct.service: Failed with result 'exit-code'.
Jul 19 11:18:31 vbqn systemd[1]: Failed to start TPM NvPCR Product ID Measurement.

× systemd-tpm2-setup.service - TPM SRK Setup
     Loaded: loaded (/usr/lib/systemd/system/systemd-tpm2-setup.service; static)
     Active: failed (Result: exit-code) since Sun 2026-07-19 11:18:32 PDT; 1h 37min ago
 Invocation: d80d79dea2584b65a9cf5e523483fd79
       Docs: man:systemd-tpm2-setup.service(8)
    Process: 1365 ExecStart=/usr/lib/systemd/systemd-tpm2-setup --graceful (code=exited, status=1/FAILURE)
   Main PID: 1365 (code=exited, status=1/FAILURE)
   Mem peak: 2.5M
        CPU: 15ms

Jul 19 11:18:32 vbqn systemd-tpm2-setup[1365]: ERROR:esys:src/tss2-esys/api/Esys_Load.c:112:Esys_Load() Esys Finish ErrorCode (0x000001df)
Jul 19 11:18:32 vbqn systemd-tpm2-setup[1365]: TPM key integrity check failed. Key most likely does not belong to this TPM.
Jul 19 11:18:32 vbqn systemd-tpm2-setup[1365]: Failed to acquire anchor secret: Object is remote
Jul 19 11:18:32 vbqn systemd-tpm2-setup[1365]: WARNING:esys:src/tss2-esys/api/Esys_Load.c:324:Esys_Load_Finish() Received TPM Error
Jul 19 11:18:32 vbqn systemd-tpm2-setup[1365]: ERROR:esys:src/tss2-esys/api/Esys_Load.c:112:Esys_Load() Esys Finish ErrorCode (0x000001df)
Jul 19 11:18:32 vbqn systemd-tpm2-setup[1365]: TPM key integrity check failed. Key most likely does not belong to this TPM.
Jul 19 11:18:32 vbqn systemd-tpm2-setup[1365]: Failed to acquire anchor secret: Object is remote
Jul 19 11:18:32 vbqn systemd[1]: systemd-tpm2-setup.service: Main process exited, code=exited, status=1/FAILURE
Jul 19 11:18:32 vbqn systemd[1]: systemd-tpm2-setup.service: Failed with result 'exit-code'.
Jul 19 11:18:32 vbqn systemd[1]: Failed to start TPM SRK Setup.

The problem looks like:
TPM key integrity check failed. Key most likely does not belong to this TPM.

dootfs · 2026-07-19 20:14:48

I would just use sbctl to create new keys, but the Warning:

"Some firmware is signed and verified with Microsoft's keys when secure boot is enabled. Not validating devices could brick them. To enroll your keys without enrolling Microsoft's, run: sbctl enroll-keys. Only do this if you know what you are doing."

And I don't really know what I'm doing...

But it doesn't show any OpROM signatures:

$ find /sys/devices/ -name rom

seth · 2026-07-19 20:50:34

The update isn't installed, but the TPM got messed up anyway.

This is a regression?
Since the BIOS wasn't updated, check your pacman.log what was updated - notably check for systemd.

You can also https://wiki.archlinux.org/title/Arch_L … cific_date
(Ie. rule out a userspace bug/regression first before messing up the UEFI)

dootfs · 2026-07-19 21:06:31

Oh, it took a few tries, but I got the BIOS flashed eventually.

"Simply putting the .EXE file on a FAT32 USB was all it took to get the BIOS update flashed. That Dell support provides a .rcv file also is what made this so confusing. "

So the UEFI firmware is all updated, but the TPM is still out of whack.

Given the opportunity, I'm trying to get the whole system buttoned up with a non-Microsoft key so that SecureBoot will work better, and then sign the UKI.

Not trying to do a downgrade/package regression.

If I run sbctl to create new keys without using Microsoft's key, that'll lock me out, right? So I have to back up the EFI variables before doing that. Then I can remove the Platform Key and create a new set of keys that'll get stored as PCR values.

Just gotta read through the Secure Boot Wiki entry.

I guess efitools is the way to go to pull the Secure Boot variables that the computer was shipped with.

But when I download efitools and run the command to pull the EFI variables:

$ for var in PK KEK db dbx ; do efi-readvar -v $var -o old_${var}.esl ; done
Variable PK has no entries
Variable KEK, length 3906
Variable db, length 8533
Variable dbx, length 22138

It looks like the Platform Key is missing? Where is the platform key stored?

Last edited by dootfs (2026-07-19 21:12:32)

seth · 2026-07-20 05:57:17

Sanity check: do you dual boot windows?
x-ref, https://bbs.archlinux.org/viewtopic.php?id=314326

dootfs · 2026-07-20 22:02:46

seth wrote:

Sanity check: do you dual boot windows?
x-ref, https://bbs.archlinux.org/viewtopic.php?id=314326

I am running Arch on a Dell laptop. The Windows partitions are all erased. Good question, though.

According to jejb at The Meaning of all the UEFI Keys:

"All of the keys are stored in UEFI secure variables (see section 7.2 of the UEFI specification)."

Although I couldn't find the reference, it appears that keys are stored in the UEFI firmware. Probably the keys can simply be copied out to different locations for backup.

Looking into the arrangement for storing keys safely, it may be better to simply use the Microsoft keys. That way I don't have to worry about setting up the MOK list and shim.

Still confused about where the keys are stored.

Anyway, it looks like I already have immutable keys stored in /sys/firmware/efi/efivars.

$ sudo sbctl verify
Verifying file database and EFI images in /boot...
✓ /boot/EFI/BOOT/BOOTX64.EFI is signed
✓ /boot/EFI/systemd/systemd-bootx64.efi is signed
✓ /boot/EFI/Linux/arch-linux.efi is signed
failed to verify file /boot/EFI/dell/bios/recovery/BIOS_CUR.rcv:
failed parsing pkcs7 signature from binary:
failed parsing authenticode:
failed parsing certificates:
failed parsing certificates:
x509:
negative serial number
✓ /boot/vmlinuz-linux is signed

Ok, then I just need to sign the new BIOS_CUR.rcv file:

$ sudo sbctl sign -s /boot/EFI/dell/bios/recovery/BIOS_CUR.rcv
failed parsing pkcs7 signature from binary:
failed parsing authenticode:
failed parsing certificates:
failed parsing certificates:
x509:
negative serial number

But it doesn't look like it worked. Same set of fails under sbctl verify.

I guess I'll just ignore the new .rcv file added to /boot and just re-enroll the TPM and put a password on the UEFI.

Edit:
Tried turning Secure Boot back on and got locked out. Probably the UEFI won't pick up the boot files because the new BIOS file measures differently from the original. The next move is to re-sign all the boot files.

Last edited by dootfs (2026-07-20 22:40:06)

cryptearth · Yesterday 03:52:42

have you reset the tpm since the bios update? from the errors posted and what comes up when you search for your tpm didn't "crash" but rather somehow got "overused" - a tpm has only very limited storage which can get exhausted quickly
also: if you have not reset the tpm after bios update it fails because one of the hashes is the bios itself - which of course got changed by the update

Arch Linux

#1 2026-07-05 04:49:02

TPM Crashed

#2 2026-07-05 07:08:51

Re: TPM Crashed

#3 2026-07-06 01:56:50

Re: TPM Crashed

#4 2026-07-09 23:58:22

Re: TPM Crashed

#5 2026-07-10 01:30:38

Re: TPM Crashed

#6 2026-07-10 17:26:10

Re: TPM Crashed

#7 2026-07-11 05:59:21

Re: TPM Crashed

#8 2026-07-11 23:56:09

Re: TPM Crashed

#9 2026-07-12 21:40:04

Re: TPM Crashed

#10 2026-07-19 02:53:34

Re: TPM Crashed

#11 2026-07-19 06:44:47

Re: TPM Crashed

#12 2026-07-19 19:09:54

Re: TPM Crashed

#13 2026-07-19 19:12:44

Re: TPM Crashed

#14 2026-07-19 19:48:43

Re: TPM Crashed

#15 2026-07-19 19:51:46

Re: TPM Crashed

#16 2026-07-19 20:04:13

Re: TPM Crashed

#17 2026-07-19 20:14:48

Re: TPM Crashed

#18 2026-07-19 20:50:34

Re: TPM Crashed

#19 2026-07-19 21:06:31

Re: TPM Crashed

#20 2026-07-20 05:57:17

Re: TPM Crashed

#21 2026-07-20 22:02:46

Re: TPM Crashed

#22 Yesterday 03:52:42

Re: TPM Crashed

Board footer