Grub2 uefi provisioning

Support
1

Problem: grub bash like terminal after boot an uefi machine for provisioning

Expected outcome: grub provisioning menu

Foreman and Proxy versions:
1.20.1 over centos 7.6.1810 clean install

Other relevant data:
Tested provisioning with a bios virtual machine first and Centos 7, everything ok. The settings i chose for the first machine was kickstart default, kickstart default finish, kickstart default PXELinux, kickstart default user data and PXELinux BIOS as PXE Loader in the machine.

Then use a uefi machine, add “Kickstart default PXEGrub2” to the Operating system, and set the PXE Loader to “Grub2 UEFI”. Start the machine and hangs in grub shell

logs

Jan  4 14:02:00 foreman dhcpd: DHCPACK on 192.168.1.13 to 52:54:00:0f:27:50 via eth0
Jan  4 14:02:13 foreman in.tftpd[5892]: RRQ from 192.168.1.13 filename grub2/grubx64.efi
Jan  4 14:02:13 foreman in.tftpd[5892]: Client 192.168.1.13 finished grub2/grubx64.efi

i don’tsee a request for grub.cfg or grub.cfg-01-52-54-00-0f-27-50 int the tftpd server, also
nothing in tcpdump

14:02:13.790930 IP 192.168.1.13.55079 > foreman.internal.ra.tftp:  47 RRQ "grub2/grubx64.efi" octet blksize 1432 tsize 0
2

Can you check grub2/grubx64.efi for corruption? I am assuming you are booting x86_64 bare metal? Can you doublecheck UEFI is turned on and SecureBoot turned off? Also there are some options in UEFI firmware named Other OS that needs to be enabled too sometimes.

3

i don’t know how to check grub2/grubx64.efi for corruption, can you explain a little more on that? in any case the md5sum of the filein the /var/lib/tftpboot/grub2 directory is fd659e2b532e1fdde0e8c8fdd513ffc6 , the file in the centos repo has a checksum of 006072d890636938999b315dbce54874. For the testing i’m using kvm virtual machines with uefi bios, but i can test with a bare metal uefi machine in the course of the week (need to clone the hard drive first, so i can restore later)

4

The grub2 is generated actually so I misled you, you can’t easily check for corruption. However I see you are using libvirt KVM/QEMU for testing. This is a bit problematic as UEFI implementation is currently work in progress and your mileage may vary. For example KVM/QEMU UEFI firmware in RHEL/CentOS is a bit old and buggy, you need to use latest firmware from Fedora:

https://lukas.zapletalovi.com/2017/10/efi-with-libvirt-in-rhel7.html

Even in some Fedoras UEFI firmware in QEMU was not working, granted this is few years back. Check that:

https://lukas.zapletalovi.com/2014/09/efi-in-qemu-kvm-on-fedora-20.html

5

ok, i tested with a intel nuc with uefi and everything work, so qemu was the issue even when i try with two different versions , qemu in ubuntu 14.04 and qemu in ubuntu 16.04.

Now im testing building ubuntu 18.04 and centos 7.4 machines in uefi and bios mode. When i finish my test i’ll write a guide about how to use in from installation to provisioning.

By the way is an awesome piece of software. This need more acknowledgement from free software community.

1 Like
6

State of libvirt UEFI in Debian/Ubuntu is a little bit worse than Fedora / Red Hat. They are probably little behind and eventually it will work. One of the reasons why I prefer CentOS / Fedora - virtualization is in better shape. :slight_smile: