I'm finding that current Rawhide images do not boot in native UEFI mode when written to a USB stick with dd. I've tested Fedora-Workstation-Live-x86_64-Rawhide-20220701.n.0.iso and Fedora-Everything-netinst-x86_64-Rawhide-20220704.n.0.iso on my test machine. Booting them in BIOS compatibility mode works, but attempting to boot in UEFI mode shows a few error messages briefly and then goes back to the firmware UI. I strongly suspect this is fallout somehow from the switch from syslinux to grub2 for BIOS booting - https://bugzilla.redhat.com/show_bug.cgi?id=2092065 . I noticed that when I attach the dd'ed USB stick back to my main system, dmesg shows some errors that I think are new (I don't recall seeing them with older images written to the same stick): [ +1.054630] GPT:Primary header thinks Alt. header is not at the end of the disk. [ +0.000007] GPT:1370279 != 30514175 [ +0.000006] GPT:Alternate GPT header not at the end of the disk. [ +0.000002] GPT:1370279 != 30514175 [ +0.000003] GPT: Use GNU Parted to correct GPT errors. To try and reproduce this, just grab any recent Rawhide ISO, write it to a USB stick with dd, and try booting it in native UEFI mode on a capable system. I'm proposing this as a Beta blocker, it's an obvious violation of "All release-blocking images must boot in their supported configurations" if more folks can reproduce on more systems.
What hardware is this failing on? FWIW I do not see this with any of my UEFI systems which include Lenovo laptops, a Dell, and a Macbook Air from 2010. The Fedora-Everything-netinst-x86_64-Rawhide-20220711.n.0.iso image works just fine on all of them. Those messages are unrelated, they will always show up because we can't know the size of the disk this is written to beforehand. I also see them on my working systems and USB stick. It's possible that some difference between isohybrid and the xorriso hybrid approach is causing problems with 'sensitive' firmware though. I'm not sure how to debug that...
Huh, that's interesting. It's my test box, which is built from parts; the motherboard is an Asus H97M-E, I believe. I meant to send out a call for testing but I guess I forgot, I'll try and do that since you're not reproducing it anywhere!
Results from the call for testing: Geraldo Kutz ("Acer Aspire"): good Kamil Paral ("three different computers"): good Luna Jernberg: unclear but seems to suggest image does boot Richard Shaw (Gigabyte B550): good Stephen Snow (https://linux-hardware.org/?probe=64e8ddf1c9): good Also cmurf suggested some parted commands for me to play with which I didn't get to yet. so, on the whole, looks like I've just got an ornery system. I guess I'll remove the blocker nomination at least for now.
This bug appears to have been reported against 'rawhide' during the Fedora Linux 37 development cycle. Changing version to 37.
I have the same observation with an Asus Z87-PLUS motherboard. The brief GRUB message is Invalid Image Failed to read header: Unsupported Failed to load Image: Unsupported start_Image() returned Unsupported _ This also applies to Fedora-Workstation-Live-x86_64-37_Beta-1.4.iso. I found that if I replace grubx64.efi and BOOTX64.efi in the EFI System partition (ANACONDA) with versions from Fedora 36 Mar 25 20:37 grubx64.efi May 5 2021 BOOTX64.EFI booting proceeds as expected.
(In reply to Frederick Grose from comment #5) > I have the same observation with an Asus Z87-PLUS motherboard. > > The brief GRUB message is > > Invalid Image > Failed to read header: Unsupported > Failed to load Image: Unsupported > start_Image() returned Unsupported > _ > > This also applies to Fedora-Workstation-Live-x86_64-37_Beta-1.4.iso. > > I found that if I replace grubx64.efi and BOOTX64.efi in the EFI System > partition (ANACONDA) with versions from Fedora 36 > Mar 25 20:37 grubx64.efi > May 5 2021 BOOTX64.EFI > > booting proceeds as expected. Oh interesting. That would mean this is actually a grub2 issue. Could you open a bug against it? @awilliam can you try doing the same thing with your hardware?
Reported here for GRUB: https://savannah.gnu.org/bugs/index.php?63024
Seems to have been reported here for shim: https://bugzilla.redhat.com/show_bug.cgi?id=2113005
*** This bug has been marked as a duplicate of bug 2113005 ***