I tried to create one with the below and failed:
sudo grub-mkimage -O x86_64-efi -d /usr/lib/grub/x86_64-efi -o /var/lib/tftpboot/grub2/grubx64.efi -p “” find /usr/lib/grub/x86_64-efi/*.mod -printf "%f " | sed -e 's/\.mod//g' => Error while booting: "The firmware encountered an unepected exception …"
Grub2 in Red Hat automatically searches for these configuration files, if they are missing it skips. Grub2 in Debian does not have this feature patched-in so we emulate this behavior:
Grub2 should not fail on these. It should carry on, I don’t have Foreman on Debian myself but in CentOS this only shows warning/error but carries on.
Note there are some limitations for IPv6 provisioning. More about these in the guide.
Our installer generates grubx64.efi for you. Just run it again to have it regenerated.
I suggest you to start with BIOS to get an understanding how all bits fit together. Then move on to EFI.
I was focusing on grubx64.efi while something else was disturbuing the process. I had tested with Legacy BIOS and I knew it worked; I followed your advice and could not understand why it failed this time …
My apologies for your time spent on this. DHCP is a tricky thing, even though Foreman provided an IP address my BOX’s DHCP was interacting. I was sure that it could not be possible but:
Rule 1: If you want Foreman or any PXE solution to work, be sure not to have any other DHCP server in the area.
You can consider this request solved. Foreman is powerful and thanks to you @lzap and all the team for this product!!
Thanks for this information. I will continue my tests with different options, custom partitioning, different scripts, … I am very amazed to see such a support on Open Source; congrats!!!
I wanted to finish on this after a new installation following exactly the same steps I did on Workstationpro.
I had this DHCP issue at first as I told you but what was strange I had another issue on my second installation which is a Bare Metal one:
Both grubx64.efi were not the same and I encounter the same issue I had on WorkStationPro:
The one which doesn’t work:
sha256sum grubx64.efi
f6f88693e6131383815e6eced2165a7fe9f3877ed154aa50f6a2467195c1a552 grubx64.efi
The one which works:
sha256sum grubx64.efi.working
e2ccd77013bdd4d15d5939675ed9a25c93b4f4c4b039268f9bd7787fae0f9b24 grubx64.efi.working
I don’t know why but for the same version of Foreman I got two different versions of grubx64.efi.
The result is a race between both files and at the end provisioning fails: "/httpboot/grub2/grub.cfg-4c:d9:8f:ba:36:3b" octet blksize 1024 tsize 0 "/grub2/grub.cfg-4c:d9:8f:ba:36:3b" octet blksize 1024 tsize 0
I wanted to send these files but couldn’t … I don’t know how is this file generated but an insight would be cool!
This file comes from grub2-efi RPM package which installs it into /boot/EFI. Then Foreman installer copies this file (everytime you execute it if the file is older) from this location to /var/lib/tftpboot.
BUT. On Debian installation this is different, instead our installer uses grub-mknetdir command to compile the file from a grub2 subpackage. The key difference is that on Debian the resulting file is NOT digitally signed so SecureBoot does not work. Debian does not sign its bootloaders, you can copy one from Ubuntu or sign it yourself.
I went in my Foreman server that is the same Ubuntu version I want to deploy on Bare Metals and want to know if I can use this file?
/boot/efi/EFI/BOOT/BOOTX64.EFI*
Otherwise I have grubx64.efi*, shimx64.efi* in /boot/efi/EFI/ubuntu …
Perhaps it will do the trick?
I do understand that Red Hat/CentOS is more adapted but I am compelled to work on Ubuntu …
These patches are already included in RHEL 7 and 8, if you want to use grub2 from Debian or Ubuntu you need to ask Debian/Ubuntu developers to carry those patches. Or build your grub from sources. I think it’s easier to simply take Grub2 from Fedora Rawhide which is the latest and greatest with all Red Hat patches applied and use that, even within Ubuntu/Debian environment. Bonus: SecureBoot will work too.
