Skip EFI entry installation

Question

Skip EFI entry installation

fsrv-xyz opened this issue a year ago · comments

Hello there,

we are deploying RHEL-based distros onto dedicated servers. Our use case is to keep network boot as the first option in our boot order which loads the installed systems' bootloader.
This brings us the option to boot the system more flexible from network when needed.

Unfortunately, shim calls the fallback binary at first startup after installation and prepends a boot entry for the system itself to the boot order. The system would not be able to boot from network without manual interaction after that point.

I found this function which "decides" if the fallback is needed. Unfortunately, I was not successful triggering a return value of 0 at that point without calling a system reset (tried removing the fallback binary).
I also tried to modify the shipped BOOT.CSV (to not create the boot entry in fallback) which results in system resets every time.

Is there an option preventing that behavior to not touch the EFI boot order at all?

Kind regards
Florian

Dennis Tseng · Answer 1 · Sun May 07 2023 18:21:29 GMT+0800 (China Standard Time)

Please try the following steps:
[step-1] use the efibootmgr to move your network boot as the 1st priority order
sudo efibootmgr -o xxx,xxx,xxx

[step-2] delete/rename boot/fbx64.efi or fallback.efi
This will result in should_use_fallback() return 0, and also will not prepend any boot entry to your boot options. Actually, fbx64.efi not existing is acceptable, e.g. removable media.

Florian Bauer · Answer 2 · Mon May 08 2023 16:23:49 GMT+0800 (China Standard Time)

@dennis-tseng99 I tried the steps you provided.
Unfortunately, the system is not booting at all after removing/renaming the file /boot/efi/EFI/BOOT/fbx64.efi.

I get the following errors:

After showing that messages for some seconds, the system goes to system setup screen.

Dennis Tseng · Answer 3 · Tue May 09 2023 16:59:35 GMT+0800 (China Standard Time)

@fsrv-xyz Thanks for your feekback.
When deleting fbx64.efi, many "Not Found" occur for sure. This is because fbx64.efi and grub.efi are not found in EFI\boot
You can trace the shim.c to prove this:

int use_fb = should_use_fallback(image_handle);
.....
start_image(image_handle, use_fb ? FALLBACK :second_stage);

Anyway, let's focus on how to change your boot order. Please make use of UEFI GUI to adjust your network boot order, like this:

Florian Bauer · Answer 4 · Tue May 09 2023 21:10:41 GMT+0800 (China Standard Time)

@dennis-tseng99 Thank you for your answer.

During the complete test time, the boot order of my system had entries for network boot as well as the entries for each disk.

# efibootmgr -v
BootCurrent: 0002
Timeout: 1 seconds
BootOrder: 0002,0003,0004
Boot0002* UEFI: PXE IPv4 Intel(R) Ethernet Connection (17) I219-V	PciRoot(0x0)/Pci(0x1f,0x6)/MAC(<redacted>,0)/IPv4(0.0.0.00.0.0.0,0,0)..BO
Boot0003* UEFI OS	HD(1,GPT,8fe177d2-7aa4-4655-86b0-245067f8fed9,0x1000,0x80000)/File(\EFI\BOOT\BOOTX64.EFI)..BO
Boot0004* UEFI OS	HD(1,GPT,bf770ccc-9a05-494b-8efc-b4efbf4422a2,0x1000,0x80000)/File(\EFI\BOOT\BOOTX64.EFI)..BO

You are right with changing the boot order will help to boot from network again.
At our datacenter scale, booting each server (also ones directly assigned customers) manually from network would have a huge impact on automation grade of our whole setup.
As written in my initial message, the servers need to have network boot at first position all the time to ensure the server is booting after sending a hardware reset signal to it.

Alberto Ridolfi · Answer 5 · Sun Jun 11 2023 07:46:00 GMT+0800 (China Standard Time)

It might be a good idea to report this also on https://bugzilla.redhat.com
That way it might catch their attention more and maybe they will give it more consideration

Kleis Auke Wolthuizen · Answer 6 · Mon Sep 11 2023 01:45:09 GMT+0800 (China Standard Time)

I also tried to modify the shipped BOOT.CSV (to not create the boot entry in fallback) which results in system resets every time.

Assuming you're testing this on x64, you'll probably need to modify the architecture-specific BOOTX64.CSV variant, as this shim will look for every directory in \EFI\ with for this file first, it'll only fallback to BOOT.CSV if that's not found.

Note that this CSV file must adhere to UTF-16 LE encoding and include a byte-order mark (BOM) at the beginning of the file. It looks like this on Fedora:
https://src.fedoraproject.org/rpms/shim/blob/rawhide/f/BOOTX64.CSV

Kleis Auke Wolthuizen · Answer 7 · Wed Sep 13 2023 00:31:29 GMT+0800 (China Standard Time)

Unfortunately, the system is not booting at all after removing/renaming the file /boot/efi/EFI/BOOT/fbx64.efi.

IIUC, this is expected, you also need to put a copy of the GRUB EFI binary at /boot/efi/EFI/BOOT/grubx64.efi, as the shim bootloader searches for grubx64.efi within the same directory where it resides.

So, on Fedora, to prevent shim from trying to add a new efibootmgr entry pointing to /boot/efi/EFI/fedora/shimx64.efi, you could do the following:

$ rm /boot/efi/EFI/BOOT/fbx64.efi
$ cp /boot/efi/EFI/fedora/grubx64.efi /boot/efi/EFI/BOOT
$ tree /boot/efi/
/boot/efi/
└── EFI
    ├── BOOT
    │   ├── BOOTX64.EFI
    │   └── grubx64.efi
    └── fedora
        ├── BOOTX64.CSV
        ├── grub.cfg
        ├── grubx64.efi
        ├── mmx64.efi
        └── shimx64.efi

Note that upgrading shim will restore /boot/efi/EFI/BOOT/fbx64.efi. To avoid this, you might want to backup /boot/efi/EFI/fedora/BOOTX64.EFI, then do sudo dnf remove --setopt=protected_packages= shim-x64 and then restore the backup.