TPM2 errors after updates - TPM key integrity check failed

jbosboom · 2026-09-28 16:44:19

I use an old-fashioned separate kernel and initramfs and had no problems with the update. TPM LUKS unlocking still works. Because I don't use a UKI, ConditionSecurity=measure-os isn't satisfied and systemd-pcrextend, systemd-pcrosseparator, systemd-pcrphase-initrd, systemd-pcrphase, systemd-tpm2-setup-early, systemd-pcrnvdone, systemd-pcrproduct, systemd-tpm2-setup, systemd-pcrmachine, and systemd-pcrphase-sysinit are all skipped. `sudo systemd-analyze nvpcrs` shows that no NvPCRs were created.

You can opt out of these services by adding `systemd.tpm2_measured_os=0` to your kernel command line. Note this will change the values of (regular) PCRs along with skipping the NvPCRs. This was added to allow opting in to measurements on systems without hardware TPMs, not to opt out, but it is documented in `man systemd.unit` and `man kernel-command-line`.

ugjka · 2026-09-28 17:06:26

jbosboom wrote:

adding `systemd.tpm2_measured_os=0` to your kernel command line.

This is what I was looking for, I use tpm to encrypt some credentials but i don't need the full systemd suite

Last edited by ugjka (2026-09-28 17:11:54)

zse · 2026-09-29 07:01:13

jbosboom wrote:

adding `systemd.tpm2_measured_os=0` to your kernel command line.

Awesome, thank you. Exactly what I wanted as well.

ugjka · 2026-10-03 12:03:55

Was reading the github issue, this seems the proper fix:

Ferdi265 wrote:

For me, the following settings worked to fix the errors:
OS: Arch Linux
Secure Boot: via sbctl
Initramfs/UKI Generator: `mkinitcpio` with UKI enabled
LUKS: yes, but without TPM unlock
# /etc/kernel/uki.conf
[UKI]
SignInitrdPCRs=yes

[PCRSignature:all]
PCRPrivateKey=/etc/systemd/tpm2-pcr-private-key.pem
PCRPublicKey=/etc/systemd/tpm2-pcr-public-key.pem
run:
# pacman -S systemd-ukify
# ukify genkey \
        --pcr-private-key=/etc/systemd/tpm2-pcr-private-key.pem \
        --pcr-public-key=/etc/systemd/tpm2-pcr-public-key.pem
# mkinitcpio -P
nothing else was needed.

I had to reboot and run mkinitcpio -P twice for all errers disappear though, no clue why but whatever...

Foucault · 2026-10-05 09:57:28

ugjka wrote:

Was reading the github issue, this seems the proper fix:
Ferdi265 wrote:
For me, the following settings worked to fix the errors:
OS: Arch Linux
Secure Boot: via sbctl
Initramfs/UKI Generator: `mkinitcpio` with UKI enabled
LUKS: yes, but without TPM unlock
# /etc/kernel/uki.conf
[UKI]
SignInitrdPCRs=yes

[PCRSignature:all]
PCRPrivateKey=/etc/systemd/tpm2-pcr-private-key.pem
PCRPublicKey=/etc/systemd/tpm2-pcr-public-key.pem
run:
# pacman -S systemd-ukify
# ukify genkey \
        --pcr-private-key=/etc/systemd/tpm2-pcr-private-key.pem \
        --pcr-public-key=/etc/systemd/tpm2-pcr-public-key.pem
# mkinitcpio -P
nothing else was needed.
I had to reboot and run mkinitcpio -P twice for all errers disappear though, no clue why but whatever...

I can't pretend I understand exactly why, but this also worked for me.

tropicalia · 2026-10-07 17:06:21

ugjka wrote:

Was reading the github issue, this seems the proper fix:
Ferdi265 wrote:
For me, the following settings worked to fix the errors:
OS: Arch Linux
Secure Boot: via sbctl
Initramfs/UKI Generator: `mkinitcpio` with UKI enabled
LUKS: yes, but without TPM unlock
# /etc/kernel/uki.conf
[UKI]
SignInitrdPCRs=yes

[PCRSignature:all]
PCRPrivateKey=/etc/systemd/tpm2-pcr-private-key.pem
PCRPublicKey=/etc/systemd/tpm2-pcr-public-key.pem
run:
# pacman -S systemd-ukify
# ukify genkey \
        --pcr-private-key=/etc/systemd/tpm2-pcr-private-key.pem \
        --pcr-public-key=/etc/systemd/tpm2-pcr-public-key.pem
