GRUB is output error of tpm.c module after 371 DBX update

After install a UEFI DBX update (version 371 of 16 June 2023) I get a GRUB “tpm.c” module error (in 140th line). Full log I’m not provide because I’m switched to Windows 11 (Windows have many other problems, but this problem is not applicable). How to fix (without disabling TPM)? Secure Boot was disabled (now is enabled for Windows).

I wait a bug fix from Fedora team. Because update of BIOS is not resolved problem. Reset Secure Boot databases to factory state is resolved, but if I update DBX database, I get a this error. Reset of TPM is also not helped.

Thanks a lot, @psi-jack, that solved my problem with temporary elegant fix (but GRUB/kernel updates is not a delete this config, and not return this issue, because is not modifying a GRUB’s package files, but creating a config overlay in /etc/grub.d/).

Temporary solution:

  1. Create a new script: sudo nano /etc/grub.d/02_tpm.
  2. Insert this code to Nano editor:
#!/usr/bin/sh -e

echo "rmmod tpm"
  1. Save file and execute this command (make this script is executable): sudo chmod +x /etc/grub.d/02_tpm.
  2. Apply this overlay config file: grub2-mkconfig -o /etc/grub2.cfg.

Done! But I want to fixes from Fedora team. Because this is a bug, and this is not normal.

I agree one should not have to make that change.
I suggest that you file a bug report at bugzilla.redhat.com with the info you provided here so the info can be passed to the kernel developers for a future fix.

I did send to Red Hat Bugzilla to GRUB developers.

Link: 2215704 – GRUB is not compatible with DBX v371.

As it turned out, my UEFI NVRAM was full of a huge number of boot entries. I cleared these entries via efibootmgr and the issue was resolved.

I think I had seen similar issues, but had not tied yours with the others because no info was available from eifbootmgr. Glad you were able to find that and resolve the problem.

:+1:

Just as general advice for everyone – It works best if one does not allow nvram to store a large number of boot entries. Apparently there is a limit to what the DBX can manage.

I had the same issue today after my dbx was updated from 217 to 317.

My PC did not boot at all. I have first disabled the TPM chip in my BIOS to be able to start my PC again. After this I could apply this 02_tpm script and then enable the TPM chip again. Now I still have a bunch of tpm.c error messages while booting but the PC is starting and I am still able to use my TPM chip.

In my case I found only 4 boot records with efibootmgr.

I’m recommend also check leftover MOK keys. Highly likely, what you have a lot of old MOK keys, which also estimate a NVRAM memory.

Yes - there were 85 keys (whereever they came from). I have done a “moktutil --reset” and was able to delete all except for one Fedora key which expired in 2022. I have tried to delete this key also but it failed.

Nevertheless the issue remains the same.

This is a main SB key from Fedora. This is embedded in Shim binary (and not stored in MOK), and not deleted (because this is not MOK key).

That is the one baked into the shim, and it is used for signing the kernel. You need this certiricates for booting fedora in secure mode. Don’t mind the expire date.

OK. Then I will keep this 02_tpm script as workaround.