IncusOS TPM rebind blocked after BIOS update due to systemd-cryptsetup log message change

IncusOS
, ,
1

PSA: This post was entirely written by AI. I apologize if this breaks any forum rules or seems lazy; I just thought my issue might have been caused by a system bug that could affect others, and I wanted to contribute to the solution since it is now fixed for me.

..

I ran into an issue with IncusOS TPM disk auto-unlock after a BIOS update changed the TPM/PCR measurements.

After the BIOS update, IncusOS started asking for the disk recovery key on every boot. The system can boot successfully after manually entering the recovery key, but TPM auto-unlock no longer works.

When attempting to run:

incus admin os system security tpm-rebind

after booting with the recovery key, the command fails with:

Error: refusing to reset TPM encryption bindings because current state can unlock all volumes

This prevents updating/rebinding the TPM configuration and causes the system to keep prompting for the disk recovery passphrase on every boot.

Affected system

  • IncusOS version: 202606282332
  • Architecture: x86_64
  • systemd version: 257.13-1
  • Hardware: Lenovo system with Discrete TPM 2.0
  • TPM status: ok
  • Secure Boot: enabled
  • System state: fully trusted
  • Trigger: BIOS update / PCR measurement change

BIOS settings were checked and appear correct:

  • TPM 2.0 enabled
  • Discrete TPM selected
  • Clear TPM / Clear TCG Security Feature: No
  • Secure Boot enabled
  • Linux Boot Manager selected manually from F12 boot menu also reproduces the issue

Symptoms

During boot, IncusOS asks for:

Please enter passphrase or recovery key for disk root-x86-64 (root):

After entering the recovery key, the system boots normally.

However, after boot, the security status incorrectly reports the encrypted volumes as unlocked by TPM:

encrypted_volumes:

  • state: unlocked (TPM)
    volume: root
  • state: unlocked (TPM)
    volume: swap

Running TPM rebind then fails with:

Error: refusing to reset TPM encryption bindings because current state can unlock all volumes

Root cause analysis

The issue appears to be in:

mkosi.packages/initrd-utils/initrd-finalize-luks-state.sh

The script determines whether the TPM successfully unlocked the root partition by searching the journal for a specific older systemd-cryptsetup log message:

if journalctl -b -g “TPM2 operation failed, falling back to traditional unlocking” -u systemd-cryptsetup@root.service > /dev/null 2>&1; then

A recovery password was used to unlock the volume

printf “\07\00\00\00\00\00\00\01” > /sys/firmware/efi/efivars/IncusOSTPMState-12f075e0-2d07-493d-811a-00920a72c04c
else

The TPM was able to unlock the volume

printf “\07\00\00\00\00\00\00\00” > /sys/firmware/efi/efivars/IncusOSTPMState-12f075e0-2d07-493d-811a-00920a72c04c
fi

On systems running newer versions of systemd, for example systemd v257+, systemd-cryptsetup no longer logs:

TPM2 operation failed, falling back to traditional unlocking

when the TPM unseal fails.

Instead, the logs now look like this:

systemd-cryptsetup: Failed to unseal secret using TPM2: Operation not permitted
systemd-cryptsetup: No valid TPM2 token data found.
systemd-cryptsetup: No TPM2 metadata matching the current system state found in LUKS2 header, falling back to traditional unlocking.

Because the old string is no longer present:

  1. journalctl -b -g “TPM2 operation failed, falling back to traditional unlocking” fails to match.

  2. initrd-finalize-luks-state.sh falls into the else branch.

  3. It incorrectly writes TPM success to IncusOSTPMState:

    07 00 00 00 00 00 00 00

  4. After boot, IncusOS reads IncusOSTPMState and believes TPM unlock succeeded.

  5. incus-osd then refuses to run tpm-rebind because it believes the current TPM state can already unlock all volumes.

So the system is in a contradictory state:

  • Early boot proves TPM unlock failed and requires the recovery key.
  • Runtime IncusOS status incorrectly says the volumes were unlocked by TPM.
  • TPM rebind is blocked by the incorrect EFI variable state.

Relevant systemd-cryptsetup logs

From the affected boot:

systemd: Starting systemd-cryptsetup@root.service - Cryptography Setup for root…
systemd-cryptsetup: Set cipher aes, mode xts-plain64, key size 512 bits for device /dev/gpt-auto-root-luks.
systemd-cryptsetup: Automatically discovered security TPM2 token unlocks volume.
systemd-cryptsetup: Failed to unseal secret using TPM2: Operation not permitted
systemd-cryptsetup: No valid TPM2 token data found.
systemd-cryptsetup: No TPM2 metadata matching the current system state found in LUKS2 header, falling back to traditional unlocking.

The system then waits for the user to enter the recovery key before completing boot.

IncusOSTPMState EFI variable

The EFI variable showed TPM success even though TPM unlock had failed:

