README.md

It sounds like your issue could be related to changes in the TPM2 PCR (Platform Configuration Register) values following the update. Specifically, since you were using PCR 7 in your /etc/crypttab configuration, and PCR 7 is tied to the Secure Boot state and configuration, any updates to the Secure Boot signatures might have altered the hash that PCR 7 measures. As a result, the TPM2 is no longer providing the correct unsealing key for automatic decryption, leading to failure in unlocking your drives.

Here are some troubleshooting steps you can try to resolve this issue:

1. Check the Current PCR 7 Value

You can use tpm2_pcrread to see the current values for PCR 7 and compare them to the previous ones. If these values have changed due to the update, you might need to adjust your cryptsetup/TMP2 configuration accordingly.

tpm2_pcrread sha256:7

If the PCR value has changed, it means that the environment the TPM is using to measure security has altered. This is likely due to the firmware update.

2. Re-enroll the Drives with Updated PCR Values

Since the update likely changed the PCR values, you may need to re-enroll the drives using systemd-cryptenroll to use the new PCR measurements:

systemd-cryptenroll --tpm2-device=auto --pcrs=7 /dev/<your-encrypted-device>

Replace /dev/<your-encrypted-device> with the appropriate device name. This will ensure the TPM2 keys are now associated with the current state of PCR 7 after the firmware update.

3. Reboot into Maintenance Mode and Re-check Crypttab Configuration

If you can still access your drives manually using the passphrase, boot into maintenance mode again.
Double-check the /etc/crypttab entries to ensure they are correctly configured for TPM2-based unlocking. The format should look something like:
```
<name> UUID=<device-UUID> none tpm2-device=auto,pcrs=7
```

Ensure the UUID is correct and that the pcrs=7 argument is present for the TPM2 unlocking.

4. Check Secure Boot State

After a firmware update, it’s also worth checking whether Secure Boot is still enabled, as this could influence PCR 7:

mokutil --sb-state

If Secure Boot is disabled after the update, that would explain why the PCR 7 values changed. You may need to re-enable Secure Boot, or re-enroll the drives as per the current PCR values.

5. Fallback: Test with Different PCRs

If re-enrolling with PCR 7 doesn’t solve the issue, you can try using other PCR values (such as PCR 0, 1, or a combination) in /etc/crypttab to identify one that might be stable across updates:

systemd-cryptenroll --tpm2-device=auto --pcrs=0+1 /dev/<your-encrypted-device>

Then update /etc/crypttab to reflect the PCR combination you're using.

6. Reset TPM Ownership (if needed)

If the TPM device itself is causing issues after the update, consider clearing the TPM and resetting its ownership. However, this is a more drastic option that should only be done if other steps fail, as it will remove all TPM-sealed keys:

tpm2_clear

After clearing, you would need to re-enroll the drives using systemd-cryptenroll as outlined above.

7. Check System Logs

Review the system logs (journalctl -b) for any errors or warnings related to TPM2 or cryptsetup. This could provide more detailed insight into why the automatic unlocking is failing.

8. Disable or Reconfigure Secure Boot (Temporary Troubleshooting)

As a temporary measure, you can also disable Secure Boot in the BIOS and test whether the TPM unlocking works without Secure Boot. If that resolves the issue, it's possible that the Secure Boot environment or keys might need to be reconfigured.

After taking these steps, you should be able to resolve the issue with automatic unlocking via TPM2 or at least identify the cause of the problem. Let me know if you encounter specific errors along the way!

krisives/README.md