@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?

@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

@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:

• https://docs.fogproject.org/install-fog-server
• https://docs.fogproject.org/local-esp-boot

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.

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

@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

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

@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.

@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.

@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.

@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.

@csurepair Is this surface laptop an intel cpu, or is it a qualcomm cpu?

@Strahd I would try updating PHP to 8.3, @Tom-Elliott managed to test it and it worked with 7.4 but I’d still suggest updating your PHP for best results and best security practice. I found (though didn’t test) a guide online right quick https://php.watch/articles/php-8.3-install-upgrade-on-debian-ubuntu#php83-ubuntu-quick there are many others out there.

I would also go in the database and see what your schema version is

mysql -u root fog
select * from schemaVersion;

318 is the latest I believe, if yours says 318 and is stuck in a loop, maybe you can try forcing it down and then trying the schema update again. i.e.

mysql u root fog
update schemaVersion set vValue=317 where vID=1;

Then open your fog server, it will redirect you to update the schema, and see if it takes then.

Also any time you’re attempting an install and it fails, if you could grab and share the error log it mentions i.e. /root/fogproject/bin/error_logs/fog_error_1.6.0-beta. 3064. log that would be very helpful.

There’s something specific to your instance that we need to find and fix. Maybe you have a firewall running sudo ufw status ?

@CanadienITGuy Just for your and anyone’s fyi the autoexec.ipxe... Not Found is not an error. It’s more of an info message than a warning or error.
I actually have tested adding an autoexec.ipxe, even just an empty file to remove that message but even an empty file or a file that is even just a symlink or copy/paste of our normal ipxe/boot menu files causes things to break in the process.
The autoexec.ipxe is meant for adding customization to the ipxe process without needing to re-build the ipxe binary. But my testing with it within the fog workflow was that it’s best to just let that message exist and to see it as it being not found means the process will not be altered from your expected Fog ipxe workflow

@siarkowski I believe I have found the cause of this.
A while back, right after the version you reverted too, we added an improved queueing system which is working perfectly in 1.6. However when we ported it backwards into 1.5.10.x I made a simple syntax error (the wrong $task->id vs $task->get('id') ). I have fixed this in the latest dev-branch.

This should also greatly improve the experience of the imaging task queue (see also https://github.com/FOGProject/fogproject/issues/736 and https://github.com/FOGProject/fogproject/issues/691) I thought I also wrote a post somewhere in the forum walking through the updated process that fixed some longstanding date math issues, but I can’t find that now.

Point being, if you would be so kind as to update to the latest dev-branch version and see if it fixes the issue, that would be very helpful.

@eliaspereira This should be fully fixed in the stable release of 1.5.10.x coming on the 15th of this month and in the dev-branch as of now.
I thought it was already fixed back in September, and it has been working in 1.6 since then but we just got a report of a related issue here https://forums.fogproject.org/topic/18081 which I believe I just fixed.

@tian @DBailey635 @eliaspereira Apologies for missing this post. This was fixed in August-ish of last year, see also:
https://github.com/FOGProject/fogproject/issues/736

I found this searching for a post I wrote about it, as I’m pushing another fix for this for a bug just found in 1.5.10.x

If you update to the latest dev-branch (or what will be stable on the 15th of this month) or give the working-1.6 branch aka 1.6-beta a try, you’ll find the queuing problems fixed.

@bond007fink @jayrehme
By “Latest Update” do you mean the December updates for Win 11 or do you mean the latest release version of 25H2 ? I haven’t tested 25H2 yet.

@pbriec Sorry that your post got lost in the shuffle, I saw it pop up with @raul’s response.
I imagine/hope you got past this in the last year but just in case, the fix would most likely be resetting the host encryption from the web ui (removes some token related database entries on the host record) then restarting the fog service on the client.

If that didn’t do the trick, then restarting the fog service along with resetting the hots encryption should fix it.

@CoNickt @avh2025
Not all usb ethernet adapters are created equal. I would usually say to just bite the bullet and get the vendor specific adapter but it looks like you already did that. I have usb and usb-c adapters that work fine but different uefi firmwares behave differently. i.e. Microsoft surface just has to have its surface branded adapter for native boot to work. HP will work sometimes with the dell or lenovo pxe capable usb-c adapters. We also recently got 2 different hp laptop models where one had to use snponly.efi and the other was fine with ipxe.efi. I maintain a table of models and which adapters work with what we have. Lots of things do just work once you have a collection of usb adapters. Unfortunately, it’s an issue of hardware vendors adding proprietary limitations, but luckily between fog and ipxe you can typically get it working pretty smooth.

Generally if you’re able to pxe boot though, it should find the adapter within pxe. It could be a case of it being too “new” an adapter that requires a different driver not in ipxe. In that case though, I would try using snponly.efi as it may have different behavior with less things loaded in the pxe side. It may also be a driver or setting needed in ipxe that could be handled in a custom compile of ipxe, there’s some info on that here https://docs.fogproject.org/en/latest/compile_ipxe_binaries

It’s also possible to use a tool such as rEFInd to get to a uefi cli console. If you load the ipxe.efi and or snponly.efi and then if you can obtain them the efi driver for the adapter you can do a fs0: to enter the usb disk (it may be fs1: or fs2: you gotta ls on each disk to find the right one) then load usb-network-driver.efi then ipxe.efi to ensure the usb network driver is loaded in the efi for that session and then boot direct to the pxe file which will start the fog network boot. It’s a bit of a hassle but it usually works for me when all else fails. I have an old startech usb 2 ethernet adapter I do this with. This has worked universally but it’s not an ideal solution, but can be poc that it can be done on any device.

I hope my rant was helpful.