PXE does not load in EFI mode.

azm9s

Good time.

I have motherboards of the A520M PRO model (MS -7C96)
on the network, a configured Windows dhcp and boottp server.
there is also a customized fogproject.

when you turn on the computer, only this happens:

checking media presence…
Media presence…
start pxe over ipv4 on MAC address: 00-00-00-00-00-00

In the server logs (command: tcpdump -i eth0 port 67 or port 68 -e -n -vv), in the 66–67 DHCP section, I get this:

14:01:45.514792 fc:9d:05:76:7c:00 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 389: (tos 0x0, ttl 64, id 25502, offset 0, flags [none], proto UDP (17), length 375)
    0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from fc:9d:05:76:7c:00, length 347, xid 0x7f6882d1, Flags [Broadcast] (0x8000)
          Client-Ethernet-Address fc:9d:05:76:7c:00
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message (53), length 1: Discover
            MSZ (57), length 2: 1472
            Parameter-Request (55), length 35:
              Subnet-Mask (1), Time-Zone (2), Default-Gateway (3), Time-Server (4)
              IEN-Name-Server (5), Domain-Name-Server (6), Hostname (12), BS (13)
              Domain-Name (15), RP (17), EP (18), RSZ (22)
              TTL (23), BR (28), YD (40), YS (41)
              NTP (42), Vendor-Option (43), Requested-IP (50), Lease-Time (51)
              Server-ID (54), RN (58), RB (59), Vendor-Class (60)
              TFTP (66), BF (67), GUID (97), Unknown (128)
              Unknown (129), Unknown (130), Unknown (131), Unknown (132)
              Unknown (133), Unknown (134), Unknown (135)
            GUID (97), length 17: 0.88.120.96.42.8.128.29.120.172.208.252.157.5.118.124.0
            NDI (94), length 3: 1.3.16
            ARCH (93), length 2: 7
            Vendor-Class (60), length 32: "PXEClient:Arch:00007:UNDI:003016"
14:01:45.515588 00:15:5d:41:09:00 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 419: (tos 0x0, ttl 128, id 55536, offset 0, flags [none], proto UDP (17), length 405)
    192.168.65.11.67 > 255.255.255.255.68: [udp sum ok] BOOTP/DHCP, Reply, length 377, xid 0x7f6882d1, Flags [none] (0x0000)
          Your-IP 192.168.65.243
          Server-IP 192.168.65.35
          Client-Ethernet-Address fc:9d:05:76:7c:00
          file "secureboot/ipxe.efi"
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message (53), length 1: Offer
            Subnet-Mask (1), length 4: 255.255.255.0
            RN (58), length 4: 300
            RB (59), length 4: 525
            Lease-Time (51), length 4: 600
            Server-ID (54), length 4: 192.168.65.11
            Default-Gateway (3), length 4: 192.168.65.1
            IEN-Name-Server (5), length 8: 192.168.65.10,192.168.65.11
            Domain-Name-Server (6), length 8: 192.168.65.10,192.168.65.11
            Domain-Name (15), length 25: "klg.localdomain^@"
            Vendor-Class (60), length 10: "PXEClient^@"
            TFTP (66), length 14: "192.168.65.35^@"
            BF (67), length 20: "secureboot/ipxe.efi^@"
14:01:45.515617 00:15:5d:41:09:00 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 419: (tos 0x0, ttl 128, id 55536, offset 0, flags [none], proto UDP (17), length 405)
    192.168.65.11.67 > 255.255.255.255.68: [udp sum ok] BOOTP/DHCP, Reply, length 377, xid 0x7f6882d1, Flags [none] (0x0000)
          Your-IP 192.168.65.243
          Server-IP 192.168.65.35
          Client-Ethernet-Address fc:9d:05:76:7c:00
          file "secureboot/ipxe.efi"
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message (53), length 1: Offer
            Subnet-Mask (1), length 4: 255.255.255.0
            RN (58), length 4: 300
            RB (59), length 4: 525
            Lease-Time (51), length 4: 600
            Server-ID (54), length 4: 192.168.65.11
            Default-Gateway (3), length 4: 192.168.65.1
            IEN-Name-Server (5), length 8: 192.168.65.10,192.168.65.11
            Domain-Name-Server (6), length 8: 192.168.65.10,192.168.65.11
            Domain-Name (15), length 25: "klg.localdomain^@"
            Vendor-Class (60), length 10: "PXEClient^@"
            TFTP (66), length 14: "192.168.65.35^@"
            BF (67), length 20: "secureboot/ipxe.efi^@"
