TPM2 errors after updates - TPM key integrity check failed

Foucault · 2026-09-17 20:54:34

Hello!

After recent update the systemd TPM services fail to start on boot. These are the systemd-tpm2-setup{,-early} and the systemd-pcr{product,login} services. All four show the same error ERROR:esys:src/tss2-esys/api/Esys_Load.c:110:Esys_Load() Esys Finish ErrorCode (0x000001df) followed by either Failed to acquire anchor secret: Object is remote or Could not extend NvPCR: Object is remote.

I've seen a few threads related to similar errors but apparently none of the proposed solutions seem to work. These include setting the PCR policies, removing the nvpcr trust anchor or even clearing the TPM.

I am not using TPM for LUKS but it is causing libvirtd to fail which is my main issue. I know the same archwiki page recommends removing the encryption key but unsurprisingly this does not help, as it does not address the underlying issue.

Any ideas to debug are welcome

Output of systemd-analyze pcrs

NR NAME                SHA256
 0 platform-code       8d994f0bc5a2f4032ecc0558567961261cf97322741c4bc42f45363a6d15f3ed
 1 platform-config     f1922520f593fbaf688a5412dd10cb410268eec5298520306657aecbe83d62cf
 2 external-code       2419e88f7b54a47565afb8e181a5123191fd7d60303b7ca989af5dc5e4665715
 3 external-config     8d22c738fcd1730fb0789cb09c0f72a0012baa3ea867723b26772c9ca0ae6571
 4 boot-loader-code    36ed2f313ecb073c7a1d803f7784a1a054099899a1a21b0a1c65c3ff487fb2c5
 5 boot-loader-config  4116acbcf75b4743609ac940520ae48d5198eed35fbda70264ef4222900dfaf8
 6 host-platform       8d22c738fcd1730fb0789cb09c0f72a0012baa3ea867723b26772c9ca0ae6571
 7 secure-boot-policy  f35abd9f314f558534a965429ce13ff8025591a719823c8ee49a23f90a221f9d
 8 -                   0000000000000000000000000000000000000000000000000000000000000000
 9 kernel-initrd       50720e99cc183b441fcad206e0ffdb597eb073cc58b60d070bc4684f181ef2a3
10 ima                 0000000000000000000000000000000000000000000000000000000000000000
11 kernel-boot         f91a54efee77d4338ea5be5b99d1f8f1e39f7a386ee9c110f900df5eab7b8f02
12 kernel-config       2c48e14adb9bb9a77792f92162149ebf7807d6b0c71294df31c6fe6d67ef6332
13 sysexts             3345a4e7857aa5ae65e97702ade84a3755fd6144724779536b5773128676c99c
14 shim-policy         3345a4e7857aa5ae65e97702ade84a3755fd6144724779536b5773128676c99c
15 system-identity     b75382d0117e089627160d6056bf982cafd577ecc3cc4100492149357a544452
16 debug               0000000000000000000000000000000000000000000000000000000000000000
17 -                   ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
18 -                   ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
19 -                   ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
20 -                   ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
21 -                   ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
22 -                   ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
23 application-support 0000000000000000000000000000000000000000000000000000000000000000

Output of systemd-analyze nvpcrs

NAME         NVINDEX PRIORITY VALUE
verity     0x1d10202      300 -
hardware   0x1d10200      500 -
cryptsetup 0x1d10201      700 -
login      0x1d10203      800 -

Output of systemd-analyze has-tpm2

yes
+firmware
+driver
+system
+subsystem
+libraries
  +libtss2-esys.so.0
  +libtss2-rc.so.0

Content of /etc/kernel/uki.conf - keys generated with ukify genkey

[PCRSignature:all]
PCRPrivateKey=/etc/systemd/tpm2-pcr-private-key.pem
PCRPublicKey=/etc/systemd/tpm2-pcr-public-key.pem

[PCRSignature:initrd]
Phases=enter-initrd
PCRPrivateKey=/etc/systemd/tpm2-pcr-private-key-initrd.pem
PCRPublicKey=/etc/systemd/tpm2-pcr-public-key-initrd.pem

Possibly related output of bootctl status

System:
      Firmware: UEFI 2.70 (American Megatrends 5.17)
 Firmware Arch: x64
   Secure Boot: disabled (setup)
  TPM2 Support: yes
  Measured UKI: yes
   Measured OS: yes
  Boot into FW: supported
 Platform Lang: en_US.UTF-8