# mkinitcpio -P
nothing else was needed.
I had to reboot and run mkinitcpio -P twice for all errers disappear though, no clue why but whatever...

Is this also recommended (safe) if the system is configured for TPM unlock?

Edit: I decided to wait for the upstream fix. The issue is opened for about 2 weeks now. I'm hoping the systemd team will release the fix soon. Sometimes I really dislike the fact that Arch is normally the first to detect and get those issues fixed.

Last edited by tropicalia (2026-10-08 19:25:12)

Koli · 2026-10-07 22:30:23

I am also in the crowd of not using LUKS in any capacity, and booting an UKI created by mkinitcpio, and I have the same services fail. I don't remember configuring anything for TPM in fact, it's just enabled and left as is. Anyone has a lead for how to resolve the failing services for this?
Logs just in case

Oct 07 22:09:28 archlinux systemd-tpm2-setup[223]: SRK public key saved to '/run/systemd/tpm2-srk-public-key.pem' in PEM format.
Oct 07 22:09:28 archlinux systemd-tpm2-setup[223]: SRK public key saved to '/run/systemd/tpm2-srk-public-key.tpm2b_public' in TPM2B_PUBLIC format.
Oct 07 22:09:28 archlinux systemd-tpm2-setup[223]: Failed to initialize NvPCR index: No such file or directory
Oct 07 22:09:28 archlinux systemd-tpm2-setup[223]: Failed to initialize NvPCR index: No such file or directory
Oct 07 22:09:28 archlinux systemd-tpm2-setup[223]: Failed to initialize NvPCR index: No such file or directory
Oct 07 22:09:28 archlinux systemd-tpm2-setup[223]: Failed to initialize NvPCR index: No such file or directory
Oct 07 22:09:28 archlinux systemd-tpm2-setup[223]: 4 NvPCRs failed to initialize, proceeding anyway.
Oct 07 22:09:28 archlinux systemd[1]: systemd-tpm2-setup-early.service: Main process exited, code=exited, status=1/FAILURE

dr26 · 2026-10-08 21:26:30

Hi everyone,

I'm running Arch Linux on an ASUS Zenbook with KDE Plasma (Wayland), systemd-boot and UKIs generated by mkinitcpio.

My current setup:

Kernel: 7.2.7.arch1-1

LTS kernel: 6.18.54-1

systemd: 262-1

mkinitcpio: 42.1-1

Root filesystem: ext4 on LUKS

LUKS unlocking: password only, no TPM2 enrollment

Two UKIs: arch-linux.efi and arch-linux-lts.efi

I have previously encountered failures involving systemd-pcrproduct.service, systemd-pcrlogin@*.service and related TPM NvPCR services.

The system currently boots and works normally, including LUKS unlocking.

I'm planning a full system upgrade that includes newer kernels, systemd-related components and mkinitcpio.

My questions are:

Is it reasonable to leave these NvPCR service failures unresolved if I do not use TPM2 for LUKS unlocking?

Could these failures interfere with UKI generation or booting after the upgrade?

Is there any recommended precaution specific to this configuration before upgrading?

I have retained the current kernel packages in the pacman cache and backed up both UKIs. I also have an Arch installation USB available for recovery.

I'd prefer not to modify a working boot configuration unless there is a concrete technical reason to do so.

Thanks for any advice.

mhdry · 2026-10-09 09:43:58

Please stop panicking about this!

