Try to replace the grub binary on your TFTP server with this one from RHEL:
http://people.redhat.com/~lzapleta/grub/grub2-efi-x64-2.02-0.87.el7.x86_64/grubx64.efi
Share your findings.
Hi @lzap,
I have to admit that I have a boot now since I have switched the legacy grubx64.efi for the one you provided. Since these files are binaries it is impossible to know the difference between them.
Now asides from the screens above and a looping reboot which does not end, I still cannot finalize my installation. I was due to deploy Ubuntu and this grubx64.efi seems to be adapted for Redhat or CentOs?
Regards,
PS: HTTP 404 … I don’t understand why do we have a HTTP response from Apache ?
You hav a network misconfiguration, Foreman is not running on that address. Fix that.
In regard to Ubuntu Grub - I can’t tell, sorry. I only test on RHEL/CentOS and grub is part of the OS not Foreman. It’s probably some old version or some patches are missing.
Hi @lzap,
This product is great; I really need to make it work. I chose it over maas.io and I need my team to be convinced that I did the right choice. So I’m gonna review every step and redo my lab from scratch. You said it is a network issue, perhaps did I not install or use discovery plugin the right way. I’ve been working a full month on Foreman and still haven’t seen more than the tip of the iceberg.
Regards,
hi @lzap,
Below is the process I followed.
Foreman installation:
hostnamectl set-hostname maas.sas.local
cat > /etc/hosts << EOF
192.168.1.100 maas.sas.local maas
EOF
sudo apt-get -y install ca-certificates
cd /tmp && sudo wget https://apt.puppet.com/puppet6-release-bionic.deb
sudo dpkg -i /tmp/puppet6-release-bionic.deb
sudo echo “deb http://deb.theforeman.org/ bionic 2.2” | sudo tee /etc/apt/sources.list.d/foreman.list
sudo echo “deb http://deb.theforeman.org/ plugins 2.2” | sudo tee -a /etc/apt/sources.list.d/foreman.list
sudo apt-get -y install ca-certificates
sudo wget -q https://deb.theforeman.org/pubkey.gpg -O- | sudo apt-key add -
sudo apt-get update && sudo apt-get -y install foreman-installer
sudo foreman-installer
Troubleshoot- DB fixed:
sudo dpkg-reconfigure locales
=> en_US.UTF-8 UTF-8
Generating locales (this might take a while)…
en_US.UTF-8… done
Generation complete.
sudo locale -a
C
C.UTF-8
POSIX
en_US.utf8
/Troubleshoot - DB fixed
sudo foreman-installer
Preparing installation Done
Executing: foreman-rake upgrade:run
foreman-rake upgrade:run finished successfully!
Success!
- Foreman is running at https://maas.sas.local
- Foreman Proxy is running at https://maas.sas.local:8443
The full log is at /var/log/foreman-installer/foreman.log
/Foreman installation
Foreman Configuration:
sudo foreman-installer
–foreman-proxy-tftp=true
–foreman-proxy-tftp-servername=192.168.1.100
Preparing installation Done
sudo foreman-installer
–foreman-proxy-dhcp=true
–foreman-proxy-dhcp-interface=ens33
–foreman-proxy-dhcp-gateway=192.168.1.254
–foreman-proxy-dhcp-pxeserver=192.168.1.100
–foreman-proxy-dhcp-range=“192.168.1.110 192.168.1.115”
–foreman-proxy-dhcp-nameservers=“192.168.1.100”
Preparing installation Done
sudo foreman-installer
–foreman-proxy-dns=true
–foreman-proxy-dns-managed=true
–foreman-proxy-dns-interface=ens33
–foreman-proxy-dns-server=192.168.1.100
–foreman-proxy-dns-zone=sas.local
–foreman-proxy-dns-reverse=1.168.192.in-addr.arpa
–foreman-proxy-dns-forwarders=8.8.8.8
Preparing installation Done
sudo foreman-installer
–enable-foreman-proxy-plugin-discovery
–foreman-proxy-plugin-discovery-install-images=true
–foreman-proxy-plugin-discovery-source-url=Index of /discovery/releases/latest
Foreman-Discovery:
Document: https://theforeman.org/static/legacy/manuals/Discovery%202.0.pdf
sudo foreman-installer --enable-foreman-plugin-discovery
sudo apt-get install ruby-smart-proxy-discovery
sudo foreman-installer
–foreman-plugin-discovery-install-images=true
ERROR: Unrecognised option ‘–foreman-plugin-discovery-install-images’
sudo wget http://downloads.theforeman.org/discovery/releases/latest/fdi-image-latest.tar -O /var/lib/tftpboot/boot && cd /var/lib/tftpboot/boot
sudo tar -xvf fdi-image-latest.tar
sudo chown foreman-proxy:foreman-proxy -R /var/lib/tftpboot/
Go to https://maas.sas.local/settings
=> Activate:
==> Default PXE global template entry form blank to ‘discovery’
Source: Chapter 6. Provisioning Bare Metal Hosts Red Hat Satellite 6.6 | Red Hat Customer Portal
Troubleshoot in template:
default=<%= global_setting(“default_pxe_item_global”, “local”) %>
sudo foreman-installer
–enable-foreman-proxy-plugin-discovery
–foreman-proxy-plugin-discovery-install-images=true
Foreman is running at https://maas.sas.local
- Foreman Proxy is running at https://maas.sas.local:8443
sudo fuser 8443/tcp
8443/tcp: 1045
sudo ps -aux | grep 1045
foreman+ 1045 - Ssl 11:22 0:01 ruby /usr/share/foreman-proxy/bin/smart-proxy --no-daemonize
=> Discovery Proxy is now available in subnet.
/Foreman-Discovery
/Foreman Configuration
Deployment test:
Boot fails with:
error: timeout reading ‘boot/fdi-image/initrd0.img’
grubx64.efi creation:
Option 1:
Source: Feature #12635: Options to deploy Grub and PXELinux EFI loaders in TFTP root - Installer - Foreman
=> Download:
sudo cd /tmp/
sudo wget http://security.ubuntu.com/ubuntu/pool/main/g/grub2/grub-efi-amd64-bin_2.02-2ubuntu8.17_amd64.deb
sudo dpkg -i grub-efi-amd64-bin_2.02-2ubuntu8.17_amd64.deb
dpkg: error processing package grub-efi-amd64-bin (–install):
dependency problems - leaving unconfigured
sudo apt-get install -y grub-efi-amd64-bin
sudo cd /var/lib/tftpboot/grub2/
sudo mv grubx64.efi grubx64.efi.bak
grub-mkimage — Make a bootable GRUB image:
-O --format - x86_64-efi, …
-d --directory (source) - Use images and modules from DIR.
-o --output=FILE
-p --prefix - Set prefix directory. The default value is /boot/grub.
Source: grub2-mkimage: Make a bootable GRUB image. - Linux Manuals (1)
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'
due to backtick, “`” the find and sed commands are executed before the main command grub-mkimage
<= find /usr/lib/grub/x86_64-efi/.mod -printf "%f " | sed -e ‘s/.mod//g’ replaces all ".mod" by “*” ; example:
acpi.mod => acpi; adler32.mod => adler32 …
==> Error while booting: “The firmware encountered an unepected exception …”
Option 2:
sudo wget http://downloads.theforeman.org/foreman-bootloaders/foreman-bootloaders-fedora-201707171807.tar.bz2
I extracted grubx64.efi and copied it to grub2 directory.
/grubx64.efi creation
I tried a new installation and could ping PXE-Client (Discovery status: Success) at this step:
I don’t understand why the installation doesn’t initiate ; the only choice is to reboot and I got the same screen. It should load the kernel (vmlinuz0). This file is in the right place, in boot:
/var/lib/tftpboot/grub2/boot/fdi-image# ll
total 249624
drwxr-xr-x 2 foreman-proxy foreman-proxy 4096 Oct 21 2019 ./
drwxr-xr-x 3 foreman-proxy foreman-proxy 4096 Oct 10 15:22 …/
-rw-r–r-- 1 foreman-proxy foreman-proxy 248859421 Oct 21 2019 initrd0.img
-rw-r–r-- 1 foreman-proxy foreman-proxy 250 Oct 21 2019 README
-rw-r–r-- 1 foreman-proxy foreman-proxy 153 Oct 21 2019 SHA256SUM
-rw-r–r-- 1 foreman-proxy foreman-proxy 6734016 Oct 21 2019 vmlinuz0
Below are my templates for the OS:
I put Default PXE Global on “discovery”:
My subnet:
I did a tftp test:
root@gregory-XPS-13-9380:/tmp# tftp
tftp> verbose
Verbose mode on.
tftp> connect 192.168.1.100
tftp> get boot/fdi-image/vmlinuz0
getting from 192.168.1.100:boot/fdi-image/vmlinuz0 to vmlinuz0 [netascii]
Received 6782157 bytes in 4.9 seconds [11072909 bits/sec]
Did I miss anything??
Best regards,
PS: Build is set to “false” but doesn’t seem a 404 to me … Perhaps I’m wrong. In fact no 404 in the logs … Token is ok.
Hi @lzap,
I tried with Discovery this time (the VM was visible there with its MAC address) but I encountered two issues:
-
PXE-Client boots automatically; a good point. But I have to remove this file otherwise the client fails:
=> grub.cfg-00:50:56:3c:2e:53 -
Grub points on “Chainload Grub2 EFI from ESP” default menu and I have the following screen:
Do I need to create a boot in /var/lib/tftpboot/EFI/ubuntu and add grubx64.efi, and the rest?
Regards,
I removed IPv6 from the newly created host and got this screen. It seems that grub.cfg-00:50:56:3c:2e:53 doesn’t trouble me anymore; I left it.
Grub2.cfg:
Each time I have a different behavior; not easy to scope where is the root cause.
Regards,
PS: What is strange, I deleted the host in Foreman and have issues with Dsicovery plugin. My host still boots with Fetching Netboot Image without the standard PXE process. My host is not discovered in Foreman GUI. Is there any method to restart discovery service?
systemctl | grep foreman
foreman-proxy.service - loaded active running Foreman Proxy
foreman.service - loaded active running Foreman
foreman.socket - loaded active running Foreman HTTP Server Accept Sockets
I restarted these three services but the behavior is the same:
systemctl restart foreman-proxy.service
systemctl restart foreman.service
systemctl restart foreman.socket
Regards,
I restarted Foreman server too; I changed my VM MAC address. I recreated a host from scratch and I still have Fetching Netboot Image … I use the legacy and default PXEGrub2 template now.
I have no explanation; I don’t understand what happens now. Even the VM was hard restarted.
I had to remove the VM and recreate another one not to get this behavior as if some data was in the VM’s UEFI. Discovery doesn’t find any VM now.
hi @lzap,
Even after having recreated the VM I have my screen … “Fetching Netboot Image”. EFI is really different from BIOS; it was really easy with the latter. Legacy BIOS is going to be replaced forever that the reason I insist on it …
https://www.bleepingcomputer.com/news/hardware/intel-plans-to-end-legacy-bios-support-by-2020/
Regards,
hi @lzap,
If I sum up correctly, the process of provisioning is the following:
-
UEFI downloads grub2/grubx64.efi from TFTP
-
GRUB2 looks for grub2/grub.cfg-[mac address]
=> I don’t know why ?? -
Grub2 template contains the automated install configuration generated by Foreman
-
GRUB2 downloads kernel (vmlinuz0) and initrd0.img and boots the kernel and starts the installer
=> from fdi-image/ -
The image of the system is retrieved from the installation media specified in OS and from the client:
=> http://archive.ubuntu.com/ubuntu (in my case) -
After installation is complete, PXELinux template is changed back to chainload local disk
How can I generate a grubx64.efi which can work?
-
You gave me this version but it is not debian and it failed (CentOS/RHEL):
http://people.redhat.com/~lzapleta/grub/grub2-efi-x64-2.02-0.87.el7.x86_64/grubx64.efi -
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 …" -
I tried with another one which I was sure would fail:
http://downloads.theforeman.org/foreman-bootloaders/foreman-bootloaders-fedora-201707171807.tar.bz2
=> “Fetching Netboot Image”
I wish I could use CentOS but I cannot, I must use Ubuntu 18.04.5 LTS.
Regards,
This looks like a bug we are looking into.
For the rest I don’t know what you’re after.
For better understanding I suggest you to read https://docs.theforeman.org/master/Provisioning_Guide/index-foreman.html
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.
hi @lzap,
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!!
WORD. 
For the record, this error happens when HDD is not selected as the second boot device.
Hi @lzap,
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!!!
Regards,
1 Like
Hi @lzap,
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!
Regards,
Gregory
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.