FOG Hangouts 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.

edvandro

Hello everyone,

I am currently testing the dev-branch of FOG and have run into an issue when trying to create a new Multicast deployment task for a group of hosts.

Whenever I attempt to start the task, it fails immediately. The web UI shows a generic “Failed to create tasking” error, and the debug log reveals the following SQL integrity constraint violation:

The full query and parameters from the log show that the INSERT into the tasks table is trying to set taskPassreset to NULL, but the column definition in the database does not allow null values.

Additional context:

This issue occurs only on the dev-branch.
I have tested the exact same configuration (same server, same image, same host group) on the stable branch, and Multicast group tasks work perfectly fine there.

I have attached the error screenshot/print for reference.

Has anyone else encountered this specific issue on the dev-branch? Could it be a schema mismatch (e.g., missing default value for taskPassreset), or is this a known regression in the development code? Any pointers on how to fix or patch this temporarily would be greatly appreciated.

Thank you in advance for your help!

FOG Version: Dev-Branch (latest pull)
Init/Kernel: (Not relevant, happens in web UI before PXE boot)
Storage: NFS (working fine on stable)

####################

Tasking Failed
Failed to create tasking

```

teste Failed to start tasking type Multi-Cast
Failed to query: Error: SQLSTATE[23000]: Integrity constraint violation: 1048 Column ‘taskPassreset’ cannot be null Error Message: Error Code: “23000”, Error Message: [“23000”,1048,“Column ‘taskPassreset’ cannot be null”], Debug: SQL: [1115] INSERT INTO tasks (taskName,taskCreateBy,taskHostID,taskForce,taskStateID,taskTypeID,taskNFSGroupID,taskNFSMemberID,taskWOL,taskImageID,taskShutdown,taskIsDebug,taskPassreset,taskLastMemberID) VALUES (:name_0,:createdBy_0,:hostID_0,:isForced_0,:stateID_0,:typeID_0,:storagegroupID_0,:storagenodeID_0,:wol_0,:imageID_0,:shutdown_0,:isDebug_0,:passreset_0,:NFSLastMemberID_0),(:name_1,:createdBy_1,:hostID_1,:isForced_1,:stateID_1,:typeID_1,:storagegroupID_1,:storagenodeID_1,:wol_1,:imageID_1,:shutdown_1,:isDebug_1,:passreset_1,:NFSLastMemberID_1) ON DUPLICATE KEY UPDATE taskName=VALUES(taskName),taskCreateBy=VALUES(taskCreateBy),taskHostID=VALUES(taskHostID),taskForce=VALUES(taskForce),taskStateID=VALUES(taskStateID),taskTypeID=VALUES(taskTypeID),taskNFSGroupID=VALUES(taskNFSGroupID),taskNFSMemberID=VALUES(taskNFSMemberID),taskWOL=VALUES(taskWOL),taskImageID=VALUES(taskImageID),taskShutdown=VALUES(taskShutdown),taskIsDebug=VALUES(taskIsDebug),taskPassreset=VALUES(taskPassreset),taskLastMemberID=VALUES(taskLastMemberID) Params: 28 Key: Name: [7] :name_0 paramno=0 name=[7] “:name_0” is_param=1 param_type=2 Key: Name: [12] :createdBy_0 paramno=1 name=[12] “:createdBy_0” is_param=1 param_type=2 Key: Name: [9] :hostID_0 paramno=2 name=[9] “:hostID_0” is_param=1 param_type=2 Key: Name: [11] :isForced_0 paramno=3 name=[11] “:isForced_0” is_param=1 param_type=2 Key: Name: [10] :stateID_0 paramno=4 name=[10] “:stateID_0” is_param=1 param_type=2 Key: Name: [9] :typeID_0 paramno=5 name=[9] “:typeID_0” is_param=1 param_type=2 Key: Name: [17] :storagegroupID_0 paramno=6 name=[17] “:storagegroupID_0” is_param=1 param_type=2 Key: Name: [16] :storagenodeID_0 paramno=7 name=[16] “:storagenodeID_0” is_param=1 param_type=2 Key: Name: [6] :wol_0 paramno=8 name=[6] “:wol_0” is_param=1 param_type=2 Key: Name: [10] :imageID_0 paramno=9 name=[10] “:imageID_0” is_param=1 param_type=2 Key: Name: [11] :shutdown_0 paramno=10 name=[11] “:shutdown_0” is_param=1 param_type=2 Key: Name: [10] :isDebug_0 paramno=11 name=[10] “:isDebug_0” is_param=1 param_type=2 Key: Name: [12] :passreset_0 paramno=12 name=[12] “:passreset_0” is_param=1 param_type=2 Key: Name: [18] :NFSLastMemberID_0 paramno=13 name=[18] “:NFSLastMemberID_0” is_param=1 param_type=2 Key: Name: [7] :name_1 paramno=14 name=[7] “:name_1” is_param=1 param_type=2 Key: Name: [12] :createdBy_1 paramno=15 name=[12] “:createdBy_1” is_param=1 param_type=2 Key: Name: [9] :hostID_1 paramno=16 name=[9] “:hostID_1” is_param=1 param_type=2 Key: Name: [11] :isForced_1 paramno=17 name=[11] “:isForced_1” is_param=1 param_type=2 Key: Name: [10] :stateID_1 paramno=18 name=[10] “:stateID_1” is_param=1 param_type=2 Key: Name: [9] :typeID_1 paramno=19 name=[9] “:typeID_1” is_param=1 param_type=2 Key: Name: [17] :storagegroupID_1 paramno=20 name=[17] “:storagegroupID_1” is_param=1 param_type=2 Key: Name: [16] :storagenodeID_1 paramno=21 name=[16] “:storagenodeID_1” is_param=1 param_type=2 Key: Name: [6] :wol_1 paramno=22 name=[6] “:wol_1” is_param=1 param_type=2 Key: Name: [10] :imageID_1 paramno=23 name=[10] “:imageID_1” is_param=1 param_type=2 Key: Name: [11] :shutdown_1 paramno=24 name=[11] “:shutdown_1” is_param=1 param_type=2 Key: Name: [10] :isDebug_1 paramno=25 name=[10] “:isDebug_1” is_param=1 param_type=2 Key: Name: [12] :passreset_1 paramno=26 name=[12] “:passreset_1” is_param=1 param_type=2 Key: Name: [18] :NFSLastMemberID_1 paramno=27 name=[18] “:NFSLastMemberID_1” is_param=1 param_type=2 SQL: INSERT INTO tasks (taskName,taskCreateBy,taskHostID,taskForce,taskStateID,taskTypeID,taskNFSGroupID,taskNFSMemberID,taskWOL,taskImageID,taskShutdown,taskIsDebug,taskPassreset,taskLastMemberID) VALUES (:name_0,:createdBy_0,:hostID_0,:isForced_0,:stateID_0,:typeID_0,:storagegroupID_0,:storagenodeID_0,:wol_0,:imageID_0,:shutdown_0,:isDebug_0,:passreset_0,:NFSLastMemberID_0),(:name_1,:createdBy_1,:hostID_1,:isForced_1,:stateID_1,:typeID_1,:storagegroupID_1,:storagenodeID_1,:wol_1,:imageID_1,:shutdown_1,:isDebug_1,:passreset_1,:NFSLastMemberID_1) ON DUPLICATE KEY UPDATE taskName=VALUES(taskName),taskCreateBy=VALUES(taskCreateBy),taskHostID=VALUES(taskHostID),taskForce=VALUES(taskForce),taskStateID=VALUES(taskStateID),taskTypeID=VALUES(taskTypeID),taskNFSGroupID=VALUES(taskNFSGroupID),taskNFSMemberID=VALUES(taskNFSMemberID),taskWOL=VALUES(taskWOL),taskImageID=VALUES(taskImageID),taskShutdown=VALUES(taskShutdown),taskIsDebug=VALUES(taskIsDebug),taskPassreset=VALUES(taskPassreset),taskLastMemberID=VALUES(taskLastMemberID) Params: Array ( [name_0] => Multi-Cast Task - teste [createdBy_0] => fog [hostID_0] => 2 [isForced_0] => 0 [stateID_0] => 1 [typeID_0] => 8 [storagegroupID_0] => 1 [storagenodeID_0] => 1 [wol_0] => 1 [imageID_0] => 1 [shutdown_0] => [isDebug_0] => [passreset_0] => [NFSLastMemberID_0] => 1 [name_1] => Multi-Cast Task - teste [createdBy_1] => fog [hostID_1] => 3 [isForced_1] => 0 [stateID_1] => 1 [typeID_1] => 8 [storagegroupID_1] => 1 [storagenodeID_1] => 1 [wol_1] => 1 [imageID_1] => 1 [shutdown_1] => [isDebug_1] => [passreset_1] => [NFSLastMemberID_1] => 1 ) ErrorInfo: Array ( [0] => 23000 [1] => 1048 [2] => Column ‘taskPassreset’ cannot be null ) Debug: SQL: [1115] INSERT INTO tasks (taskName,taskCreateBy,taskHostID,taskForce,taskStateID,taskTypeID,taskNFSGroupID,taskNFSMemberID,taskWOL,taskImageID,taskShutdown,taskIsDebug,taskPassreset,taskLastMemberID) VALUES (:name_0,:createdBy_0,:hostID_0,:isForced_0,:stateID_0,:typeID_0,:storagegroupID_0,:storagenodeID_0,:wol_0,:imageID_0,:shutdown_0,:isDebug_0,:passreset_0,:NFSLastMemberID_0),(:name_1,:createdBy_1,:hostID_1,:isForced_1,:stateID_1,:typeID_1,:storagegroupID_1,:storagenodeID_1,:wol_1,:imageID_1,:shutdown_1,:isDebug_1,:passreset_1,:NFSLastMemberID_1) ON DUPLICATE KEY UPDATE taskName=VALUES(taskName),taskCreateBy=VALUES(taskCreateBy),taskHostID=VALUES(taskHostID),taskForce=VALUES(taskForce),taskStateID=VALUES(taskStateID),taskTypeID=VALUES(taskTypeID),taskNFSGroupID=VALUES(taskNFSGroupID),taskNFSMemberID=VALUES(taskNFSMemberID),taskWOL=VALUES(taskWOL),taskImageID=VALUES(taskImageID),taskShutdown=VALUES(taskShutdown),taskIsDebug=VALUES(taskIsDebug),taskPassreset=VALUES(taskPassreset),taskLastMemberID=VALUES(taskLastMemberID) Params: 28 Key: Name: [7] :name_0 paramno=0 name=[7] “:name_0” is_param=1 param_type=2 Key: Name: [12] :createdBy_0 paramno=1 name=[12] “:createdBy_0” is_param=1 param_type=2 Key: Name: [9] :hostID_0 paramno=2 name=[9] “:hostID_0” is_param=1 param_type=2 Key: Name: [11] :isForced_0 paramno=3 name=[11] “:isForced_0” is_param=1 param_type=2 Key: Name: [10] :stateID_0 paramno=4 name=[10] “:stateID_0” is_param=1 param_type=2 Key: Name: [9] :typeID_0 paramno=5 name=[9] “:typeID_0” is_param=1 param_type=2 Key: Name: [17] :storagegroupID_0 paramno=6 name=[17] “:storagegroupID_0” is_param=1 param_type=2 Key: Name: [16] :storagenodeID_0 paramno=7 name=[16] “:storagenodeID_0” is_param=1 param_type=2 Key: Name: [6] :wol_0 paramno=8 name=[6] “:wol_0” is_param=1 param_type=2 Key: Name: [10] :imageID_0 paramno=9 name=[10] “:imageID_0” is_param=1 param_type=2 Key: Name: [11] :shutdown_0 paramno=10 name=[11] “:shutdown_0” is_param=1 param_type=2 Key: Name: [10] :isDebug_0 paramno=11 name=[10] “:isDebug_0” is_param=1 param_type=2 Key: Name: [12] :passreset_0 paramno=12 name=[12] “:passreset_0” is_param=1 param_type=2 Key: Name: [18] :NFSLastMemberID_0 paramno=13 name=[18] “:NFSLastMemberID_0” is_param=1 param_type=2 Key: Name: [7] :name_1 paramno=14 name=[7] “:name_1” is_param=1 param_type=2 Key: Name: [12] :createdBy_1 paramno=15 name=[12] “:createdBy_1” is_param=1 param_type=2 Key: Name: [9] :hostID_1 paramno=16 name=[9] “:hostID_1” is_param=1 param_type=2 Key: Name: [11] :isForced_1 paramno=17 name=[11] “:isForced_1” is_param=1 param_type=2 Key: Name: [10] :stateID_1 paramno=18 name=[10] “:stateID_1” is_param=1 param_type=2 Key: Name: [9] :typeID_1 paramno=19 name=[9] “:typeID_1” is_param=1 param_type=2 Key: Name: [17] :storagegroupID_1 paramno=20 name=[17] “:storagegroupID_1” is_param=1 param_type=2 Key: Name: [16] :storagenodeID_1 paramno=21 name=[16] “:storagenodeID_1” is_param=1 param_type=2 Key: Name: [6] :wol_1 paramno=22 name=[6] “:wol_1” is_param=1 param_type=2 Key: Name: [10] :imageID_1 paramno=23 name=[10] “:imageID_1” is_param=1 param_type=2 Key: Name: [11] :shutdown_1 paramno=24 name=[11] “:shutdown_1” is_param=1 param_type=2 Key: Name: [10] :isDebug_1 paramno=25 name=[10] “:isDebug_1” is_param=1 param_type=2 Key: Name: [12] :passreset_1 paramno=26 name=[12] “:passreset_1” is_param=1 param_type=2 Key: Name: [18] :NFSLastMemberID_1 paramno=27 name=[18] “:NFSLastMemberID_1” is_param=1 param_type=2

edvandro

Resolved. I’m sharing FOG with as many people as I can. Love this project!

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.

J	Joe Schmitt
E	edvandro
G	Greg Plamondon
S	soscrafts01
O	oelked
M	Mr_____T
B	broodbaron
R	rcalayan
H	hammerc807
D	dyacishyn
L	lukebarone
M	Melisa
Y	yushin
B	brechtvervaeke
A	abasto
E	emreonder
R	rogalskij
M	mkoliva15
C	carltoncortez
A	alvin.bayani

FOG Hangouts

Posts