Uh, anyone else seeing this? Updated about a month ago; worked fine. Today, after GNOME Software update, system will not boot. Ouch.
Can you look at 2128485 – GRUB errors out on boot due to TPM module errors to see if it’s the same bug?
1 Like
One possible fix is to boot to the bios setup and disable the tpm &/or secure boot under the uefi security settings.
Yes, thank you. That bug looks like a match. And the solution was to disable Secure Boot.
How do I get back to Secure Boot? Do I just go through the process like it’s the first time? (I think, on this system, I just installed fresh with it enabled, but I think there are instructions to do it manually somewhere I’ve seen.)
1 Like
I normally enable/disable it through the BIOS menu on startup (before it gets to grub).
I mean, how do I make secure boot work again. It’s broken.
Re-enable secure boot the same way you disabled it — in bios.
On my laptop I was forced to disable tpm then disable secure boot (in that order). I restored both after having enabled signing the nvidia driver modules. (The nvidia modules unsigned was the reason secure boot had to be disabled initially.)
There was an update to the keys about a month ago. You might try running sudo fwupdmgr update (note that it’ll require a reboot) and see if it includes the updated secureboot keys.
I appreciate that this thread is attracting such helpful folks, but I think we are talking past each other.
Enabling Secure Boot doesn’t make Secure Boot work. I don’t understand what you are suggesting. Secure Boot in the BOIS just forces checking signatures, which is what is broken on my system because GRUB2 cannot load TMP module–or something like that. I tried re-enabling SB, and it gives the exact same error as before. What I’m asking is: how do I fix my broken Secure Boot configuration?
I also tried fwupdmgr update but that didn’t help, either. It reported “Devices with the latest available firmware version: UEFI dbx”. But, it didn’t appear to make any changes. Again, I don’t understand why this should help. AFAICT, there’s nothing wrong with my firmware, keys, or signatures. GRUB cannot boot any kernels with SB enabled because it cannot verify signatures because it cannot interface with the TMP due to the problem I reported in the subject line of this thread. I’m asking how to fix that.
That bug has been open over a month with no help.
I’m guessing GRUB2 should be reinstalled or updated? Maybe I should move to systemd-boot like did on my other system. But, then I still have the problem of making SecureBoot work, which I haven’t done from scratch, yet.
on Fedora 36 the error could be cleared by disabling the SHA-1 PCR bank in the TPM.
So far today, that doesn’t help with Fedora 37.
Hmm, okay, I don’t fully understand, but I’ll try to figure out how to do that. I’m assuming that will make sense when I’m in the BIOS looking a options.
So, is that because SHA-1 is deprecated or something? Would like to understand why that fix is expected to work.