"Invalid image": BIOS fails to load image from bootable USB

I’ve been trying to reinstall Fedora after I messed up my previous installation.
So far, I have tried to use both a USB mass media storage device and a 4GB off-brand USB stick, and I have loaded both devices with a bootable image via Fedora Media Writer. I have also tried using Rufus on the second device, but to no avail.
The computer clearly recognises the USB devices, but when trying to boot up the image, the following error is returned:

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

I’m pretty sure I selected the correct image architecture, and I have “Secure Boot” disabled, so I no longer know what could be the cause of this.

Does anyone have any idea of why this error is showing up?
Thank you.

P.S.: Please ask for any hardware info you might need to help me out on this. Once again, thank you.

First guess is that your BIOS is set to boot in legacy mode, while your media was written to only work in UEFI mode.
There is probably a BIOS setting that is effectively a three way choice between secure-UEFI (which you indicated you did not choose) vs. regular UEFI vs. legacy.

The actual error message seems more plausible for the reverse: BIOS is UEFI, while media is legacy. I doubt you could do that by accident with Fedora Media Writer, but I could be wrong.

I’ve had much better luck with Ventoy. You use its installer to put it, including an ordinary filesystem partition, onto a USB stick, then just copy the desired ISO file(s) to that partition.

It then tolerates a wider range of BIOS’s that aren’t exactly following the standards.

If you copied the default fedora ‘live’ ISO image to the USB, it is a hybrid image and can boot to either legacy mode or uefi mode.

I do not know what (if any) other OSes may be installed on that machine, but if it has windows then windows requires a gpt partition if installed in uefi mode and requires an msdos partition if installed in legacy (MBR) mode.

As noted above, the BIOS usually has a setting for the boot mode that in most is a choice of a) csm (which allows booting in either mode) or b) uefi only. Sometimes there is a third choice which would be legacy only.

If the bios is set to uefi and you selected the wrong mode to boot then it fails as noted.
On my system when booting from a live USB image I see 2 choices in the bios boot menu for that usb device. One appears as a plain usb stick image, and the other has ‘uefi’ overlaid on the usb stick image. Whichever one is selected picks the boot mode and the boot and install is attempted in the mode selected.

I have the exact same problem. My Surface Pro 3 is UEFI, and there is no way to change it in the setup menu. I can, and have, set the boot order to USB → SSD.

I used Media Writer, and the dd command, and balenaEtcher, with the same results every time.

I used 2 different live versions, and one of the atomic versions.

I seem to recall that there were certain machines that could not boot directly from the F39 image. It may have been the surface pro.

In that case the fix as I recall it was to install F38 then do the upgrade on the already installed system. I have not seen recent posts on the matter, but this seems a potential cause.

Maybe this is related?

I will try that. Where can I find an archive of previous versions? I have looked everywhere on fedoraproject, they must be elsewhere. Of course, I could have missed some pages.

Closest mirror:
Master server:

Thanks for the pointer to the archives. Unfortunately, none of the archives have versions as early as 36.

My solution, if it can be called that, was to use a lenovo ideapad 330 to do the install onto a usb flash drive. Used the Plasma edition. It boots and runs fine on my MS Surface Pro 3.

Whatever works


has almost all the fedora releases F36 and earlier.

Thanks Jeff V
Followed the link and it said the archives have been moved

One possible issue, it is not a secure server.

Maybe, but more likely it was done for better organization of the storage. In any case the ISOs are there for use with the older releases. The CHECKSUM files are available with each ISO so you can verify they are correct and not corrupted.

Note that it is still the same server, just not using the https format.

You might try this