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:
- Create a new script:
sudo nano /etc/grub.d/02_tpm. - Insert this code to Nano editor:
#!/usr/bin/sh -e
echo "rmmod tpm"
- Save file and execute this command (make this script is executable):
sudo chmod +x /etc/grub.d/02_tpm. - 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.
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.
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.