My computer (a Lenovo Yoga laptop, AMD processor) hasn’t started up with just the TPM pin since updating Tumbleweed about a week ago. (LUKS TPM2+pin, set up in the openSUSE installer.) At first I saw a message about the OS disabling RDSEED32 due to security risks; thinking that could be causing the issue, I updated the UEFI (itself a big hassle, thanks Lenovo) but that didn’t work. I bashed my head against a wall for a while until I realized that I just needed to mash the pin to get it to prompt me for my recovery password, which did work. I then tried several things that didn’t work to get it to start up normally again, including clearing the TPM lockout (with tpm_dictionarylockout), trying to clear the TPM (with tpm_clear), and clearing the TPM slots in systemd-cryptenroll and re-enrolling with sdbootutil. It always failed TPM decryption with a “state unrecoverable” error, and actually made the problem worse - the PCR validator started failing and systemd would fail to setup encryption at all, requiring me to manually use systemd-cryptsetup at the initramfs recovery console.
I managed to fix that by clearing and re-enrolling entirely with sdbootutil (after clearing the TPM lockout), but PCR validation is still failing. Setting it up threw the error TPM2 device supports SHA256 PCR bank but none of the selected PCRs are valid! Firmware apparently did not initialize any of the selected PCRs. Proceeding anyway with SHA256 bank. PCR policy effectively unenforced!and calling sdbootutil update-predictions --measure-pcr didn’t help. systemd just prompts me for the disk passphrase now; it’s not even attempting to unlock using the TPM. Here’s the relevant bit from the system journal. systemd-cryptsetup[724]: Automatically discovered security TPM2 token unlocks volume. systemd-cryptsetup[724]: Failed to load pcr signature: No such file or directory systemd-cryptsetup[724]: TPM2 operation failed, falling back to traditional unlocking: No such file or directory
I also tried using fde-tools, but fdectl regenerate-key just throws an error. cp: cannot stat '/usr/lib64/efi/MokManager.efi': No such file or directory cp: cannot stat '/usr/lib64/efi/MokManager.efi': No such file or directory Error: Failed to update bootloader configuration
I wasn’t convinced that was the right tool to begin with, though. fdectl tpm-present does indicate the TPM is working. Checking systemd-analyze pcrs also shows a string in PCR 15. I’m really not sure what I’m missing.
Is the systemd service “tpm2-abrmd.service” enabled and executing?
Does the systemd status of that service indicate that, the TPM2 Access Broker and Resource Management Daemon is executing?
All looks fine in the journal; not sure where I’d check otherwise. And I actually briefly got it working, so it must be fine. Somewhat unsatisfyingly, I just ran the same sdbootutil commands to re-enroll the keys again and even though I had no real reason to expect that to work this time, it did. However, I updated the system to check if that would break it again, and I’m seeing the exact same behavior I started with - a prompt for the pin, which fails after five attempts and prompts for the password. The journal throws this error.
Jan 29 01:45:04 localhost systemd-cryptsetup[727]: WARNING:esys:src/tss2-esys/api/Esys_PolicyOR.c:286:Esys_PolicyOR_Finish() Received TPM Error
Jan 29 01:45:04 localhost systemd-cryptsetup[727]: Failed to add OR policy to TPM: tpm:parameter(1):value is out of range or is not correct for the context
Jan 29 01:45:04 localhost systemd-cryptsetup[727]: Failed to unseal secret using TPM2: State not recoverable
This time though, I did see something strange in the zypper output. It looks like the script that updates the PCR policy failed. (Strangely, zypper didn’t inform me any scripts had failed when it completed; I only saw this because I was watching the output closely. Is this normal operation for zypper?)
%posttrans(sdbootutil-dracut-measure-pcr-1+git20260115.cd41d07-1.1.noarch) script output:
Removed /boot/efi/loader/entries/snapper-opensuse-tumbleweed-6.18.5-1-default-171.conf
Removed "/boot/efi/opensuse-tumbleweed/6.18.5-1-default/linux-b3a3fa32ca2f13604c91510f3d98f9337556978e"
Removed "/boot/efi/opensuse-tumbleweed/6.18.5-1-default/initrd-044d6436524acc957df9bd16d7e917a111646ee3"
Removed /boot/efi/loader/entries/system-opensuse-tumbleweed-6.18.5-1-default-1.conf
Removed "/boot/efi/opensuse-tumbleweed/6.18.2-1-default/linux-17aa742ebbe34d76bee9df1adf8e7f49d838c330"
Removed "/boot/efi/opensuse-tumbleweed/6.18.2-1-default/initrd-b793d5dcc1a4926ee2962b86c7d9b62b53c57f66"
Removed /boot/efi/loader/entries/system-opensuse-tumbleweed-6.18.2-1-default-1.conf
Garbage after device path end, ignoring.
Garbage after device path end, ignoring.
Garbage after device path end, ignoring.
Garbage after device path end, ignoring.
PCR policies with more than 8 alternatives per PCR are currently not supported.
Failed to calculate super PCR policy: Argument list too long
Error creating the systemd-pcrlock policy!
warning: %posttrans(sdbootutil-dracut-measure-pcr-1+git20260115.cd41d07-1.1.noarch) scriptlet failed, exit status 1
And if I re-enroll as above, it works again. (Out of interest I checked the scripts log to see if the same behavior happened after the update that initially caused the issue, which it didn’t. The amdgpu script failed that time, no idea if that’s related.)
If SELinux with the openSUSE/SUSE configuration definitions then, this little secret:
# restorecon -F -R -v /usr
#
# restorecon -F -R -v /etc
Relabeled /etc/pki/nssdb/pkcs11.txt from unconfined_u:object_r:cert_t:s0 to system_u:object_r:cert_t:s0
Relabeled /etc/ld.so.cache from unconfined_u:object_r:etc_t:s0 to system_u:object_r:ld_so_cache_t:s0
#
# restorecon -F -R -v /var
#
The “semanage-fcontext” man page supplies more details – especially the Examples near the end of the page.
Taking the last example, if you have home directories under the top level directory as I do, never, ever, execute “restorecon -R” on /home – execute it recursively explicitly only on the home directories located below the top level directory – the same applies to any KVM image directories you may have in a partition other than the one where the directory /var/lib/libvirt/images/ is located.