F37 Invalid image error while booting

So far, I’ve tried to boot these images:

  • Fedora-Everything-netinst-x86_64-37_Beta-1.5.iso
  • Fedora-Workstation-Live-x86_64-37_Beta-1.5.iso
  • Fedora-KDE-Live-x86_64-37_Beta-1.5.iso

When I try to boot them on my hardware, this is the output I get:

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

I have tried these measures:

  • Verify file integrity
  • Toggle secure boot
  • Boot from USB 2.0 and 3.0 ports
  • Write to media using dd and Fedora Media Writer
  • Format media with MBR and GPT partition tables

Yet, these images refuse to boot on my hardware. The images boot fine in VMs. Fedora 36 live images boot on my hardware just fine. What relevant info should I provide?

Solved thanks to Reddit user liwindowsnux’s comment under a post by someone experiencing a similar problem on r/RockyLinux.

  • You’ll need a tool (such as Rufus) to burn the installer ISO into the USB stick in ISO mode (not dd mode) to get access to the /<USB_Stick>/EFI folder. I guess you can also use dd mode if you can get access to the EFI partition.
  • After the burning process, backup /<USB_Stick>/EFI to somewhere else just in case.
  • Get into /<USB_Stick>/EFI/BOOT, delete the original BOOTX64.EFI and BOOTIA32.EFI.
  • Rename grubx64.efi and grubia32.efi to BOOTX64.EFI and BOOTIA32.EFI respectively.
  • Boot your system with this USB stick in UEFI mode and you should be able to boot into the installer.
1 Like

Note, that solution will only work if Secure Boot is disabled, because it bypasses shim and loads grub directly. The best solution is to copy over BOOTX64.EFI from the F36 shim-x64 package.

This is 2113005 – Live image made with BOOTX64.EFI from latest shim-x64-15.6-2 fails to boot on some boards .

@mcdoland - can you say what your motherboard model is? Thanks!

Sounds like it is related to this issue which lists some workarounds.

Listing the motherboard of concern may help, but it seems a fix is already in the works, just not yet here.

I am having the same issue both with the Fedora 37 live CD and Ventoy 1.0.82 (which uses the Fedora 37 shims). If I swap out BOOTX64.EFI and mmx64.efi with ones from either Ubuntu or Parted Magic, everything works great. I have also posted in Ventoy’s issues list here start_image returned Unsupported in v3.4 · Issue #18 · ValdikSS/Super-UEFIinSecureBoot-Disk · GitHub
and here is some of the hardware I have had trouble with Fedora 37 on:
MSI Z97A Krait Edition motherboard in custom build PC (BIOS version 2.0 and latest 2.3) with Secure Boot disabled error messages:
Invalid image
Failed to read header: Unsupported
Failed to load image: Unsupported
start_image() returned Unsupported

then it reboots

Dell Latitude 7490 laptop (latest BIOS) with secure boot enabled error messages:
Failed to open \EFI\BOOT\∎ - Invalid Parameter
Failed to load image ∎∎: Invalid Parameter
start_image() returned Invalid Parameter, falling back to default loader

but then continues to grub and works anyway

None of the disk images boot!

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

FUJITSU ESPRIMO P520 / nvidia gtx1650

I also had this problem on a laptop with a very old fedora install. Adding here for anyone in a similar boat.

Got it to boot by pushing c at the old grub prompt to get the command line, then
set root=(hd0,gpt2)
chainloader /efi/boot/grubx64.efi

For anybody looking for a bit more detail on the “power user” workaround from the common issues post:

Don’t do the below, just do what @adamwill says in the post below.

First, extract the boot images from the ISO you wish to modify:

$ osirrox -indev Fedora-Workstation-Live-x86_64-37-1.7.iso -extract_boot_images ./ -extract /EFI/BOOT/BOOTIA32.EFI BOOTIA32.EFI

Next, move the BOOTX64.EFI file from the shim package linked in the common issues post to the directory you’re working in, e.g.:

$ cp ~/Desktop/shim/boot/efi/EFI/BOOT/BOOTX64.EFI .

Update the boot image with the new shim:

$ mcopy -D oO -i eltorito_img2_uefi.img BOOTX64.EFI BOOTIA32.EFI ::/EFI/BOOT/

Finally, create a new ISO with the boot configuration taken from the original ISO, the modified boot image we made above, and BOOTX64.EFI replaced:

$ xorriso -indev Fedora-Workstation-Live-x86_64-37-1.7.iso -outdev Fedora-Workstation-Live-x86_64-37-1.7_BOOTFIX.iso -boot_image any replay -append_partition 2 0xef eltorito_img2_uefi.img -update BOOTX64.EFI /EFI/BOOT/BOOTX64.EFI

If you need help extracting BOOTX64.EFI from the shim package, you can extract the contents of the RPM to the current directory as follows:

$ rpm2cpio shim-x64-15.4-5.x86_64.rpm | cpio -idmv

1 Like

That’s an unnecessarily complicated way of doing it. All you need to do is write the ISO to a USB stick first, then just mount the relevant partition from the stick (the second one) and replace the files in a normal way - file manager, console cp, whatever. You don’t need to go to the trouble of modifying the ISO itself unless you need to write it to a DVD-R or something.

Ignore my ramblings below.

Unless I’m missing something, the partition is ISO9660 which is decidedly read only.

Believe me, I wanted it to be the case I could just copy a file over, but at least for a thumb drive made with dd, there was no way I could make that work. Even just replacing the shim on the ISO with xorriso before dd-ing wasn’t enough to make my board boot, the boot image jiggery pokery was required.

Perhaps Fedora media writer does something different? Perhaps I’m just dense. But believe me, I spent at least 3 hours trying to find a not complicated way.

The first partition on the stick is ISO9660. The second partition is FAT, and that’s where all the EFI bootloader files are - it’s an EFI system partition (it has to be, or else the stick wouldn’t boot). I just confirmed this with a stick I have here that’s written with dd.

I was sure the first thing I tried was replacing the shim on the second partition and it still refused to boot which was why I started down the road of ISO modification. But I just tried it, and it worked. Sorry for the noise!

FYI, this bug also impacts the Asus Z87-A board.

Are you selecting the second partition on the usb device to boot? That should normally boot it as uefi since that is the efi partition on the usb stick.

I am also having a similar problem. My laptop is ACER s1001. The problem that I face is similar but it has a slightly different twist with regards to the shim. The processor on my laptop is 64bit but the EFI BIOS is 32bit. I tried after replacing the 32bit shim from the centos 32bit shim but it didn’t work.

Surprisingly Fedora 31 (64 bit) is able to boot with UEFI enabled as well as disabled.

At the time fedora 31 was around fedora still supported 32 bit kernels (and may not have supported secure boot). The shim used was likely a 32 bit compatible shim.

As I explained in the bug report, we did (try to) maintain specific 64-on-32 support for those odd systems for a while. IIRC it didn’t require a 32-bit kernel, only a 32-bit shim and grub, they could boot a 64-bit kernel (the systems themselves run 64-bit code fine, they just shipped with a 32-bit firmware for some bizarre reason). This has likely been lost or just broken along the way as these systems are so uncommon; I used to have one, but got rid of it some time back, so I wouldn’t know if this broke.

We certainly have supported Secure Boot since way before F31.

Anyway, problems on those systems are very likely a different thing from the problem being discussed in this thread.

Not sure whether related but I’m suddenly unable to run Fedora 37 on an Asus M15 laptop. All attempts to remedy including installing rEFInd result in errors. The first error manifestation lost the Grub menu and only showed the BIOS. Windows then recovered as the default OS. None of the Fedora versions are yet accessible. All recovery attempts are blocked.

The latest error came with a big red message that there was a problem with Secure Boot. Turning Secure Boot off in BIOS didn’t help booting Fedora but did remove the error message.