Network boot failing for UEFI host that is already imaged


After a system is imaged on a reboot it will fail when going through /var/lib/tftpboot/grub2/grubx64.efi file

Expected outcome:
Successfully load bootloader and load Rocky 9
Foreman and Proxy versions:
3.5 Katello 4.7
Foreman and Proxy plugin versions:

Distribution and version:
Rocky Linux 9.2
Other relevant data:

Hi, I am testing Network booting EFI machines from my foreman/tftp server. I have chain load hd0 as the default in foreman’s global parameters and can see this reflected in my BIOS and grub2 grub.cfg files. In BIOS mode it works, but EFI fails.

I’ve been searching around the internet and querying chatGPT, but I don’t think I’ve come across a discussion of anything exactly like this. My knowledge of grub is limited, so any help would be appreciated to steer me in the right direction.

I downloaded grubx64.efi from the rocky 9.2 repos and replaced what was created on the foreman server at /var/lib/tftpboot/grub2.

So the system will load successfully from the default grub.cfg file, but if a grub.cfg-macaddress file is created it fails. If I delete that file after it’s imaged it will successfully boot. I’m going to look further into it this morning and try to identify the difference between the default cfg and the one that is paired with each host. Is it foreman that is responsible for creating that file, or is that a TFTP thing?

Thank you for any assistance.

Upon further digging it’s not in fact the grub.cfg-macaddress file.

It’s whether I let the boot order initiate the EFI Network boot or whether I manually intervene and select it. Automatically fails, manual succeeds. They both use the grub2/shim.efi file ( I missed that before.) I’m kind of miffed as to why one succeeds and one fails when as far as I can tell it’s the exact same boot option. ONly when I manually do it it looks a bit different and shows that it’s obtaining and IP before going to the grub menu. The failed automatic boot order one, says it’s initiating EFI Network boot but seems to skip where it obtains and IP.

This is a really weird problem to say the least. Maybe some weird bug for VMWare. They still recommend BIOS mode for a VM. A colleague in the office is going to set me up with a vPro desktop and I’ll see if the behaviour is the same or if automatic network boot succeeds.

Okay, I tested a desktop in UEFI mode and it boots fine when automatically network booting from BIOS priorities. Seems like something weird is going on with the VMs.

If anyone replies. Any ideas why this strange problem?