0

I would like to PXE boot some ESXi hosts using UEFI, but keep getting the following message:

enter image description here

I am testing with a VM and can see it hitting the DHCP/TFTP server (CentOS 7) in a packet capture (3 reboots were captured as follows):

09:18:04.995404 IP 192.168.0.136.rsc-robot > stager.test.lab.tftp:  50 RRQ "efi.x64/syslinux.efi" octet tsize 0 blksize 1468
09:18:04.997399 IP 192.168.0.136.cera-bcm > stager.test.lab.tftp:  42 RRQ "efi.x64/syslinux.efi" octet blksize 1468
...
09:18:40.700760 IP 192.168.0.136.itm-mcell-u > stager.test.lab.tftp:  50 RRQ "efi.x64/syslinux.efi" octet tsize 0 blksize 1468
09:18:40.704583 IP 192.168.0.136.optika-emedia > stager.test.lab.tftp:  42 RRQ "efi.x64/syslinux.efi" octet blksize 1468
...    
09:18:57.525302 IP 192.168.0.136.altalink > stager.test.lab.tftp:  50 RRQ "efi.x64/syslinux.efi" octet tsize 0 blksize 1468
09:18:57.528201 IP 192.168.0.136.tunstall-pnc > stager.test.lab.tftp:  42 RRQ "efi.x64/syslinux.efi" octet blksize 1468

I was able to get the ESXi installer to run via UEFI as long as I directly point to the image file in "mboot.efi", which I placed in there from syslinux 6.03, but I want to use syslinux to pass in PXE configurations from a default configuration file. I am directing to there via DHCP, as seen below:

default-lease-time 600;
max-lease-time 7200;
ddns-update-style none;
authoritative;
log-facility local7;
allow booting;
allow bootp;

option client-system-arch code 93 = unsigned integer 16;

class "pxeclients" {
    match if substring(option vendor-class-identifier, 0, 9) = "PXEClient";
    #TFTP Server
    option tftp-server-name "192.168.0.250";
    next-server 192.168.0.250;
    if option client-system-arch = 00:00 {
        filename = "bios/pxelinux.0";
    } elsif option client-system-arch = 00:07 {
        filename = "efi.x64/syslinux.efi";
    }
}

subnet 192.168.0.0 netmask 255.255.255.0 {
    option domain-name-servers 192.168.0.250;
    range 192.168.0.100 192.168.0.145;
}

My tftpboot/pxelinux.cfg/default file:

UI vesamenu.c32
PROMPT 0

menu title UEFI Deployment
MENU INCLUDE graphics.conf

LABEL -
   MENU label Standard Builds
   MENU DISABLE

LABEL ESXi 6.7
   MENU LABEL ^esxi 6.7
   MENU INDENT 3
   MENU DEFAULT
   KERNEL images/ESXiv6.7/mboot.efi
   APPEND initrd=/images/ESXiv6.7/boot.cfg ks=nfs://192.168.0.250/nfsshare/ks-prime.cfg

I can move the default file completely and have the same results. I do not believe that the boot is ever even getting pushed over to use it.

EDIT: I am adding in the TFTP logs. It does not look like it ever gets past loading syslinux.efi. It is worth noting that my BIOS implementation correctly is pulling the boot.cfg file from the image after loading its respective pxelinux.0 file. I'm assuming the default file is actually working in this instance and not the EFI default file.

TFTP UEFI Logs:

Jul 24 08:28:49 stager in.tftpd[49849]: Client ::ffff:192.168.0.136 finished efi.x64/syslinux.efi
Jul 24 08:35:58 stager in.tftpd[50227]: connect: Invalid argument
Jul 24 08:36:05 stager in.tftpd[50233]: connect: Invalid argument
Improve this question

2 Answers 2

Reset to default
2

Apparently (at least some version of) UEFI PXE standard calls for specifying the size of the boot file, using DHCP option option boot-size <value>. With traditional-BIOS-based PXE booting, this was not required.

You can get the correct size value by doing a du -B 512 syslinux.efi.

So, if the du command reports the size of your syslinux.efi as 400 blocks, you'd want your DHCP configuration to say something like this:

...
    } elsif option client-system-arch = 00:07 {
        filename = "efi.x64/syslinux.efi";
        option boot-size 400;
    }
...

Without this option, some systems I tested failed to boot with UEFI PXE.

The vesamenu.c32 module might also be problematic with UEFI, as the UEFI firmware will provide its own type of display API that has nothing to do with VESA VBIOS extensions. I've had some success with menu.c32 instead.

I've tested both syslinux.efi and ipxe.efi of ipxe.org. I could make both of them work in my environment, but iPXE seemed somewhat more robust to me.

Improve this answer
4
  • Thanks for the quick response, no joy on the boot option size. I also changed it over to use menu.c32 with the same results as well.
    – notsodev
    Commented Jul 23, 2018 at 16:54
  • Actually, your packet capture looks like the TFTP server might not be responding to the firmware. I'd crank its logging to the maximum possible, and see what happens at the TFTP server side when attempting a UEFI PXE boot.
    – telcoM
    Commented Jul 23, 2018 at 20:31
  • Good point, I should have thought to check the TFTP logs themselves. I can see that the server is presenting the syslinux.efi file to the PXE booting box, but then nothing. I tried replacing the syslinux.efi with a mboot.efi file that I had from another syslinux.efi I was working with earlier and it looks for its the boot.cfg in the image, as it should, but only in the directory that the mboot.efi is in. I can't for the life of me remember where I got that mboot.efi from, but I am beginning to think something is wrong with the syslinux.efi file. I'm editing my question to add the TFTP logs.
    – notsodev
    Commented Jul 24, 2018 at 12:41
  • I wound up just having DHCP pass the PXE boot along to the mboot.efi file in the actual image and adding in a line for my kickstart file to the boot.cfg in ESXi. It skips syslinux and the menu system, but does the job for me right now. Thanks so much for your help! @telcoM
    – notsodev
    Commented Jul 24, 2018 at 15:04
1

To anyone else who landed here looking for a solution. This setup is currently not possible due to this bug in the Syslinux/GRUB EFI bootloader. You need to pass mboot.efi directly from DHCP. Sadly this means a menu based selection is not possible in UEFI mode.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .