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.
1 Like
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.
solved the issue, you just need to disable secure boot / TPM AND delete all security keys of secure boot and TPM then boot into the Fedora OS
THEN boot once again into the bios and enable secure boot and TPM install the factory secure keys and boot once again into the OS and the issue is fixed permanently with secure boot enabled.
Fedora 38
Hmm, I think I understand, but how do you reinstall key? The system did this automatically for me when I installed it the first time. Is this easy to find how to do? I haven’t looked, but maybe you know the highlights?
Okay, I think I see what you mean. I was able to delete and reinstall keys from inside the UEFI firmware. System boots now with Secure Boot enabled.
Once booted, GNOME Software offered a special update related to Secure Boot, so I installed that, and it said I needed to reboot. That worked, and SB is still installed.
Doing system update, now…
I would like also to thank @vwbusguy his mentioning of keys inspired me to reinstall the firmware security keys. Thank you very much.
1 Like