14:01:48.886162 fc:9d:05:76:7c:00 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 401: (tos 0x0, ttl 64, id 25503, offset 0, flags [none], proto UDP (17), length 387)
    0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from fc:9d:05:76:7c:00, length 359, xid 0x7f6882d1, Flags [Broadcast] (0x8000)
          Client-Ethernet-Address fc:9d:05:76:7c:00
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message (53), length 1: Request
            Server-ID (54), length 4: 192.168.65.11
            Requested-IP (50), length 4: 192.168.65.243
            MSZ (57), length 2: 65280
            Parameter-Request (55), length 35:
              Subnet-Mask (1), Time-Zone (2), Default-Gateway (3), Time-Server (4)
              IEN-Name-Server (5), Domain-Name-Server (6), Hostname (12), BS (13)
              Domain-Name (15), RP (17), EP (18), RSZ (22)
              TTL (23), BR (28), YD (40), YS (41)
              NTP (42), Vendor-Option (43), Requested-IP (50), Lease-Time (51)
              Server-ID (54), RN (58), RB (59), Vendor-Class (60)
              TFTP (66), BF (67), GUID (97), Unknown (128)
              Unknown (129), Unknown (130), Unknown (131), Unknown (132)
              Unknown (133), Unknown (134), Unknown (135)
            GUID (97), length 17: 0.88.120.96.42.8.128.29.120.172.208.252.157.5.118.124.0
            NDI (94), length 3: 1.3.16
            ARCH (93), length 2: 7
            Vendor-Class (60), length 32: "PXEClient:Arch:00007:UNDI:003016"
14:01:48.886960 00:15:5d:41:09:00 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 419: (tos 0x0, ttl 128, id 55537, offset 0, flags [none], proto UDP (17), length 405)
    192.168.65.11.67 > 255.255.255.255.68: [udp sum ok] BOOTP/DHCP, Reply, length 377, xid 0x7f6882d1, Flags [none] (0x0000)
          Your-IP 192.168.65.243
          Server-IP 192.168.65.35
          Client-Ethernet-Address fc:9d:05:76:7c:00
          file "secureboot/ipxe.efi"
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message (53), length 1: ACK
            RN (58), length 4: 300
            RB (59), length 4: 525
            Lease-Time (51), length 4: 600
            Server-ID (54), length 4: 192.168.65.11
            Subnet-Mask (1), length 4: 255.255.255.0
            Default-Gateway (3), length 4: 192.168.65.1
            IEN-Name-Server (5), length 8: 192.168.65.10,192.168.65.11
            Domain-Name-Server (6), length 8: 192.168.65.10,192.168.65.11
            Domain-Name (15), length 25: "klg.localdomain^@"
            Vendor-Class (60), length 10: "PXEClient^@"
            TFTP (66), length 14: "192.168.65.35^@"
            BF (67), length 20: "secureboot/ipxe.efi^@"
14:01:48.887048 00:15:5d:41:09:00 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 419: (tos 0x0, ttl 128, id 55537, offset 0, flags [none], proto UDP (17), length 405)
    192.168.65.11.67 > 255.255.255.255.68: [udp sum ok] BOOTP/DHCP, Reply, length 377, xid 0x7f6882d1, Flags [none] (0x0000)
          Your-IP 192.168.65.243
          Server-IP 192.168.65.35
          Client-Ethernet-Address fc:9d:05:76:7c:00
          file "secureboot/ipxe.efi"
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message (53), length 1: ACK
            RN (58), length 4: 300
            RB (59), length 4: 525
            Lease-Time (51), length 4: 600
            Server-ID (54), length 4: 192.168.65.11
            Subnet-Mask (1), length 4: 255.255.255.0
            Default-Gateway (3), length 4: 192.168.65.1
            IEN-Name-Server (5), length 8: 192.168.65.10,192.168.65.11
            Domain-Name-Server (6), length 8: 192.168.65.10,192.168.65.11
            Domain-Name (15), length 25: "klg.localdomain^@"
            Vendor-Class (60), length 10: "PXEClient^@"
            TFTP (66), length 14: "192.168.65.35^@"
            BF (67), length 20: "secureboot/ipxe.efi^@"

I’ve changed section 66 for just about everything…
Here’s the list of what’s in the tftboot directory.

intel.efi 
intel.kkpxe
intel.kpxe
intel.pxe
intel.ipxe
ipxe.efi
ipxe.iso
ipxe.kkpxe
ipxe.kpxe
ipxe.pxe
realtek.efi
realtek.kkpxe
realtek.kpxe
realtek.efi
snp.efi
snponly.efi
undionly.kkpxe
undionly.kpxe
undionly.pxe

Nothing works.
Network stack — enabled.
UEFI — cannot be disabled in BIOS.
Legacy — enabled only for video and disk; it cannot be switched to network boot.

Where to look to get this motherboard to boot over the network…

Tom Elliott

@azm9s UEFI cannot be disabled or do you mean “Secure Boot” cannot be disabled? UEFI disabled might make sense, Secure Boot not being able to be disabled, does not. Otherwise vendors would not be able to load custom Firmware or fix software.

Please review your MB for secure boot and disable it. I suspect that’s the issue you’re running into.

That said, what version of FOG are you running? You said a customized FOGProject, what exactly do you mean?

If you mean:

We used FOGProject as the baseline at some snapshot in time to do our own thing with it and we have it how we like it.

Then I don’t know what you want us to do. What you have is up to you to figure out how to get working because the developers would have no idea of what your layout looks like.

JJ Fullmer

@azm9s echoing the question if what version you’re on?
Also the pxe saying 0s for the mac points to a mobo option, maybe dhcp has to be turned on in the mobo under pxe or network devices? Maybe it isn’t saving that setting? I’m guessing with no uefi disable you mean there’s no bios/legacy/csm option to use the legacy boot files?
I would suggest trying out working-1.6. There’s a lot of new options for pxe including secure boot support and local pxe boot environment zip downloads for testing trouble hardware like this
https://docs.fogproject.org/install-fog-server
https://docs.fogproject.org/local-esp-boot

Also as far as customized goes, there are lots of supported customizations that don’t get overwritten on updates https://docs.fogproject.org/supported-customizations

JJ Fullmer

@azm9s also, silly question, but is this a problem just with this motherboard? Other devices pxe boot fine?

JJ Fullmer

@azm9s I asked Claude for help, it found some stuff

@azm9s Good news buried in your tcpdump: DHCP is working perfectly. Discover → Offer → Request → ACK, the client takes 192.168.65.243, and ARCH (93) = 7 means the firmware is correctly identifying itself as x64 UEFI. Your Realtek 8111H, the board’s UEFI network stack, and IPv4 PXE are all fine. Whatever is broken happens after DHCP.

That reframes the problem — you’re not stuck at “PXE won’t start,” you’re stuck at “NBP won’t load or won’t run.”

First: we’re blind to the actual failure

Your filter is port 67 or port 68, so the capture cannot show TFTP. Please re-run on the FOG server (192.168.65.35) with:

tcpdump -i eth0 -e -n -vv ether host fc:9d:05:76:7c:00

That one change decides everything:

No TFTP RRQ at all → the firmware never got past DHCP (see option 60 below)
RRQ answered with error code 1, File not found → wrong path
RRQ, full successful transfer, then a blank screen → Secure Boot is rejecting the binary

Also confirm where you ran the original capture — if it wasn’t on .35, you’d never see the unicast TFTP anyway.

The boot file almost certainly doesn’t exist

DHCP is handing out secureboot/ipxe.efi, but your /tftpboot listing has no secureboot/ directory in it, and no such file. FOG doesn’t ship a secureboot/ipxe.efi under any version — on 1.6 the signed binaries are secureboot/snponly-shimx64.efi and secureboot/ipxe-shimx64.efi.

Check both of these on the server:

ls -la /tftpboot/secureboot/
tftp 192.168.65.35 -c get secureboot/ipxe.efi

If that tftp get fails, there’s your answer. Point option 67 at snponly.efi (a file you’ve confirmed exists) purely as a test.

Your DHCP server is sending option 60 = PXEClient

Vendor-Class (60), length 10: "PXEClient"

