After re-installation with TPM2, constant "Loading jwk to TPM2 failed!"

[darcyrailip]

Initial installation and encryption of SDD seems to work fine, but running into an issue when attempting to, essentially, wipe all hardware of secrets and data and restart the installation.

Current install runs the following in kickstart:

part /boot/efi --fstype="efi" --size=200 --fsoptions="umask=0077,shortname=winnt"
part /boot     --fstype="xfs" --size=200
part /         --fstype="xfs" --grow --encrypted --passphrase=temppass

Followed later by:

yum install -y clevis clevis-luks clevis-dracut
# Entries from previous installs can remain and cause problems:
luksmeta nuke -f -d /dev/sde3
# Move decryption to the TPM:
clevis luks bind -f -k- -d /dev/sde3 tpm2 '{"pcr_ids":"7"}' <<< temppass
echo -n temppass | cryptsetup luksRemoveKey /dev/sde3 -
dracut -f

However, re-running this installation script leads to the machine being locked out. On the screen:

Please enter passphrase for disk KINGSTON_SERIAL (luks-uuid):

If I hit ESC, I see repeated, continually outputting lines of:

Loading jwk to TPM2 failed!

A few things I've tried:

• Clearing the TPM2 pin in BIOS before the new installation
• Installation of CentOS 7 from a USB key leads to a useable OS that is not encrypted and likely not using the TPM2 meaning (IMO) that the drive is useable and not "stuck" in some kind of encrypted state
• A new SSD

My thoughts lead me to thinking that the TPM2 is still holding the old secret somehow.

I am not the original author of the installation code above, so I'm not entirely sure if something there may be a little bit off or not.

[darcyrailip]

Here's an update. If I remove the cryptsetup luksRemoveKey line from my kickstart script, I'm able to decrypt the hard drive and boot continues.

It's unclear to me if I'm actually setting the key on the TPM2 or not. Once booted, I've run this:

[root@hostname ~]# luksmeta show -d /dev/sde3
0   active empty
1   active ab123456-uuid-xxxx-yyyy-zzzzzzzzzzzz
2 inactive empty
3 inactive empty
4 inactive empty
5 inactive empty
6 inactive empty
7 inactive empty

Which seems to indicate some key is on SLOT 1. However, it's not decrypting the disk.

I can then run:

[root@hostname ~]# clevis luks bind -f -k- -d /dev/sde3 tpm2 '{"pcr_ids":"7"}' <<< temppass
[root@hostname ~]# dracut -f

And reboot the device. Now my disk decrypts automatically.

Does this assist in pointing in any direction?

Edit:

After re-running clevis luks bind, I now have this output:

[root@hostname ~]# luksmeta show -d /dev/sde3
0   active empty
1   active ab123456-uuid-xxxx-yyyy-zzzzzzzzzzzz
2   active ab123456-uuid-xxxx-yyyy-zzzzzzzzzzzz
3 inactive empty
4 inactive empty
5 inactive empty
6 inactive empty
7 inactive empty