Rocky Linux 8.5 UEFI Install Issue


I have a refurbished SuperMicro server that’s not particularly new (my guess is from around 2013-2014) and has been running CentOS 8.1 for a while now. With Red Hat’s switch to CentOS Stream, I wanted to try Rocky Linux since I don’t want a bleeding-edge OS running on my server. The server supports Legacy Bios and basic UEFI (enough to allow UEFI OS installs), but for some reason, I can’t seem to get Rocky Linux 8.5 to install as UEFI. When I select the UEFI USB option from my boot menu, I get the following error preventing me from even getting to the UEFI installer grub prompt:

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

But when I select the regular Legacy USB option, I’m greeted with the Legacy Rocky Linux installer grub prompt (I know it’s the Legacy version since I checked that /sys/firmware/efi doesn’t exist once I’m in Anaconda). I’ve scoured Google with not much success, and the only other post on these forums I could find was this, but they ended up just installing in Legacy mode.

I’ve tried every since conceivable way of setting up the USB installer (DD on linux, Etcher, Fedora Media Writer, GNOME Disk Image Writer, and every possible configuration on Rufus) using two different computers, and they all have the same result. I also made sure all my downloaded images had the correct SHA256 checksums. What’s extra weird is, creating a CentOS 8.5 USB installer launches the UEFI installer no problem on this server.

Has anyone seen this issue with Rocky Linux or any other distro before? I saw that Rocky Linux 8,5 added Secure Boot functionality, and I’m pretty sure my server doesn’t support Secure Boot, but that shouldn’t break my ability to run Rocky Linux in UEFI mode right? If it helps, my server’s running a SuperMicro X9DRi-LN4F+ motherboard with dual E5-2670 v2 CPUs and 168GB of RAM. Thanks for any and all help! :grin:


Surely you have installed all CentOS Linux updates? If you have, then your CentOS 8 has already 8.5-based content.

Rocky has a sidegrade migration script that essentially replaces CentOS repo definitions with Rocky definitions and then reinstalls/updates all packages with versions that are in Rocky’s repo. That would avoid the install.

However, the question about UEFI installer is important. I presume that you did test every install media in some other UEFI system too?

However, the question about UEFI installer is important. I presume that you did test every install media in some other UEFI system too?

Other than this, did you ever manage to get another UEFI system installed on that server? I’m not 100% sure about this but maybe CentOS falls back to BIOS? I would suggest testing another OS with UEFI boot just to be sure.

Good point, out of all the things I tried, I did indeed forget to try another computer (since I wasn’t planning on installing it on another computer :joy:). I just tried on my laptop that dual boots Windows and Ubuntu, and I did get to the UEFI install grub prompt. Strangely though, the following message popped up for a few seconds before it showed the UEFI install grub prompt:

Failed to open \EFI\BOOT? - Invalid Parameter
Failed to load image \EFI\BOOT? - Invalid Parameter
start_image() returned Invalid Parameter, falling back to default loader

So I got a different message on my newer laptop, but it also seemingly “recovered” and proceeded to the UEFI install grub prompt as expected :thinking:.

So I did start to get paranoid of this too and did verify that both my current CentOS 8.1 install and the CentOS 8.5 installer did run in UEFI mode (/sys/firmware/efi/ was present in both scenarios) on this server :thinking:.

1 Like

I had the same issue on older hardware (HP model Z1 G2, ca. 2014), and it started with the 8.5 ISOs. Both CentOS and Rocky have the same problem, and I presume RHEL as well. Seems to be specific to older UEFI implementations.

Newer systems (HP Z8 G4, ca. 2018) do not have the issue.

Switching back to legacy (BIOS) boot mode is a workaround, or you can use the 8.4 boot media and stay in UEFI mode. Once my old system was loaded it can update to 8.5 and boot from disk in UEFI mode without issue, it was just the boot ISO images that have the problem.

Hopefully someone can fix this in 8.6.

