0

In a simple install of Redhat from rhel-8.10-x86_64-dvd.iso I have this

/boot/efi/EFI/BOOT/BOOTX64.EFI /boot/efi/EFI/BOOT/fbx64.efi /boot/efi/EFI/redhat/grubx64.efi /boot/efi/EFI/redhat/mmx64.efi /boot/efi/EFI/redhat/shimx64.efi /boot/efi/EFI/redhat/shimx64-redhat.efi

Can a quick explanation be given of each?

On a Dell server, in the F11 boot menu when making an Add Boot option, which of the above is the proper one to choose?

Improve this question

2 Answers 2

Reset to default
3
  • fbx64.efi is the fallback bootloader, if the selected one doesn't load
  • BOOTX64.EFI is hence the main boot loader, which loads the necessary shims from the redhat subdirectory as needed.

The other ones are essentially executables to be used by the main bootloader, and you'll want to have them all;

  • mmx64: mok signing utility, you want this if you want your server to be able to verify the bootloader it's loading is legit. Server deployments usually insist on this secure boot. If everything is correctly set up, it just calls grub.
  • grubx64: GRUB loader as loaded by the main bootloader
  • shimx64 / ~-redhat: shim bootloader that can be signed by your mainboard vendor, or a trusted third party (typically, Microsoft), and allows to boot the rest securely

On a Dell server, in the F11 boot menu when making an Add Boot option, which of the above is the proper one to choose?

That should never be necessary, though. Boot manager installation happens during operating system installation (or later, at your behest), using efibootmgr --create …. Note that if you're transplanting a boot disk from one machine to another, you must have enrolled the same signing keys on that new machine, or else secure boot will suspect you're trying to compromise the server's integrity and refuse to load your bootloaders. This is not a problem if you're not enrolling your own keys.

Improve this answer
10
  • I have multiple disks in the server I want to boot from, from RHEL-8.10 and RHEL-9.6 and RHEL-10, and I want to be able to F11 and delete all the existing menu options and then add just these 3 items... choosing the correct .efi file. so it would be the BOOTX64.efi file? I am not doing any secure booting. Commented Jul 30 at 18:49
  • not the way to go. The selection of these would usually be in GRUB, so leave your EFI files alone. Commented Jul 30 at 22:41
  • (and even if this was actually addressed by the EFI programs in that directory, still the wrong way to go: you would then still need to remove the boot loader entries from your machine's NVRAM.) Commented Jul 31 at 13:55
  • so you're saying i cannot manipulate the EFI boot manager via F11 on a [Dell] server? I need to be able to conveniently choose which of at least 2 disks in the server (out of 16 that it could possibly hold) to boot different operating systems. I simply put a rhel-8.10 on one disk, rhel-9.6 on another disk, rhel-10.0 on another, to do evaluation of software & operating system compatibility. I need an acceptable way to choose which one boots... which I can do on my home ASROCK pc. Commented Jul 31 at 14:16
  • 1
    I'm not sure why this has gotten adversarial; I apologize. It doesn't change the fact that you need to stay with modifying GRUB here. Commented Jul 31 at 15:05
3

You should see all your UEFI boot entries with either efibootmgr or whatever Fedora uses. I am familiar with Ubutnu. I would expect all three to install to same ESP - efi system partition. If on separate drives, you can then create an ESP on every drive and have a different UEFI entry for each. Default may still be Fedora or grub, but you can create a new entry, if desired. Note that

UEFI entries use GUID, so you can tell them apart in efibootmgr. I prefer to boot multiple distributions from one grub as easier to edit descriptions.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.