od -t x1 /sys/firmware/efi/efivars/IncusOSTPMState-12f075e0-2d07-493d-811a-00920a72c04c

Output:

0000000 07 00 00 00 00 00 00 00
0000010

The last byte is 00, indicating TPM success, but the boot logs show that TPM unseal failed and traditional recovery-key unlocking was required.

Output of incus admin os system security show

Redacted output:

config:
encryption_recovery_keys:

  • [REDACTED]
    state:
    drive_recovery_keys: {}
    encrypted_volumes:
  • state: unlocked (TPM)
    volume: root
  • state: unlocked (TPM)
    volume: swap
    encryption_recovery_keys_retrieved: true
    pool_recovery_keys:
    local: [REDACTED]
    secure_boot_certificates:
  • fingerprint: 26dce4dbb3de2d72bd16ae91a85cfeda84535317d3ee77e0d4b2d65e714cf111
    issuer: CN=Incus OS - Secure Boot E1,O=Linux Containers
    subject: CN=Incus OS - Secure Boot PK R1,O=Linux Containers
    type: PK
  • fingerprint: 9a42866f496834bde7e1b26a862b1e1b6dea7b78b91a948aecfc4e6ef79ea6c1
    issuer: CN=Incus OS - Secure Boot E1,O=Linux Containers
    subject: CN=Incus OS - Secure Boot KEK R1,O=Linux Containers
    type: KEK
  • fingerprint: 21b6f423cf80fe6c436dfea0683460312f276debe2a14285bfdc22da2d00fc20
    issuer: CN=Incus OS - Secure Boot E1,O=Linux Containers
    subject: CN=Incus OS - Secure Boot 2025 R1,O=Linux Containers
    type: db
  • fingerprint: 2243c49fcf6f84fe670f100ecafa801389dc207536cb9ca87aa2c062ddebfde5
    issuer: CN=Incus OS - Secure Boot E1,O=Linux Containers
    subject: CN=Incus OS - Secure Boot 2026 R1,O=Linux Containers
    type: db
  • fingerprint: 48e99b991f57fc52f76149599bff0a58c47154229b9f8d603ac40d3500248507
    issuer: CN=Microsoft Corporation Third Party Marketplace Root,O=Microsoft Corporation,L=Redmond,ST=Washington,C=US
    subject: CN=Microsoft Corporation UEFI CA 2011,O=Microsoft Corporation,L=Redmond,ST=Washington,C=US
    type: db
    secure_boot_enabled: true
    system_state_is_trusted: true
    system_state_status: system state is fully trusted
    tpm_status: ok

Workaround used

The stale/incorrect EFI variable was removed manually.

Because IncusOS is immutable, this was done using a temporary privileged container with the host EFI variable directory mounted.

The problematic variable was:

/sys/firmware/efi/efivars/IncusOSTPMState-12f075e0-2d07-493d-811a-00920a72c04c

Commands used inside the helper environment:

chattr -i /mnt/IncusOSTPMState-12f075e0-2d07-493d-811a-00920a72c04c
rm -f /mnt/IncusOSTPMState-12f075e0-2d07-493d-811a-00920a72c04c

After deleting the stale EFI variable, running:

incus admin os system security tpm-rebind

was allowed to proceed.

After completing the rebind and rebooting, TPM auto-unlock worked again.

Expected behavior

If TPM unlock fails and the system falls back to recovery-key unlocking, IncusOS should record the TPM state as failed, even with newer systemd log messages.

Then:

incus admin os system security tpm-rebind

should be allowed.

Actual behavior

Because the journal grep does not match newer systemd-cryptsetup messages, IncusOS incorrectly records TPM unlock success. This causes tpm-rebind to refuse to run, leaving the user stuck entering the recovery key on every boot.

Possible fix

The detection logic should probably not rely on a single human-readable systemd log string.

At minimum, the grep should also match newer systemd v257+ messages such as:

Failed to unseal secret using TPM2
No valid TPM2 token data found
No TPM2 metadata matching the current system state found in LUKS2 header, falling back to traditional unlocking

A more robust fix might be to detect recovery-key fallback through a machine-readable state instead of grepping journal text.

2

Thanks for being transparent about this. :slightly_smiling_face: A mini-novella isn’t really useful, as we are familiar with the code and how it’s supposed to operate. The following excerpts from your original post would have been a great report of the issue:

That tells us concretely what error you’re encountering, the version of IncusOS, and importantly actual log messages.

From the report, it looks like your BIOS update performed a full reset of your TPM, including the public key that was bound to it and referenced in the LUKS encryption header. This is then causing a different error message which should be properly recognized. (The current logic catches an error when the TPM’s computed PCRs are different, but it hasn’t been fully reset like in your case.)

Your LLM helpfully gave you an incorrect red herring “solution”, as the major version of systemd hasn’t changed. IncusOS is built from Debian stable (currently trixie, which has used systemd v257 from its first day of release).

3