Current Boot Loader:
        Product: systemd-boot 261.3-1-arch
       Features: ✓ Boot counting
                 ✓ Menu timeout control
                 ✓ One-shot menu timeout control
                 ✓ Default entry control
                 ✓ One-shot entry control
                 ✓ Support for XBOOTLDR partition
                 ✓ Support for passing random seed to OS
                 ✓ Load drop-in drivers
                 ✓ Support Type #1 sort-key field
                 ✓ Support @saved pseudo-entry
                 ✓ Support Type #1 devicetree field
                 ✓ Enroll SecureBoot keys
                 ✓ Retain SHIM protocols
                 ✓ Menu can be disabled
                 ✓ Multi-Profile UKIs are supported
                 ✓ Loader reports network boot URL
                 ✓ Support Type #1 uki field
                 ✓ Support Type #1 uki-url field
                 ✓ Loader reports active TPM2 PCR banks
                 ✓ Loader reports firmware keyboard layout
                 ✓ Loader measures SMBIOS information
      Partition: /dev/disk/by-partuuid/ae68becb-a61e-456e-8358-fac8613e8bb3
         Loader: └─/boot//EFI/SYSTEMD/SYSTEMD-BOOTX64.EFI
Keyboard Layout: n/a (not reported by firmware)
  Current Entry: archlinux-linux.efi

Current Stub:
        Product: systemd-stub 261.3-1-arch
       Features: ✓ Stub reports loader partition information
                 ✓ Stub reports stub partition information
                 ✓ Stub reports network boot URL
                 ✓ Picks up credentials from boot partition
                 ✓ Picks up system extension images from boot partition
                 ✓ Picks up configuration extension images from boot partition
                 ✓ Measures kernel+command line+sysexts
                 ✓ Support for passing random seed to OS
                 ✓ Pick up .cmdline from addons
                 ✓ Pick up .cmdline from SMBIOS Type 11
                 ✓ Pick up .dtb from addons
                 ✓ Stub understands profile selector
                 ✓ Stub measures SMBIOS information
      Partition: /dev/disk/by-partuuid/ae68becb-a61e-456e-8358-fac8613e8bb3
           Stub: └─/EFI/Linux/archlinux-linux.efi

Random Seed:
 System Token: set
       Exists: yes

seth · 2026-09-17 22:50:25

https://bbs.archlinux.org/viewtopic.php?id=314689 ?
Edit, or https://bbs.archlinux.org/viewtopic.php?id=314936 ?

Last edited by seth (2026-09-17 22:53:18)

Foucault · 2026-09-18 10:23:50

I have already tried removing the trust anchor before posting this and it didn't really help. I'm also using mkinitcpio (not booster) for initramfs and if I checked correctly the PCR signature and systemd service are included already in the image. One recommendation I saw here was to re-enroll the TPM but there is nothing to enroll as I'm not using the TPM for LUKS.

I may also be an idiot but it is somewhat difficult for me to follow how the whole trust chain works wrt systemd and TPM as there is no documentation that explains how all the individual parts of the secure computing infrastructure depend on one another (ie systemd, TPM, initrd and PCR). It is possible that I'm missing something.

Last edited by Foucault (2026-09-18 10:28:00)

seth · 2026-09-18 14:56:14

Please post your complete system journal for the boot:

sudo journalctl -b | nc termbin.com 9999

systemd is supposed to print some useful explanation about what went wrong: https://github.com/systemd/systemd/comm … bee33b856c

Foucault · 2026-09-18 15:29:12

Here it is, although I don't think there is much more than the TPM errors in the first post. Lines ~1470ish and ~1740ish.

seth · 2026-09-18 15:40:16

TPM key integrity check failed. Key most likely does not belong to this TPM.

To be sure: https://wiki.archlinux.org/title/Truste … _TPM_reset
You've removed both files, restarted the services and regenerated the initramfs?

Foucault · 2026-09-18 18:07:26

I have indeed removed the nvpcr file /var/lib/systemd/nvpcr/nvpcr-anchor.cred but all tpm2 systemd services still fail to start. Should it be recreated at some point? At the moment there's nothing under /var/lib/systemd/nvpcr.

I also checked that the TPM is not under lockout

