Hi @Tom-Elliott – thank you for your help! The client is UEFI.

I probably should have mentioned that the main symptom I’m trying to figure out is the client giving up with PXE-E16: No valid offer received after a few minutes of trying PXE boot.

Interestingly, when I tried also listening to port 4011 with my initial config file, there was no additional traffic being picked up.

When I used the version you suggested (with the server’s IP switched in of course), the tcpdump actually no longer shows any responses to the client’s requests, and the PXE boot errors out faster with PXE-E18: Server response timeout.

tcpdump: listening on eno1, link-type EN10MB (Ethernet), snapshot length 262144 bytes 16:08:07.096920 IP (tos 0x0, ttl 64, id 29391, offset 0, flags [none], proto UDP (17), length 375) 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from <client’s mac address>(oui Unknown), length 347, xid 0x92c2c13c, Flags [Broadcast] Client-Ethernet-Address <client’s mac address>(oui Unknown) 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.128.226.9.231.152.246.237.17.132.7.227.255.61.233.42.0 NDI (94), length 3: 1.3.16 ARCH (93), length 2: 7 Vendor-Class (60), length 32: "PXEClient:Arch:00007:UNDI:003016" 16:08:10.881261 IP (tos 0x0, ttl 64, id 29392, offset 0, flags [none], proto UDP (17), length 375) 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from <client’s mac address>(oui Unknown), length 347, xid 0x92c2c13c, secs 4, Flags [Broadcast] Client-Ethernet-Address <client’s mac address>(oui Unknown) 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.128.226.9.231.152.246.237.17.132.7.227.255.61.233.42.0 NDI (94), length 3: 1.3.16 ARCH (93), length 2: 7 Vendor-Class (60), length 32: "PXEClient:Arch:00007:UNDI:003016" 16:08:18.968033 IP (tos 0x0, ttl 64, id 29393, offset 0, flags [none], proto UDP (17), length 375) 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from <client’s mac address>(oui Unknown), length 347, xid 0x92c2c13c, secs 12, Flags [Broadcast] Client-Ethernet-Address <client’s mac address>(oui Unknown) 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.128.226.9.231.152.246.237.17.132.7.227.255.61.233.42.0 NDI (94), length 3: 1.3.16 ARCH (93), length 2: 7 Vendor-Class (60), length 32: "PXEClient:Arch:00007:UNDI:003016" 16:08:35.140038 IP (tos 0x0, ttl 64, id 29394, offset 0, flags [none], proto UDP (17), length 375) 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from <client’s mac address>(oui Unknown), length 347, xid 0x92c2c13c, secs 28, Flags [Broadcast] Client-Ethernet-Address <client’s mac address>(oui Unknown) 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.128.226.9.231.152.246.237.17.132.7.227.255.61.233.42.0 NDI (94), length 3: 1.3.16 ARCH (93), length 2: 7 Vendor-Class (60), length 32: "PXEClient:Arch:00007:UNDI:003016" ^C 4 packets captured 4 packets received by filter 0 packets dropped by kernel

In case it is informative, my initial config file yields a few cycles of

cpdump: listening on eno1, link-type EN10MB (Ethernet), snapshot length 262144 bytes 16:25:14.333731 IP (tos 0x0, ttl 64, id 3165, offset 0, flags [none], proto UDP (17), length 375) 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from <client’s mac address>(oui Unknown), length 347, xid 0xf2335aca, Flags [Broadcast] Client-Ethernet-Address <client’s mac address>(oui Unknown) 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.128.226.9.231.152.246.237.17.132.7.227.255.61.233.42.0 NDI (94), length 3: 1.3.16 ARCH (93), length 2: 7 Vendor-Class (60), length 32: "PXEClient:Arch:00007:UNDI:003016" 16:25:14.334222 IP (tos 0xc0, ttl 64, id 43055, offset 0, flags [none], proto UDP (17), length 328) CREEDfog.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length 300, xid 0xf2335aca, Flags [Broadcast] Server-IP CREEDfog Client-Ethernet-Address <client’s mac address>(oui Unknown) Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message (53), length 1: Offer Server-ID (54), length 4: CREEDfog Vendor-Class (60), length 9: "PXEClient" GUID (97), length 17: 0.128.226.9.231.152.246.237.17.132.7.227.255.61.233.42.0

@Alun Thank you and added to documentation and within the installer to try to more cleanly account for this.

@Valer Thanks for the report and the writeup, that’s a good catch. You’re right about the cause. Debian 13 dropped the sysv-rc-conf package since it’s fully on systemd now, so the installer chokes trying to apt-get it. We never actually use that tool on a systemd system anyway, it only ever got called on the old non-systemd paths, so it was just dead weight on Trixie.

I pushed a fix to working-1.6. It leaves the package off the list on Debian 13 and up, and it also strips it out of a cached .fogsettings so an in-place upgrade doesn’t drag it back in. Older Debian keeps installing it like before so nothing changes there.

If you want to get moving before you pull the update, you can either grab the latest working-1.6 and rerun the installer, or just open /opt/fog/.fogsettings and delete sysv-rc-conf from the packages line, then run the installer again. Either one gets you past it.

Let me know if you hit anything else on Trixie.

@Tom-Elliott When searching for a solution I recall seeing a related post on GitHub but that was not me. Today I created a new VM that was 70GB with 2GB EFI partition and after sysprep and it yielded the similar resize error during capture.