This is going to sound mean, but I’m so glad to hear someone else had this same issue because at least it shows I’m not nuts or doing something wrong. :joy:

That’s the crazy thing for me though, CentOS 8.5’s installer seems to work just fine (at least in terms of getting into the UEFI installer)! :sweat_smile:

Yeah I was actually considering that myself as well. Do you have any idea where I can find download the 8.4 ISO? I’m new to the site, but looking around, I couldn’t find any ISO “archive” that would have an older version of the OS to download. I absolutely might have just missed it though. :thinking:

Nevermind, I scoured the site index and found the directory with 8.4’s x86_64 files. In case anyone else is looking for it:

1 Like

Okay, so I did some investigation and experimentation, and I think I found a pseudo “solution” (which is probably unnecessarily more complex than just installing 8.4 and upgrading :sweat_smile:). Since the issue revolves around booting, I did some digging into the various bootloaders present on the install media and Linux installs in general. I came across this Stack Overflow post that includes a decent explanation of what the various bootloader EFI files do.

If my understanding is correct (someone please correct me if it’s not), OS installers like those on USB drives and CDs will default to booting using the BOOTX64.EFI file since that’s the default bootloader all UEFI systems look for. Once the installation completes, the installer sets up the system’s NVRAM to have it boot the newly installed Linux distro using the grubx64.efi bootloader.

Going off these understandings and assumptions, I used Rufus on my Windows desktop to create a Rocky 8.5 USB installer in ISO mode (emphasis on ISO mode, not DD mode) with the following configuration (mostly default values):

While it was burning, I downloaded the Rocky 8.4 ISO to my laptop running Ubuntu and mounted the image to a temporary directory. When Rufus finished, I plugged the flash drive into my laptop and replaced the BOOTIA32.EFI and BOOTX64.EFI files down <Rocky 8.5 USB root directory>/EFI/BOOT/ with the versions from <Rocky 8.4 ISO mounted directory>/EFI/BOOT/.

With this custom USB installer, I was able to boot into the Rocky 8.5 installer with no error messages and successfully install Rocky 8.5 on my server. Given this actually worked, it would suggest something is wrong with 8.5’s BOOTX64.EFI (and possible BOOTIA32.EFI) files that breaks compatibility with old UEFI systems.

I have no idea what can be done to “fix” this or if it’s even technically a “bug” to “fix” in the first place, but I’m hoping one of the Rocky team members might see this and have a better idea of what might need to be “fixed” in future releases. :grin:

1 Like

Once upon a time … I did install CentOS, neatly in UEFI mode and (GPT) partitioned to leave space for other OS.
The other OS, MS Windows 7 from USB made by MS, did boot only in legacy; UEFI could not see /EFI/BOOT/BOOTX64.EFI on the USB. (I was lucky to have GPT there as showstopper or I had missed the error.)
The reason (found out by comparing CentOS and Windows install medias) was that the case of characters in path /EFI/BOOT/BOOTX64.EFI was not what the UEFI implementation was looking for (from “case-insensitive” FAT32!!).

Similar to you, I did end up copying content from read-only MS USB into writable USB, and then renaming the offending paths.

1 Like

I had a similar problem with new hp Proliant G10 hardware. I tried many solutions and finally @rindi suggested I use Ventoy to create my bootable USB. It worked like a champ. Might give it a try.



I can’t believe I’d never heard of Ventoy before, and holy moly it did indeed work! Given it seems to use it’s own Grub bootloader to launch you into another ISO’s installer, I’m guessing it circumvents using the ISO’s own bootloader which inadvertently gets around this issue (even though it’s not really a “fix” per se :joy:). I’ll be honest, I still kind of like my own overly-complicated hacky solution, but I think your answer deserves the title of “Solution” given it’s way easier to do and requires little to no technical knowledge. :grin:

I never had heard of this before but it is my toolbox now. happy installing!


1 Like