LUKS unlock method priority

[Arbel-arad]

my setup:
i have two LUKS partitions: cryptroot and cryptswap.
they are both configured to unlock with TPM2 automatically on boot, but they also have a FIDO2 key enrolled as a backup.

the issue:
when i boot the system normally everything works fine and i get to the login screen without any intervention, but if the FIDO key is plugged in while booting the system would try to use it first instead of the TPM, thus getting stuck if there is no user present to verify it.

i would like a way to set which keyslot gets used first so the TPM is always tried before switching to the backup.

[aafeijoo-suse]

when i boot the system normally everything works fine and i get to the login screen without any intervention, but if the FIDO key is plugged in while booting the system would try to use it first instead of the TPM, thus getting stuck if there is no user present to verify it.

I think your issue is related to systemd, not to dracut. Anyway:

• Check the journal, it should show what is happening: journalctl -b | grep cryptsetup.
• Maybe when you plug the FIDO2 key to your system, the measurements change, what could affect the TPM2 unsealing depending on the PCRs you're sealing against. If the TPM unsealing fails, the journal should report something like "Current policy digest does not match stored policy digest, cancelling TPM2 authentication attempt."

i would like a way to set which keyslot gets used first so the TPM is always tried before switching to the backup.

The order is defined by systemd: https://github.com/systemd/systemd/blob/d203e5e008eaf5cfc040407646535ee47b4bc9c1/src/cryptsetup/cryptsetup.c#L2011-L2022

[Arbel-arad]

seems like you are right, but i can't figure out why having a FIDO2 key plugged in is changing PCR 7 or 1 (UEFI settings and secure boot state)
journalctl -b doesn't show any messages about TPM, only a few errors if i let the FIDO2 user verification time out.
i will run some more checks and record the PCR states, that might give some more insight.