I’m using Foreman 1.19.1 to deploy esxi 6.5 on Dell servers and its working well on my main site. I’ve now setup a secondary Foreman proxy server at a remote location with just dhcp, discovery and tftp.
Server will PXE boot to the Discovery image and be “discovered” on the master Foreman proxy server and then it’ll install esxi 6.5 successfully.
Problem comes up when it reboots and defaults to the Discovery Image instead of “Chainload Grub2 EFI from ESP”.
Manually selecting “Chainload Grub2 EFI from ESP” then gives the following messages:
Probing ESP partition … found hd0.gpt1
File grubx64.efi not found on ESP.
Update pxegrub2_chainload paths array with:
./ …/ boot/ VMware/ Dell/
pxegrub2_chainload has already been updated previously to get Foreman working at my main site:
this is really a horrible hack. There are two options - make this working and you really need trial and error here as I don’t have these Dell servers with SD cards here to test it. Or use the new approach I tend to recommend these days - change boot order to boot from HDD (or SD card whatever) instead.
There is a snippet which should help you with this a bit. It really depends on EFI vendor if the system will change boot order after new EFI entry putting it as the first or as the last. Some vendors allows you to configure this, so you can decide. Or you can use this snippet and change the ordering via script, however there are challenges (boot entry name is always different).
If you want to try to chainloading stuff, then make sure you use the latest and greatest version from community-templates as there were some changes. Also put DELL/VMWARE EFI files into paths array instead of the BOOTx64.EFI which is I think just some shim:
paths = [
You need to find the path first, make sure not to make a typo. That should work.
Thing is it all works fine at my main site where the master Foreman server is located. Physical host has PXE selected as first boot option:
Server defaults to “discovery image” on first boot.
Then I configure it for build and it reboots into the esxi installer.
Once esxi is installed, it reboots and defaults to “Chainload Grub2 EFI from ESP”.
Then it loads esxi and runs the customised kickstart script from a Provisioning Template.
Finally it reboots and defaults again to “Chainload Grub2 EFI from ESP” and loads esxi all ready to go.
But when I point a physical host to use the remote smart proxy (with dhcp, tftp, discovery and templates features installed), it fails at step 3 where it defaults to “discovery image”. And if I select “Chainload Grub2 EFI from ESP” manually, it says “File grubx64.efi not found on ESP”.
So I reckon I’m not understanding how the remote smart proxy is suppose to work. The physical host gets a dhcp lease correctly, boots into the esxi installer correctly but doesn’t seem to be able to read the pxegrub2_chainload template from the master Foreman server. Hence it can’t find /EFI/BOOT/BOOTx64.EFI even though its there.
The tftpboot directory from the Foreman master is synced to the remote proxy (every 15 seconds). I can see the mac address “directory” created under tftpboot with the boot.cfg file. But the corresponding mac address “file” under the pxelinux.cfg directory isn’t created.
Adding the 3rd entry above “tftpboot/grub2/grub.cfg-01-mac-address” allowed "…reboots and defaults to “Chainload Grub2 EFI from ESP …” to work. It found the /EFI/BOOT/BOOTx64.EFI file and ESXi loaded successfully.
So I need to get “tftpboot/grub2/grub.cfg-01-mac-address” created automatically. It does when the physical host points to the master Foreman server for the build process. But it does not when pointed to the remote smart proxy.
The “mac address files” were actually being created on the remote smart proxy. But the script syncing the tftpboot folder from the Foreman Master to the Remote Proxy was deleting them. Thanks to rsync’s “–delete” option.
I need to get away from computers for a while.
Sorry for wasting your time lzap. Have a great weekend.