You are not logged in.
Pages: 1
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
+librariesIt 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-supportOther 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?
Offline
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
Offline
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/2024Looks 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.
Offline
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?
Offline
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
Offline
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 (Today 17:33:55)
Offline
Pages: 1