This is not really a bug (I'll explain my reasoning at the end of this post...), but rather a (gross) configuration mismatch after systemd changed its default policy about handling TPM2 measured boot. For practical purposes, there are three options:

Option 1: Wait and see

As already described in this thread, doing nothing causes some services to fail, in my case:

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

3 loaded units listed.

Basically, the services failing indicate that TPM2 measured boot is enabled but completely unconfigured:

$ bootctl status
  TPM2 Support: yes
  Measured UKI: yes
   Measured OS: yes

If this doesn't bother you, wait and see whether systemd will implement changes to this behaviour in the future. Your system should work normally, as this implies you've never setup TPM2 measured boot in the past at all and therefore don't rely on it.

Option 2: You don't need/want TPM2 measured boot

Add systemd.tpm2_measured_os=0 to your kernel command line. Systemd services in Initrd used for TPM2 measured boot will skip without an error message. All UEFI measurements carried out by systemd-boot and systemd-stup will remain unaffected, but the advanced (signed) NvPCR measurements carried out in userspace by systemd-pcrextend or (partially) systemd-cryptsetup as well as systemd-veritysetup will skip.

Setting this kernel parameter your machine shuold show:

$ bootctl status
  TPM2 Support: yes
  Measured UKI: yes
   Measured OS: no

$ systemctl list-units --state=failed
  UNIT LOAD ACTIVE SUB DESCRIPTION

0 loaded units listed.

Option 3: You need/want to configure TPM2 measured boot (the new systemd default)

If using systemd-ukify, you need to set SignInitrdPCRs=yes in /etc/kernel/uki.conf and generate a private/public key pair used to sign PCR registers in Initrd.

Edit (create if it doesn't exist) /etc/kernel/uki.conf:

[UKI]
SignInitrdPCRs=yes

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

Warning 1: This example only shows the minimum configuration required to enable TPM2 measured boot, if you've already configured uki.conf - e.g. in order to sign your UKI with your own secure boot PK - of course keep those settings...

Warning 2: Section [PCRSignature:initrd] is required to get this running. Whether you use [PCRSignature:all], [PCRSignature:default] or whatever instead, depends on your own use case(s). Please refer to ukify man page to make an informed decision...

Interjection: Classical LUKS2/cryptenroll using PCR binding cryptenroll --tpm2-pcrs should be completely unaffected by this issue. However the newer cryptenroll --tpm2-public-key-policyref=initrd uses the same mechanism (signed PCR policy) as measured boot and therefore relies on NvPCR measurements to be successful.

Now generate these keys and regenerate your Initrd/UKI:

$ sudo ukify genkey --config=/etc/kernel/uki.conf
$ sudo mkinitcpio -P

With this setup, your machine should display:

$ bootctl status
  TPM2 Support: yes
  Measured UKI: yes
   Measured OS: yes

$ systemctl list-units --state=failed
  UNIT LOAD ACTIVE SUB DESCRIPTION

0 loaded units listed.

Why did I claim this wasn't a bug?

Systemd defaults to TPM2 measured boot since version 261. However - at least as of now - it seemingly was decided to not default to SignInitrdPCRs=yes and to not automatically generate the required key pair. This causes the failing services mentioned in this thread. However, systemd works exactly as intended: If NvPCR signatures can't be generated and checked (key missing + "wrong" (nonsensical?) deafult of "no" for SignInitrdPCRs), the respective services fail. This isn't a bug as in "faulty code", but it needs manual configuration adjustments - which in this case (as often in the past) have been poorly communicated and documented by the systemd developers.

Last edited by mhdry (2026-10-09 14:53:32)

Janusz11 · 2026-10-10 11:56:31

Thanks, @mhdry, that helps better understanding the issue.

I use TPM for unlocking my LUKS encrypted NVMe. I have opted for installing systemd-ukify and creating corresponding keys and setting my system up anew. Unfortunately, the setup slows the boot process down noticeably.

I will stay with the current setup (I may get used to it eventually), but will also keep an eye on the future development.

Last edited by Janusz11 (2026-10-10 11:57:09)

mokkurkalve · Yesterday 15:19:18

Mm. I managed too get the error messages to disappear but I'm still struggling. How is it possible in the current situation to enroll TPM2 keys on my LUKS2 volumes (three of them) that will work? I'm exhausted by having all attempts ending in having to get out that USB rescue stick. (Maybe it's a problem that I have a Pluton chip?) Anyways, if somebody knows a combo of configuration and systemd-cryptenroll commands that actually works....

Arch Linux

#26 2026-09-28 16:44:19

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

#27 2026-09-28 17:06:26

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

#28 2026-09-29 07:01:13

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

#29 2026-10-03 12:03:55

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

#30 2026-10-05 09:57:28

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

#31 2026-10-07 17:06:21

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

#32 2026-10-07 22:30:23

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

#33 2026-10-08 21:26:30

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

#34 2026-10-09 09:43:58

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

#35 2026-10-10 11:56:31

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

#36 Yesterday 15:19:18

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

Board footer