Bug 2103785

Summary: Current Rawhide images do not boot in UEFI mode when written to USB on Asus H97M-E motherboard
Product: [Fedora] Fedora Reporter: Adam Williamson <awilliam>
Component: loraxAssignee: Brian Lane <bcl>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: urgent Docs Contact:
Priority: unspecified    
Version: 37CC: anaconda-maint-list, bcl, fgrose, pbrobinson, reallylongword, robatino
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2022-10-25 17:45:20 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 2092065    

Description Adam Williamson 2022-07-04 21:55:10 UTC
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.

Comment 1 Brian Lane 2022-07-11 23:03:26 UTC
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...

Comment 2 Adam Williamson 2022-07-11 23:42:10 UTC
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!

Comment 3 Adam Williamson 2022-08-08 17:36:56 UTC
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.

Comment 4 Ben Cotton 2022-08-09 13:39:56 UTC
This bug appears to have been reported against 'rawhide' during the Fedora Linux 37 development cycle.
Changing version to 37.

Comment 5 Frederick Grose 2022-09-04 16:46:01 UTC
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.

Comment 6 Brian Lane 2022-09-06 20:42:08 UTC
(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?

Comment 7 Frederick Grose 2022-09-06 21:40:41 UTC
Reported here for GRUB: https://savannah.gnu.org/bugs/index.php?63024

Comment 8 Frederick Grose 2022-09-06 21:58:25 UTC
Seems to have been reported here for shim: https://bugzilla.redhat.com/show_bug.cgi?id=2113005

Comment 9 Adam Williamson 2022-10-25 17:45:20 UTC

*** This bug has been marked as a duplicate of bug 2113005 ***