You are not logged in.
Hello,
After replacing my video card, GRUB complains with that message "prohibited by secureboot policy".
My previous card was a NVIDIA GTX 1060 and the new one is an AMD RX 6600 XT.
On this dual boot desktop, I am still able to boot Windows by spamming F11 to get motherboard menu and select Windows boot loader.
I've read a previous post with same error message and a problem with font signing but I'm not sure it's related to my case.
As I'm noob in UEFI things, the only thing I've tried was to boot into live USB and trying to reinstall GRUB inside chroot with no luck.
Could someone give me others directions please?
Offline
I've read a previous post with same error message and a problem with font signing but I'm not sure it's related to my case.
There are other modules besides the fonts that might need to be signed with the latest GRUB version: https://wiki.archlinux.org/title/Unifie … y_and_GRUB
I presume you're using the shim? You should probably provide more information about your SecureBoot implementation.
"It's impossible for a white person to believe in capitalism and not believe in racism. You can't have capitalism without racism."
— Malcolm X
Offline
survietamine wrote:I've read a previous post with same error message and a problem with font signing but I'm not sure it's related to my case.
There are other modules besides the fonts that might need to be signed with the latest GRUB version: https://wiki.archlinux.org/title/Unifie … y_and_GRUB
I presume you're using the shim? You should probably provide more information about your SecureBoot implementation.
Hello,
I'm sorry for the delay of my answer because I was a bit busy these days.
I have to admit I lack knowledge about that signing and shim things. Since my dual boot worked for years without touching it, I even cannot remember well how I implemented it. The only recent change was that graphics card from NVIDIA to AMD.
Thanks for the URL, I'll read it and try to understand better how secureboot is handled nowadays in GRUB.
Offline
Did you enroll custom keys?
Perhaps the firmware reset itself to its default settings, and now tries to use the standard MS certificates to verify your EFI binaries?
Offline
Did you enroll custom keys?
Perhaps the firmware reset itself to its default settings, and now tries to use the standard MS certificates to verify your EFI binaries?
No, I didn't do anything about keys in my implementation.
Offline