"Cannot verify TPM rollback protection" and unable to boot or reset TPM

V540TU with recently updated Dasharo coreboot+heads v0.9.1

I think this is my first attempted reboot after updating the firmware.

I get the red screen with “ERROR: TPM State Inconsistent”

Cannot verify TPM rollback protection

Recommended first step:

  • Show integrity Report (TOTP/HOTP + /boot)

So when I do the integrity report, it says:

Measured Integrity Report

Date: 2026-06-25 16:…

TOTP: 2026-06-25 16:…

HOTP: Nitrokey 3 CONNECTED (presence confirmed)

Boot signature (/boot/kexec.sig): VERIFIED

ROM-fused public key authenticated /boot/kexec.sig - all /boot files match the signed hashes.

Boot files: OK

Nitrokey 3 key: DONGLE MATCHES ROM-TRUSTED KEY

Action: No signature fix needed.

I take this to mean that the stuff in /boot has been signed by the inserted nitrokey.

OK, so I think maybe I can simply boot unsafely. But when I Continue to main menu → Default Boot then I see this on the console (some of which is leftover from before getting into this menu)

HEADS

>> Extracting GPG keyring, trustdb, and board configuration from firmware

OK Board keys and configuration loaded from firmware

Quiet mode enabled from board configuration: refer to ‘/tmp/debug.log’ for boot measurements traces

>> Loading OS distribution signing keys for ISO boot authentication

>> Adding user GPG key as trusted for ISO signing

***** Normal boot: /bin/gui-init.sh

*** WARNING: TPM reset required: TPM integrity counter cannot be read. Possible cause: TPM was swapped or reset. This could indiate a TPM swap attack. RESET TPM from GUI (Options → TPM/TOTP/HOTP Options → Reset the TPM). *

>> Preparing Measured Integrity Report - hashing and verifying /boot

>> Checking Nitrokey 3 presence

OK Nitrokey 3 detected

OK Nitrokey 3 firmware: v1.8.3 (Secrets App: v4.14) (minimum: v1.8.3, latest known: v1.8.3)

>> Verifying /boot detatched signature

OK GPG signature on kexec boot params verified

>> Verifying signing key on Nitrokey 3

OK GPG signature on kexec boot params verified

*** WARNING: Hash of TPM2 primary key handle mismatch - if you have not intentionally regenerated the TPM2 primary key, your system may have been compromised *

!!! ERROR: Hash of TPM2 primary key handle mismatch (/boot/kexec_primhdl_hash.txt). If you did not intentionally regenerate the TMP2 primary key, this may indicate compromise. !!!

Press Enter to continue…

So I press Enter, it prints a note about filing a bug report with debug logs, then says

*** WARNING: Failed default boot *

>> Starting recovery shell

bash-5.1#

And then I manually power it off and rebooted and… weird, now it gives me semi-success with a Boot Hash Mismatch on (expected Xen updates). Previously it would go back to the “cannot verify TPM…” and even if I selected the option to reset the TPM it would not work. Now I seem to be on track…

The following files failed the verification process:

./efi/EFI/qubes/xen-4.19.4.efi

./efi/EFI/qubes/xen.fi

./xen-4.19.4.gz

(new) ./loader

(new) ./loader/entries

This could indicate a compromise!

Would you like to investigate…

When I investigate it says “Detached signature on /boot/kexec.sig verified successfully.” as part of the menu.

And now it booted OK after I signed those as usual after an update.

What was all the fuss about the TPM and why did it not work for three or four boots then suddenly work?

And just to be sure, I powered down and booted again. Now I get back to “ERROR: TPM State Inconsistent" as above. This time when I selected TPM reset from this first menu it seems to work (unlike the TPM reset from the main menu). Then despite entering the app pin correctly three times and touching at the right moment it did not succeed in setting HOTP secret on NitroKey 3. Sigh. Trying again. When I do the same reboot (also with same TPM error again) and put in the right app passphrase, it seemed to boot fine. I will try rebooting again after all that and see what happens.

Again on reboot I get “ERROR: TPM State Inconsistent” and “Cannot verify TPM rollback protection”

It cannot be correct to need to do a TPM reset on every boot, right?

Maybe this is TPM reset is complex · Issue #1337 · linuxboot/heads · GitHub

TPM reset is complex #1337

This and the message suggest that after resetting the TPM then I need to generate TOTP/HOTP secret and/or reseal?

Weird. It just booted into the secondary disk which happens to be PureOS, a straight copy of my old Librem laptop’s disk. Could this be the issue? Two disks, both configured with heads? Why would it boot into the second disk?

After it booted into the second disk, within that OS I marked the second disk’s partition as not bootable using fdisk though I do not think this was as important as telling Dasharo Heads the default /boot and root disks.

  1. Changed the /boot devide to /dev/nvme0n1p2
  2. Changed the root device to /dev/nvme0n1p1 (not as certain that this is correct but seems to work)
  3. Save the current configuration to the running BIOS

Now I am reliably booting into the first (zero-eth) NVMe disk with Qubes as expected without nasty TPM warnings.

1 Like

It could be, yes. I’ve had it that dasharo switched NVME device enumeration. A drive nvme0n* suddenly becoming nvme1n* and vice versa. That would explain why you had the initial mismatch.

The device order does not matter with UEFI. Having the root device first only makes it cumbersome, if you need re-partitioning, because the boot partition is “in the way”.

What not matters anymore with UEFI is the bootable flag. The firmware just looks for the efi partition label of the first device it enumerates (or which you choose from the boot menu). And since you had two devices with one, it picked the first. I’m not sure from memory, but think you can mark one device as the default boot device. This could have avoided it booting the second device.