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.
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.
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
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.
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!
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.