Output of tpm2_getcap properties-variable

TPM2_PT_PERMANENT:
  ownerAuthSet:              0
  endorsementAuthSet:        0
  lockoutAuthSet:            0
  reserved1:                 0
  disableClear:              0
  inLockout:                 0
  tpmGeneratedEPS:           1
  reserved2:                 0
TPM2_PT_STARTUP_CLEAR:
  phEnable:                  1
  shEnable:                  1
  ehEnable:                  1
  phEnableNV:                1
  reserved1:                 0
  orderly:                   1
TPM2_PT_HR_NV_INDEX: 0x0
TPM2_PT_HR_LOADED: 0x0
TPM2_PT_HR_LOADED_AVAIL: 0x3
TPM2_PT_HR_ACTIVE: 0x0
TPM2_PT_HR_ACTIVE_AVAIL: 0x40
TPM2_PT_HR_TRANSIENT_AVAIL: 0x6
TPM2_PT_HR_PERSISTENT: 0x1
TPM2_PT_HR_PERSISTENT_AVAIL: 0x6
TPM2_PT_NV_COUNTERS: 0x0
TPM2_PT_NV_COUNTERS_AVAIL: 0x19
TPM2_PT_ALGORITHM_SET: 0x0
TPM2_PT_LOADED_CURVES: 0x3
TPM2_PT_LOCKOUT_COUNTER: 0x0
TPM2_PT_MAX_AUTH_FAIL: 0x3
TPM2_PT_LOCKOUT_INTERVAL: 0x3E8
TPM2_PT_LOCKOUT_RECOVERY: 0x3E8
TPM2_PT_NV_WRITE_RECOVERY: 0x0
TPM2_PT_AUDIT_COUNTER_0: 0x0
TPM2_PT_AUDIT_COUNTER_1: 0x0

Last edited by Foucault (2026-09-18 18:11:11)

seth · 2026-09-18 21:15:26

Should it be recreated at some point?

Yes, however https://bbs.archlinux.org/viewtopic.php … 1#p2293101

seth · 2026-09-19 06:48:32

As for https://gitlab.archlinux.org/archlinux/ … _items/310 I'd still give that a try as well…

Beemo · 2026-09-19 11:11:43

EDIT: Ignore this. nvPCRs are not extended because of the failure to decrypt nvpcr-anchor.cred with TPM. The system has already exited initramfs at this point in the log.

Not sure if it's relevant, "systemd-analyze nvpcrs" shouldn't be empty. From log:

systemd[1]: TPM PCR NvPCR Initialization Separator skipped, unmet condition check ConditionPathExists=/etc/initrd-release

On my system:

❯ sudo lsinitcpio /boot/EFI/Linux/arch-linux.efi | grep etc/initrd-release
etc/initrd-release

https://www.freedesktop.org/software/systemd/man/261/initrd-release.html wrote:

Additionally, the presence of that file means that the system is in the initrd/exitrd phase.

Last edited by Beemo (2026-09-19 11:45:16)

Foucault · 2026-09-19 13:19:51

seth wrote:

As for https://gitlab.archlinux.org/archlinux/ … _items/310 I'd still give that a try as well…

I saw this before, but what does it even mean "re-enrolling" the TPM outside the context of LUKS? From my understanding this assumes the TPM gets unlocked at boot before enrolling can happen anyway.

seth wrote:

Yes, however https://bbs.archlinux.org/viewtopic.php … 1#p2293101

Some progress! Recreating the credentials with systemd-creds on top of the previously removed libvirtd secrets file allowed libvirtd to start. But unfortunately still the systemd-tpm2-* and systemd-pcr* services fail to start with the same cryptic error (of course I rerun mkinitcpio). In case it's important there is still nothing (re)created under /var/lib/systemd/nvpcr.

Honestly this TPM situation is quite baffling, and probably one the few times I've hit such an "undebugable" wall. I'm willing to ascribe this to "my firmware is somehow borked" but it's quite difficult to know if that's actually the reason.

Last edited by Foucault (2026-09-19 13:20:28)

Beemo · 2026-09-19 14:13:51