I then tried Windows 11 25H2 June 2026 Build 26200.8655 with 60GB VM and it generated the resize error. 25H2 with 60GB VM and 2GB EFI also generated the resize error after sysprep during capture.

The AI suggested defrag C : /X

I ran the defrag before sysprep and capture was succesful.

The pre optimization total fragmentation was 22% and post defragmentation it was also 22%

To my understanding the /X flag consolidates free space. How was this the solution to my issue?

Per the FOG Project wiki I found that defrag is recommended before sysprep:

"…
Before Running Sysprep
Other steps to consider are:

Run Chkdsk /f /p prior to imaging
Defrag the drive
Make sure 2gb of disk space is free or the NTFSresize will fail
Make sure the FOG service is installed and properly configured
Update your hostnamechange.dll file
…
"
https://wiki.fogproject.org/wiki/index.php/Client_Setup

@Tom-Elliott yes, I checked the services, they all running.
systemctl status nfs-server
● nfs-server.service - NFS server and services
Loaded: loaded (/usr/lib/systemd/system/nfs-server.service; enabled; preset: enabled)
Drop-In: /run/systemd/generator/nfs-server.service.d
└─order-with-mounts.conf
Active: active (exited) since Tue 2026-06-30 09:06:50 UTC; 17h ago
Process: 4995 ExecStartPre=/usr/sbin/exportfs -r (code=exited, status=0/SUCCESS)
Process: 4997 ExecStart=/usr/sbin/rpc.nfsd (code=exited, status=0/SUCCESS)
Main PID: 4997 (code=exited, status=0/SUCCESS)
CPU: 10ms

Jun 30 09:06:49 fog-svr.local systemd[1]: Starting nfs-server.service - NFS server and services…
Jun 30 09:06:50 fog-svr.local systemd[1]: Finished nfs-server.service - NFS server and services.

rpcinfo -p 192.168.13.99
192.168.13.99 mountd
rpcinfo -t 192.168.13.99 nfs
rpcin program vers proto port service
100000 4 tcp 111 portmapper
100000 3 tcp 111 portmapper
100000 2 tcp 111 portmapper
100000 4 udp 111 portmapper
100000 3 udp 111 portmapper
100000 2 udp 111 portmapper
100024 1 udp 50174 status
100024 1 tcp 34667 status
100005 1 tcp 20048 mountd
100005 2 tcp 20048 mountd
100005 3 tcp 20048 mountd
100003 3 tcp 2049 nfs
100227 3 tcp 2049 nfs_acl
100021 1 udp 38178 nlockmgr
100021 3 udp 38178 nlockmgr
100021 4 udp 38178 nlockmgr
100021 1 tcp 37227 nlockmgr
100021 3 tcp 37227 nlockmgr
100021 4 tcp 37227 nlockmgr

I deployed the image using a VM on Proxmox and it worked, but with a phisical PC it gives the error like above. All are on the same VLAN.

@Tom-Elliott awesome, thank you!

@george1421

I’m interested in creating a working WiFi or USB network solution for device registration in FOG.

I have approximately 160 laptops to add to FOG that do not have a built-in Ethernet port. I’ve already tried using USB network adapters, but this has introduced extra complexity. In addition, a second laptop I tested is not consistently able to boot from the USB NIC, even though it worked on the first device.

To clarify, I am not attempting to image over WiFi. I only need network connectivity in the FOG environment so I can register each device and capture the correct MAC address. I will then image via Clonezilla using a USB-C NVME, which takes under three minutes to image each device

If possible, I would appreciate guidance on modifying the kernel so I can include future WiFi drivers.

I’ve attached the relevant information I believe you will need.
WhatsApp Image 2026-06-26 at 12.51.26.jpeg

@Tom-Elliott

Ah man that’s exactly what I needed. Thanks so much sir!

@JCS-RVK Understood and apologies there’s not a good method around this.

Thanks for at least understanding. I wonder if some of the similar types of issues we’ve seen historically have a similar style of problem that I’m only coming to realize now-a-days.

@Tom-Elliott

Just lyk that I updated the main FOG server to Debian 13 and installed the latest stable release of FOG.

Replication working well now that the OS and FOG server versions match the Storage Node server.

Thanks again

@Valer Hi Valer,

You can see my tutorial on using Secure boot with Shim, and my thoughts on what 2.0 means for Secure Boot with FOG here: http://forums.fogproject.org/post/158170

@Tom-Elliott

I’ve updated my FOG to the stable release and also updated my script with the following three lines, and everything’s fine – the database has been backed up successfully, it’s perfect!

fogApiToken="XYZ=" fogUsrToken="ZYF" curl -ik -X GET "http://$fogServerAddress/fog/system/export" -H "fog-api-token: $fogApiToken" -H "fog-user-token: $fogUsrToken" -o $backupDir/mysql/fog.sql 2>>$backupDir/logs/error.log 1>>$backupDir/logs/progress.log 2>&1

Thanks again for all your hard work on the FOG project!

Thanks @Tom-Elliott !

Perhaps we could include a brief note stating that it is possible the database schema may not need updating.

@Tom-Elliott said in Unauthorized error:

@Jamaal I’m not sure I follow? The database isn’t insecure, it was being able to download the database, or force an upgrade without authorization that was the piece being secured, nothing about the normal day to day operation of the database changed.

Got it, ok thanks for your help today on this.