1

I've been having a lot of issues with UEFI boots lately. I have two VMs that I've been using for testing. One is running DHCP/TFTP (CentOS 7) and the other is a client set to UEFI boot. I have tested this with a Legacy boot and it is able to boot and pull an image. But it does not look like the UEFI client ever takes its DHCP assignment. Both machines are sitting on the same virtual wire (portgroup), so there should be no network problems in the way. I have mirrored another setup that I did previously that is not having the same issue, so I am kind of at a loss. I feel like I am missing something small, so if anyone notices anything, I would appreciate any input! Thanks you!

I took a pcap of the test environment and can see the DHCP reply from my server:

# tcpdump -enli ens192 port 67
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ens192, link-type EN10MB (Ethernet), capture size 262144 bytes
12:45:51.742154 00:0c:29:ae:ff:e7 > Broadcast, ethertype IPv4 (0x0800), length 389: 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:0c:29:ae:ff:e7, length 347
12:45:51.742436 00:0c:29:7a:7c:27 > Broadcast, ethertype IPv4 (0x0800), length 342: 132.0.101.2.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length 300
12:46:07.742311 00:0c:29:ae:ff:e7 > Broadcast, ethertype IPv4 (0x0800), length 389: 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:0c:29:ae:ff:e7, length 347
12:46:07.742506 00:0c:29:7a:7c:27 > Broadcast, ethertype IPv4 (0x0800), length 342: 132.0.101.2.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length 300

I can then see in the logs that DHCP is in fact providing an address to the booting server (note this an an offline environment that does not have access to NTP):

Aug 17 12:42:23 stager named[1148]: error (network unreachable) resolving './NS/IN': 2001:500:12::d0d#53
Aug 17 12:42:23 stager named[1148]: error (network unreachable) resolving '3.centos.pool.ntp.org/AAAA/IN': 2001:500:12::d0d#53
Aug 17 12:42:23 stager named[1148]: error (network unreachable) resolving '3.centos.pool.ntp.org/A/IN': 2001:500:12::d0d#53
Aug 17 12:42:28 stager dhcpd: DHCPDISCOVER from 00:0c:29:ae:ff:e7 via ens192
Aug 17 12:42:28 stager dhcpd: DHCPOFFER on 132.0.101.11 to 00:0c:29:ae:ff:e7 via ens192

Regardless, the client never actually boots and stays at the screen below until giving up: enter image description here

My dhcpd.conf:

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 "132.0.101.2";
        next-server 132.0.101.2;
        if option client-system-arch = 00:00 {
                filename = "bios/pxelinux.0";
        } elsif option client-system-arch = 00:07 {
                filename = "images/esxi6.7/efi/boot/bootx64.efi";
                option boot-size 344;
        }
}

subnet 132.0.101.0 netmask 255.255.255.0 {
        option routers 132.0.101.1;
        option domain-name-servers 132.0.101.2;
        range 132.0.101.11 132.0.101.99;
}
2

DHCP's Client System Architecture Type Option defines several architectures for PXE EFI clients. Of those, two are of interest:

Type   Architecture Name
----   -----------------
[...]
  7    EFI BC
[...]
  9    EFI x86-64

EFI BC is an processor-independent byte code implementation for drivers and is often used by UEFI PXE boots.

Now, on any recent VMware documentation, the filter is accepting both type 00:07 or 00:09, eg this PDF document Installing ESXi Using PXE - VMware vSphere 6.0, or Sample DHCP Configurations, both include:

if option client-system-arch = 00:07or option client-system-arch = 00:09{

This expectation makes me believe VMware's emulated UEFI firmware sends 00:09 and not the more common 00:07 architecture type, so they suggest to have both on the DHCP server.
UPDATE: from OP's comment, it appears that depending on the x86-64 hardware (or virtual) vendor, EFI implementation can differ and thus send type 00:07 or type 00:09.

You should add type 00:09 and see if now TFTP is offered to the ESXi client.

I don't have the means to verify this theory.

1
  • Thank you so much. This was exactly what it was. What is weird is that i have another identical setup on a different ESXi host in another location that is working with just the 00:07. I wonder if it depends on the hardware that VMware is running on at that point. – Bryan A Aug 17 '18 at 18:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.