This is the old WDS-on-the-same-box workaround, and it can actively break plain TFTP boot. Per the PXE spec, option 60 in the offer tells the client “I am a PXE boot service” — so instead of just using siaddr + boot filename, the client starts looking for option 43 boot-server sub-options and may try ProxyDHCP on port 4011. There’s no option 43 in your offer, so some UEFI implementations simply stall right here, which is exactly what you’re seeing.

Unless WDS is genuinely running on 192.168.65.11, delete option 60 from your scope/server options and retest.

Minor related note: Windows DHCP null-terminates its string options, which is why tcpdump shows "secureboot/ipxe.efi^@". Usually harmless, but if you get the TFTP capture, glance at the RRQ filename for a stray byte.

(The doubled Offer and ACK in your capture are the same packet seen twice — identical IP IDs. Not a second DHCP server, ignore it.)

Motherboard: MS-7C96, MSI Click BIOS 5

First, your “UEFI cannot be disabled” is expected behavior, not a fault. MSI greys out / force-locks CSM when Secure Boot is enabled, and also when the installed GPU (including a Ryzen APU’s iGPU) has no legacy VBIOS. Since your client is correctly requesting arch 7, UEFI is what we want — don’t chase legacy mode.

Press Del, then F7 to get into Advanced mode — EZ mode hides all of the following, and it’s the usual reason people report options as missing.

Settings → Advanced → Windows OS Configuration

Secure Boot → Secure Boot Support: Disabled
If that’s greyed out: Secure Boot → Key Management → set Factory Default Key Provisioning: Disabled, or delete/clear all keys to put the board in Setup Mode. Secure Boot is always disableable on this board — Tom is right that it would be a firmware bug otherwise.
BIOS UEFI/CSM Mode lives here too, which is where you saw UEFI locked.

Settings → Boot

MSI Fast Boot: Disabled
Fast Boot: Disabled

MSI Fast Boot skips USB and network initialization outright. It’s a common cause of erratic PXE on these boards and is worth turning off regardless.

Settings → Advanced → Integrated Peripherals

LAN Option ROM: Enabled
Network Stack (may be its own menu entry depending on BIOS revision): Ipv4 PXE Support: Enabled, Ipv6 PXE Support: Disabled

Flash the latest BIOS via M-FLASH (FAT32 USB stick). MS-7C96 has been through a lot of AGESA revisions and several MSI 500-series releases shipped with a broken Realtek UEFI PXE driver. This is a genuinely common fix for “DHCP completes, NBP never downloads.”

About that MAC address on screen

Start PXE over IPv4 on MAC address: 00-00-00-00-00-00 — did you redact that, or is it literally printing zeros? The wire shows a real MAC (fc:9d:05:76:7c:00) doing valid DHCP, so the two don’t agree. If the screen genuinely shows all zeros, that points at the Realtek LAN EEPROM not being read at ROM init time — CMOS clear plus a BIOS reflash. A photo of the screen would settle it.

Realtek 8111H, snponly vs ipxe

When you get to the point of testing binaries, try snponly.efi and ipxe.efi and note which behaves differently. snponly.efi uses the firmware’s own SNP/UNDI driver; ipxe.efi uses iPXE’s native driver. FOG 1.6 standardized on the snponly builds specifically because they’re more reliable on modern UEFI firmware. If snponly fails but ipxe works, the board’s SNP implementation is the culprit and that’s useful information.

Version, and the “customized” question

Still need to know what version you’re on — your /tftpboot listing looks like 1.5.x. And when you say customized: if you mean you’ve used FOG’s supported customization points (https://docs.fogproject.org/supported-customizations), we can help fine. If you mean you forked it at some snapshot and changed internals, we can still help with the DHCP/BIOS side above, but anything server-side is going to be guesswork on our end.

Either way, working-1.6 is worth a look here — it has proper Secure Boot support with Microsoft-signed shim chains and a local ESP boot option that’s built for testing exactly this kind of stubborn hardware:

Start with the TFTP capture though. That’ll tell us which of the three branches above we’re actually in, and we’ll stop guessing.

JJ Fullmer

@azm9s actually reading the claude output looks like you’re actually pointing to secureboot/ipxe.efi for option 67. Switch that to either secureboot/snponly-shimx64.efi or secureboot/ipxe-shimx64.efi and that may do the trick