Moderators group

JJ Fullmer

@jmeyer I have some e16 g1s and I am not having the same issue. What version of fog are you running? Are there any other secure boot settings you have configured or maybe not configured? Can you get to the mok enroll with secure boot off? And then turn it back on?

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

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 also, silly question, but is this a problem just with this motherboard? Other devices pxe boot fine?

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

@jmeyer Would you be willing/able to try again without bypassing it to help confirm the fix?
@rogersk4132 thank you for testing and confirming!

JJ Fullmer

@edvandro Thank you for reporting. We’re working on a fix for that right now.
I would also suggest trying working-1.6 instead of dev-branch as we have a lot of new improvements and are anxious to get feedback. I’ve been running the 1.6 “beta” as my production fog server for a few years now and recently we’ve added a lot of new long-requested features.

JJ Fullmer

@Valer
@Tom-Elliott may have already fixed this, but if you’re using refined that would also need to be signed. We should be able to just have it signed by our new secure boot system and then it should be happy.
But also, the newer version of ipxe has proper support for SANBOOT in uefi mode, so you may be able to skip over refined and just use SANBOOT to boot to disk, try SANBOOT as the exit mode on a host and see if works, if it does you can change your global default and have an easier time.

JJ Fullmer

@Tom-Elliott said in How to upgrade to FOG 1.6?:

Client state What the task does
Setup Mode (platform key cleared) Enrols outright. Nothing to confirm, nobody at the keyboard.
Normal (keys present, Secure Boot off) FOS stages the MOK request itself, non-interactively. Someone answers the blue MokManager screen once on the next reboot.
Already enforcing Secure Boot Cannot run — the machine will not boot FOS in the first place. Use the live USB route for those.

One minor correction, with secure boot enabled on a new machine, if you boot to the signed shim you can use the Mok enrollment boot issue without needing to disable secure boot, but you do have to be physically at each machine to enroll.

JJ Fullmer

@csurepair I think Elite is referencing snapdragon elite? I actually don’t see any intel options for the laptop 7.
So you may need it to boot to the arm pxe file, but you’ll also need a new image for arm64 I imagine.
Microsoft also did something like this with the surface GO for business, there was a surface go 4 but all of a sudden no more surface go 4 being made and the product line was dead. They made a similarly priced (at the time, not anymore) 12" surface tablet but snapdragon based. We opted to not change our entire cpu architecture, so sadly I don’t have any experience with getting this working. I know @rodluz has done a lot with getting arm working with FOG and may be of more help if booting to arm kernel and init doesn’t work.

S	Sebastian Roth
J	JJ Fullmer
F	fry_p
X	x23piracy
Q	Quazz
F	falko
G	george1421
C	cml
C	ch3i
A	andyroo54
C	chad-bisd
V	VincentJ
N	need2

Moderators

Posts