Hide Forgot
Description of problem: On some boards (?), a custom live image made with /boot/efi/EFI/BOOT/BOOTX64.EFI from shim-x64-15.6-2.x86_64 fails to boot, but replacing the BOOTX64.EFI on this image with the one from shim-x64-15.4-5.x86_64 fixes the problem. Booting a standard Fedora 36 Live image (tested Fedora-Xfce-Live-x86_64-36-1.5.iso) on such a board works OK, but this image is using shim-x64-15.4-5.x86_64. Version-Release number of selected component (if applicable): shim-x64-15.6-2.x86_64 How reproducible: Easy with the right x86_64 board Tested with a Kontron VX3040 board (Quad core Intel Core i7-3517UE) with UEFI AMI BIOS Steps to Reproduce: 1.Rebuild a live image (tested XFce) using livemedia-creator from latest Fedora sources 2.Try to boot the image 3.An error is displayed Actual results: Invalid image Failed to read header: Unsupported Failed to load image: Unsupported start_image() returned Unsupported Expected results: GRUB successfully loaded Additional info: As workaround I can enter the UEFI shell, enter the filesystem (map -r + fs0:), then cd EFI\BOOT, then run GRUB manually with : GRUBX64.EFI <enter> But running BOOTX64.EFI gives the same errors than when the BIOS is trying to boot automatically from boot list (see 'Actual results") Strangely, once booted with the workaround above and installed to disk, the disk boots successfully even with this /boot/efi/EFI/BOOT/BOOTX64.EFI from shim-x64-15.6-2.x86_64
What if you try to boot shimx64.efi from the UEFI shell?
Boot fails also with shimx64.efi : fs0:\EFI\FEDORA> SHIMX64.EFI Invalid image Failed to read header: Unsupported Failed to load image: Unsupported start_image() returned Unsupported start_image() returned Unsupported fs0:\EFI\FEDORA>
Created attachment 1907142 [details] Additional tests
Additional infos : - SHIMX64.EFI is not present on EFI partition of live image; only once installed to disk (under EFI\FEDORA) - Fedora 36 official live image can boot from \EFI\BOOT\BOOTX64.EFI - Fedora 36 custom live image can not boot from \EFI\BOOT\BOOTX64.EFI but can boot from \EFI\BOOT\GRUBX64.EFI - Once installed to disk, the custom Fedora 36 live image can not boot from \EFI\FEDORA\SHIMX64.EFI but can boot from \EFI\BOOT\BOOTX64.EFI See attached f36gruberrdbg_3.txt (attachment 1907142 [details])
On Fedora 36 official live image, \EFI\BOOT\BOOTX64.EFI has same checksum and size (13999 / 928592) than the one in shim-x64-15.4-5.x86_64.rpm (fedora release) On Fedora 36 custom live image and once installed to disk, \EFI\BOOT\BOOTX64.EFI has same checksum and size (23754 / 946712) than the one in shim-x64-15.6-2.x86_64.rpm (fedora updates)
Can you try (in a booted system that works): mokutil --set-verbosity true mokutil --set-fallback-verbosity true and then reboot into the image with 15.6? This should result in more debug output.
Created attachment 1907157 [details] with debug enabled by mok on shimx64.efi 15.6
OK, on a system running from a disk installed from the custom live image, I ran you commands and attempted to reboot from SHIMX64.EFI (from 15.6-2). See attachment 1907157 [details]
Created attachment 1907158 [details] Auto boot from custom live image with mok debug
Created attachment 1907159 [details] boot from bootx64 from shell on custom live image with mok debug
Created attachment 1907160 [details] Auto boot from official F36 live image with mok debug (boot OK; have to press ENTER in debug messages)
Thanks. I may have a fix: https://github.com/rhboot/shim/pull/505 . If you're able to test unsigned shims, it would be helpful if you could give that a spin.
Ok, I would be glad to help for testing, but how can I do that ? Would you send me an updated shimx64.efi ?
Well, the tricky part is signing it, not building it. You either need your own key enrolled to sign with, or secure boot enforcement disabled. But if it helps, and you feel like running binaries linked by quasi-strangers on the internet, you can extract built, unsigned shims from /usr/share/shim of the RPM at: https://rharwood.fedorapeople.org/shim-505/shim-unsigned-x64-15.6-505.x86_64.rpm
Created attachment 1907921 [details] Test of test of shimx64.efi from shim-unsigned-x64-15.6-505.x86_64.rpm with secure boot disabled I've extracted the shimx64.efi from your shim-unsigned-x64-15.6-505.x86_64.rpm test package and copied it to an installed disk under EFI/fedora/shimx64_156505.efi. I also copied version 15.6-2 under shimx64_1562.efi and 15.4-5 under shimx64_1545.efi to compare. Then I've tried to run them manually from EFI shell with secure boto disabled : shimx64_1545.efi : OK (grub is run) shimx64_1562.efi : FAILS shimx64_156505.efi : OK
Thanks for the testing. For anyone hitting this issue before Fedora's signed shim updates: in my opinion, it is better from a security perspective to run the older, signed shim rather than disabling secureboot to run the patched, unsigned shim linked above. (If you're able to enroll your own keys, of course you can have the best of both worlds; and if you're just testing fixes, none of this applies anyway.)
I observe the same error messages booting Fedora 37 images on an Asus Z87-PLUS motherboard. see https://bugzilla.redhat.com/show_bug.cgi?id=2103785 Substituting the Fedora 36 Mar 25 20:37 grubx64.efi May 5 2021 BOOTX64.EFI files solves the problem.
*** Bug 2103785 has been marked as a duplicate of this bug. ***
It's a shame we have a fix for this but are releasing F37 with it :( Sorry, I kinda took my eye off this ball a bit. Robbie, when are we scheduled to do another signed shim build?
I've created a CommonBugs description here: https://ask.fedoraproject.org/t/common-issues/28364 Can somebody please proof-read it? (I only tried to advise workarounds usable for a general user. Approaches like using the UEFI shell can power users easily discover when reading through this bug report). Most importantly, does this problem only affect booting install media, or does it also affect upgraded systems (F36->F37)? IOW, can a system upgrade make your system unbootable?
I observe the same error messages booting the latest Rawhide .iso, Fedora-Workstation-Live-x86_64-Rawhide-20221109.n.0.iso on my Asus Z87-PLUS motherboard.
I think most likely an upgrade could break it, yes, as the affected files are part of shim-signed and typically Fedora boots with /boot/efi mounted and writeable. It's probably worth documenting the "replace the files with ones from the older shim package" workaround too, for folks who want to do a UEFI install, or are upgrading a UEFI system. I wish I'd thought to make this bug a higher priority :| Maybe we could've at least just downgraded to the older working shim for F37, or something, even if we couldn't get a new signed build done in time for release. I hate to do it, but I'm actually gonna throw this on the blocker list for the go/no-go, at least to let people chew it over and raise visibility.
Just realized I never actually mentioned this, but my Asus H97M-E - which I believe is likely of similar vintage to Frederick's Z87-PLUS - is also affected. So the total list of affected boards so far is: * Kontron VX3040 * Asus Z87-PLUS * Asus H97M-E nirik also found this forum post by another affected person: https://ask.fedoraproject.org/t/f37-invalid-image-error-while-booting/26632/3
So, good news on the upgrade front. I tested, and this bug does not actually seem to affect installed systems. If you install F36 and update it, you already get the 'bad' shim, because it's in F36 (and F35) updates as well as in F37. But the system still boots fine. If you then upgrade to F37, the system still boots fine. So it seems, for some reason, this bug only affects the live boot scenario. I don't know why that would be, but it's good news. Robbie, does that make sense to you?
In today's Go/No-Go meeting, we agreed to reject this on the basis that this bug appears to be limited to specific hardware and may only affect booting live images, so it does not rise to the level of a release blocker https://meetbot.fedoraproject.org/fedora-meeting/2022-11-10/f37-final-go_no_go-meeting.2022-11-10-17.02.log.html#l-280
Just reporting that my main computer with following mainboard is also affected. Not only live images but also netinst (Everything "variant") has this issue. Asus Z97-DELUXE/USB 3.1 (bought 2015/07)
This workaround allowed me to boot a LiveUSB: (from https://www.reddit.com/r/RockyLinux/comments/r49er0/comment/hs6mll2/?utm_source=share&utm_medium=web2x&context=3) In the ESP, delete the original BOOTX64.EFI and BOOTIA32.EFI. Then Rename grubx64.efi and grubia32.efi to BOOTX64.EFI and BOOTIA32.EFI respectively.
That's not the best idea, because it will only work with Secure Boot disabled. The best workaround is the one documented at https://ask.fedoraproject.org/t/f37-install-media-dont-boot-in-uefi-mode-on-certain-motherboards/28364 - replacing BOOTX64.EFI with the one from an older package. You don't need to worry about BOOTIA32.EFI.
Just for information, I have an MSI H81M-E33 and that is affected too.
Also affects to Acer E5-575.
for the record, Lenovo ThinkCentre E73 is also affected RHEL 9 is suffering from the same issue it seems to me.
To add to the list, this also affects Asus AM1I-A (latest AMI UEFI BIOS 0801).
Intel DH87RL is affected.
Gigabyte GA-6LXSV is affected. Though, I was trying to boot RHEL 9.1 (dvd and live boot images). I worked around this by deleteing BOOTX64.efi and renaming GRUBX64.efi in its place in the efi partition.
Adding to the list: My DELL G5 5590 with its latest UEFI version 1.22.0 is also affected. Will be installing Fedora 36 and upgrading to 37 as a workaround. Annoying to learn that this is not getting fixed.