Bug 2135923 - BOOTX64.EFI cannot boot
Summary: BOOTX64.EFI cannot boot
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: shim
Version: 37
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Peter Jones
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-10-18 19:27 UTC by Michael Riss
Modified: 2023-07-24 13:23 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: ---
Doc Text:
Clone Of:
Environment:
Last Closed: 2023-07-24 13:23:02 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Michael Riss 2022-10-18 19:27:18 UTC
Description of problem:
Trying to boot Fedora-Workstation-Live-x86_64-37-20221017.n.0.iso on my machine fails with

Invalid image
Failed to read header: Unsupported
Failed to load header: Unsupported
start_image() returned Unsupported

This behavior has already been reported here: 
https://ask.fedoraproject.org/t/f37-invalid-image-error-while-booting/26632
and the solution (renaming the grub*.efi files to corresponding BOOT*.EFI files)
helps also in my case to boot into the initial ram disk. It fails then because I copied 
all the files of the ISO image to a FAT32 filesystem which leads to failure in a later stage of the installer.

My machine is a Intel Haswell i7-4790K on an Asrock Z97 Extreme 4 Motherboard with 
BIOS version 2.60.

Version-Release number of selected component (if applicable):
shim version included in Fedora-Workstation-Live-x86_64-37-20221017.n.0.iso

How reproducible:

Steps to Reproduce:
1. Boot Workstation ISO on an affected machine.


Actual results:
Boot fails with:

Invalid image
Failed to read header: Unsupported
Failed to load header: Unsupported
start_image() returned Unsupported

Expected results:
Installer booting.

Additional info:

Comment 1 Michael Riss 2022-10-18 19:36:31 UTC
There seems to be a related issue upstream:

https://github.com/rhboot/shim/issues/490

Comment 2 Michael Riss 2022-10-19 23:00:33 UTC
Some more info:
- I have secure boot disabled on my machine.
- I did some more experimenting. I copied the contents of the Live ISO image to an USB stick with FAt32 file system as before. But this time
I addressed the problem later in the boot chain. The issue is that the second stage is located with a kernel boot parameter such as "root=live:CDLABEL=Fedora-WS-Live-37-20221018-n-0". This file system label is too long for a FAT32 file system and hence the problem. Once I shorten this label down to 8 letters and adapt the kernel boot parameters the second stage also works.
With this setup I was able to drill down to the problem:
  - copying grubx64.efi to BOOTX64.EFI still works as described above
  - I downloaded and compiled several versions of the shim package https://github.com/rhboot/shim. Each time I copied the resulting shimx64.efi binary to EFI/BOOT/BOOTX64.EFI of the Live Image.
    - the latest master version solves the problem
    - using the last version before the proposed fix (https://github.com/rhboot/shim/commit/4fd484e4c29364b4fdf4d043556fa0a210c5fdfc) still shows the problem
    - the one one commit with the proposed fix (https://github.com/rhboot/shim/commit/14d63398298c8de23036a4cf61594108b7345863) also resolves the problem
    So, for me the proposed fix does the trick and from my side I suggest to include it into future versions of the install images.

What I could not test yet are actual ISO images. I tried to find a working guide showing how to build such an installation/live ISO image, but so far I had no luck (pointers are welcome).

Comment 3 Thomas Crider 2023-04-21 21:30:45 UTC
this appears to be a duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=2113005

Comment 4 Michael Riss 2023-07-24 13:22:53 UTC
Closing this issue as I have retired the machine on which the error showed up and hence cannot test possible fixes for it.


Note You need to log in before you can comment on or make changes to this bug.