Yea it seems it's 2 issues.
How nvpcr-anchor.cred works (and it's going to change & be automatically migrated next ver): https://github.com/systemd/systemd/comm … b97b080848

The credential is protected by the TPM with a PCR policy.
The credential is currently only protected by PCR11.

Turns out I have the issue too, but somehow nvPCRs are still extended.
EDIT: nvm a different error, means "already initialized".

TBH how is this sealed with PCR11 when it changes on every update...

p.s. I love how complex and poorly documented systemd is /s

Last edited by Beemo (2026-09-19 15:39:34)

seth · 2026-09-19 14:16:09

I suspect https://man.archlinux.org/man/systemd-tpm2-setup.8 kinda expects key to be enrolled for decrypting the root device?
@Beemo, do you use LUKS?

@Foucault, what if you just disable those services?

Beemo · 2026-09-19 14:20:37

@seth Yes I use LUKS

I noticed the log is missing something like below. The log is perhaps from after the anchor was already deleted?

systemd[1]: Received untrusted credentials: nvpcr-anchor.(random string here)

(However, how is systemd / TPM complaining about the key if there is nothing to decrypt...)

systemd-tpm2-setup[778]: WARNING:esys:src/tss2-esys/api/Esys_Load.c:314:Esys_Load_Finish() Received TPM Error
systemd-tpm2-setup[778]: ERROR:esys:src/tss2-esys/api/Esys_Load.c:110:Esys_Load() Esys Finish ErrorCode (0x000001df)
systemd-tpm2-setup[778]: TPM key integrity check failed. Key most likely does not belong to this TPM.
systemd-tpm2-setup[778]: Failed to acquire anchor secret: Object is remote

What does this say?

$ sudo systemd-creds list --system

Last edited by Beemo (2026-09-19 17:29:19)

Foucault · 2026-09-20 09:33:42

Beemo wrote:

I noticed the log is missing something like below. The log is perhaps from after the anchor was already deleted?
systemd[1]: Received untrusted credentials: nvpcr-anchor.(random string here)

That's correct, the log is after deleting the anchor - The line did appear in the logs before the anchor was deleted (still all TPM services failed)

Beemo wrote:

What does this say?
$ sudo systemd-creds list --system

# systemd-creds list --system
No credentials passed to system.
# systemd-creds list
No credentials passed. (i.e. $CREDENTIALS_DIRECTORY not set.)

seth wrote:

@Foucault, what if you just disable those services?

Sure, I can do that; but I don't think I ever enabled them explicitly or them failing before. I only noticed once libvirtd started failing.

Beemo · 2026-09-20 09:49:57

What a mystery... (surely it can't be SRK since the pub key is pulled from TPM...?)

probably one the few times I've hit such an "undebugable" wall

TBH I feel like it's kinda systemd's fault for not providing visibility on what it's doing here. A feature request might be in order, but you might want to make sure there is really no way to make it more verbose. (e.g. Asking in systemd's IRC or Matrix chat)
I tried adding "LogLevelMax=debug" to systemd-tpm2-setup.service, but it's still nowhere near as verbose as some other units.

seth · 2026-09-20 12:28:29

I only noticed once libvirtd started failing.

Do you still have journals from before that?

sudo journalctl -b -20

it's kinda systemd's fault

And you can scratch the following qualifiers

Foucault · 2026-09-21 16:31:33

seth wrote:

I only noticed once libvirtd started failing.
Do you still have journals from before that?
sudo journalctl -b -20

Try -60 maybe . I thought about that but unfortunately no; I've rebooted so many times while debugging this (before posting) that the journal has since rolled over.

I do remember from my notes while debugging (I occasionally write things down) that after root pivot (so after initrd has exited) it was something along the lines of

systemd-pcrextend: Extended NvPCR index 'hardware' with 'product-id:.....'
systemd-pcrextend: Finished TPM NvPCR Product ID Measurement

and

systemd-tpm2-setup: SRK already in TPM
systemd-tpm2-setup: public key saved to /run/systemd/smth

Now, for example, pcrextend always fails during actual root (but still works in initrd).

Last edited by Foucault (2026-09-21 16:39:47)

dr26 · 2026-09-24 21:31:28

I seem to have a similar issue after upgrading to systemd 262-1, although the error message is different.

Before the update `systemctl --failed` showed no failed units. After upgrading to systemd 262-1, the following units fail:

```text
systemd-tpm2-setup-early.service
systemd-pcrproduct.service
systemd-pcrlogin@964.service
systemd-pcrlogin@1000.service
```

The main error is:

```text
systemd-tpm2-setup: Failed to initialize NvPCR index: No such file or directory
systemd-tpm2-setup: 4 NvPCRs failed to initialize, proceeding anyway.
systemd-pcrextend: Could not extend NvPCR: No such file or directory
```

TPM itself seems to be detected correctly:

```text
$ systemd-analyze has-tpm2
yes
+firmware
+driver
+system
+subsystem
+libraries
+libtss2-esys.so.0
+libtss2-rc.so.0
+libtss2-mu.so.0
```

`systemd-analyze pcrs` also shows the normal PCRs.

NvPCR output:

```text
$ sudo systemd-analyze nvpcrs
NAME NVINDEX PRIORITY VALUE
verity 0x1d10202 300 -
hardware 0x1d10200 500 -
cryptsetup 0x1d10201 700 -
login 0x1d10203 800 -
```

And:

```text
$ sudo systemd-creds list --system
No credentials passed to system.
```

The TPM devices are present:

```text
/dev/tpm0
/dev/tpmrm0
```

I use LUKS for the root filesystem, but I do **not** use TPM for LUKS unlocking. I unlock it manually with a password.

My initramfs is generated with mkinitcpio and I boot a UKI:

```text
HOOKS=(base udev autodetect microcode modconf kms keyboard keymap consolefont block encrypt filesystems fsck)
```

with:

```text
default_uki="/boot/EFI/Linux/arch-linux.efi"
```

There is no `/etc/kernel/uki.conf`.

The system otherwise boots and works normally. This only appeared immediately after the upgrade to systemd 262-1.

Is this another manifestation of the NvPCR changes in systemd 262, or should NvPCR initialization also work with this mkinitcpio/UKI setup without TPM-based LUKS unlocking?

Beemo · 2026-09-25 06:05:58

@dr26 Seems to be a different issue. I have it too. I'm guessing the migration logic is bugged.
https://github.com/systemd/systemd/issues/43848

EDIT: intentional breakage...
https://github.com/systemd/systemd/blob … /NEWS#L447

For NvPCRs to work, all NvPCR definitions (/usr/lib/nvpcr/*.nvpcr) must now be shipped in the UKI. The UKI must also embed a signed PCR policy that is bound to the initrd boot phase and with the "initrd" policy reference. This can be created by supplying the --sign-initrd-pcrs option to ukify.
...
and the existing "anchor secret" stored in /var/lib and the ESP/XBOOTLDR will be removed.

Last edited by Beemo (2026-09-25 06:16:48)

unnatural · 2026-09-25 20:27:15

Given it is intentional on systemd's end how would we pass ukify the --sign-initrd-pcrs flag from mkinitcpio? It doesn't seem like there is any option in the config file that can be set to get the same behavior.

johnpatcher · 2026-09-25 20:39:02

After upgrading Arch Linux to systemd 262-1, I started getting these failed units:

systemd-pcrlogin@1000.service
systemd-pcrlogin@60578.service
systemd-pcrproduct.service
systemd-tpm2-setup-early.service

The initial journal error was:

Failed to initialize NvPCR index: No such file or directory

TPM itself is working:

systemd-analyze has-tpm2
yes

and the SRK is present and valid:

SRK already stored in the TPM.
SRK saved in '/var/lib/systemd/tpm2-srk-public-key.pem' matches SRK in TPM2.

My setup uses a UKI generated by

mkinitcpio

.

I configured

systemd-ukify

with:

[UKI]
SignInitrdPCRs=yes

[PCRSignature:initrd]
Phases=enter-initrd
PCRPrivateKey=/etc/systemd/tpm2-pcr-private-key-initrd.pem
PCRPublicKey=/etc/systemd/tpm2-pcr-public-key-initrd.pem

The rebuilt UKI now contains both the normal PCR signature and the additional initrd policy:

systemd-measure sign ... --phase=enter-initrd
systemd-measure sign ... --phase=enter-initrd --policyref=initrd

The NvPCR definitions are present in the initrd:

usr/lib/nvpcr/cryptsetup.nvpcr
usr/lib/nvpcr/hardware.nvpcr
usr/lib/nvpcr/login.nvpcr
usr/lib/nvpcr/verity.nvpcr

The PCR signature/key are also available after boot:

/run/systemd/tpm2-pcr-public-key.pem
/run/systemd/tpm2-pcr-signature.json

and the JSON contains

"ref": "initrd"

entries for PCR 11.

The four systemd NvPCR indices are:

0x01d10200 hardware
0x01d10201 cryptsetup
0x01d10202 verity
0x01d10203 login

They previously already existed, which caused:

Esys_NV_DefineSpace() ... ErrorCode (0x0000014c)

After removing only those four systemd NvPCR indices, that error disappeared.

Current problem:

After reboot, the services still fail with:

Failed to initialize NvPCR index: Device not a stream

four times.

Current PCR 11 value:

11:sha256=70101794f18528c97980dc7b01fe02f8c40b69fd57fbaf31265428ed8a2ab96a

bootctl status

confirms that the expected UKI is booted, using

systemd-stub 262-1-arch

, with Secure Boot enabled and the UKI measured.

So at this point the UKI contains the NvPCR definitions and the required

policyref=initrd

PCR signatures, but

systemd-tpm2-setup-early.service

still cannot initialize the NvPCRs.

This appears to be related to:

systemd issue #43848
the systemd 262 NEWS entry about NvPCR initialization and
```
--sign-initrd-pcrs
```

dr26 · Yesterday 00:02:38

Is there a supported way to disable NvPCR completely?
I don't use TPM for LUKS unlocking, just a normal LUKS passphrase, so I don't really need NvPCR. I'd rather disable it than change my UKI and set up PCR signing just to get rid of the failed units.

UrbenLegend · Yesterday 00:55:05

All the solutions posted in bug 43848 seem to rely on systemd-ukify. Even though I use LUKS with TPM, I don't use ukify as I have no need for PCR signing (I prefer simply binding on PCR 7 and 15).

If its an intended change, I think its weird that its being enforced in this way. Are users really expected to setup ukify just to get these services to not error out?

Arch Linux

#1 2026-09-17 20:54:34

TPM2 errors after updates - TPM key integrity check failed

#2 2026-09-17 22:50:25

Re: TPM2 errors after updates - TPM key integrity check failed

#3 2026-09-18 10:23:50

Re: TPM2 errors after updates - TPM key integrity check failed

#4 2026-09-18 14:56:14

Re: TPM2 errors after updates - TPM key integrity check failed

#5 2026-09-18 15:29:12

Re: TPM2 errors after updates - TPM key integrity check failed

#6 2026-09-18 15:40:16

Re: TPM2 errors after updates - TPM key integrity check failed

#7 2026-09-18 18:07:26

Re: TPM2 errors after updates - TPM key integrity check failed

#8 2026-09-18 21:15:26

Re: TPM2 errors after updates - TPM key integrity check failed

#9 2026-09-19 06:48:32

Re: TPM2 errors after updates - TPM key integrity check failed

#10 2026-09-19 11:11:43

Re: TPM2 errors after updates - TPM key integrity check failed

#11 2026-09-19 13:19:51

Re: TPM2 errors after updates - TPM key integrity check failed

#12 2026-09-19 14:13:51

Re: TPM2 errors after updates - TPM key integrity check failed

#13 2026-09-19 14:16:09

Re: TPM2 errors after updates - TPM key integrity check failed

#14 2026-09-19 14:20:37

Re: TPM2 errors after updates - TPM key integrity check failed

#15 2026-09-20 09:33:42

Re: TPM2 errors after updates - TPM key integrity check failed

#16 2026-09-20 09:49:57

Re: TPM2 errors after updates - TPM key integrity check failed

#17 2026-09-20 12:28:29

Re: TPM2 errors after updates - TPM key integrity check failed

#18 2026-09-21 16:31:33

Re: TPM2 errors after updates - TPM key integrity check failed

#19 2026-09-24 21:31:28

Re: TPM2 errors after updates - TPM key integrity check failed

#20 2026-09-25 06:05:58

Re: TPM2 errors after updates - TPM key integrity check failed

#21 2026-09-25 20:27:15

Re: TPM2 errors after updates - TPM key integrity check failed

#22 2026-09-25 20:39:02

Re: TPM2 errors after updates - TPM key integrity check failed

#23 Yesterday 00:02:38

Re: TPM2 errors after updates - TPM key integrity check failed

#24 Yesterday 00:55:05

Re: TPM2 errors after updates - TPM key integrity check failed

Board footer