This is a discussion topic for the following Common Issue:
You can discuss the problem and its solutions here, but please note that debugging and technical feedback should primarily go to the issue trackers (e.g. Bugzilla) linked in the Common Issue, because that’s the place that developers watch, not here.
If there are any updates/changes/amendments for the Common Issue description, which you believe should be performed, please post it here.
Thanks for sharing - my only note would be that, it seems quite possible this isn’t exclusively a Fedora issue - I also play around with Linux Mint some, and the last time I tried to install it I had a heck of a time because of issues related to the shim versions being used by upstream Ubuntu, it seemed.
On Mint, I ended up having to disable Secure Boot to get the installed OS to boot at all, even though the live image worked OK (sounds like almost the inverse of this issue?). On the same machine, though, Fedora 37 installed just fine. Maybe comes down to the different versions of shim-related things that would be in Debian/Ubuntu vs. Fedora?
Is there maybe some broader thing going on with Secure Boot as a whole? In the Bugzilla comments it’s noted that at least some component of a root cause fix for Fedora’s issue would depend on significant kernel changes…which would eventually impact all distributions, I’d think?
It probably impacts all distributions which use the same shim version.
@kparal Can you extend the instructions a bit? I found with the F38 Workstation live there isn’t enough space to replace BOOTX64.EFI. To make space, it’s safe to remove BOOTIA32.EFI and grubia32.efi - these are only needed on weird systems with 32-bit UEFI firmwares (none of which are affected by this bug, AFAIK).
Funny, I’ve been booting from the UEFI shell as a workaround and thought there was something wrong with my motherboard’s UEFI implementation (I’m way past due for an upgrade, but my computer has been working fine). Glad I’m not the only one facing this.
BOOTX64.EFI throws the same error if ran from the shell, but is able to “fall back to the default loader” and continue booting.
I had the F38 beta install media not boot for me, but this was on an older motherboard in the BIOS mode. I’d discussed it with folks on the Fedora IRC/Matrix channel but i was going away on leave and didn’t have the time to debug this further to file an issue. I’ll try it out again and file a bug.
I have tested to install with the changed BOOTX64.efi, but i get the message “sb.c:183:bad shim signature”.
Is there any other chance to boot Fedora 37 or 38 in UEFI mode?
Hello, in the guide related to the manual solution for this problem the url for the F36 shim package does not work anymore, so I found it from the archive
I suggest to modify the link in the guide until the fix comes
Use the following command to extract BOOTX64.EFI from the rpm.
rpm2cpio shim-x64-15.4-5.x86_64.rpm|cpio -idmv