@Tom-Elliott

Thanks for your quick response. We’ll be using Fog heavily over the next few days, so we won’t be able to update the version right away.
We’ve found a workaround while we wait for the update by setting the setgid bit on the directory:

chown fog:fog /images/dev
chmod 2775 /images/dev

Best.

Jérôme

@Tom-Elliott said in Wiping Drive via PXE menu:

@vanfifty1 Sweet so it is functional and seems to be much more verbose about the actions it’s performing, thank you!

Thank you!

With the experimental init.xz when it said the following in my case: “Erasing /dev/nvme0n1 with an NVMe sanitize block erase (sanact 2)” does this mean the following command was run?: nvme sanitize /dev/nvme0n1 -a 2

Does this mean the bug is patched? Should I use the experimental init.xz file on the production FOG server? What ramifications will this have? Is it better to wait until this is released in an official version down the road?

unnamed (1).jpg

@88fingerslukee

Well mate, you did a wonderfull job 🙂 The only thing that afraid me is maintenance. By not using the fog install script, you have to write your own installer, which could be hard to maintain in the future, i think.

But to be clear, this is by far the best/cleanest work i’ve seen since a while (and i’ve seen a lot of them) :). I guess you did spent a lot of time on this. If i had found your work earlier, i would have, for sure, worked on it !

@jmeyer Good work. So far looks very similar to what I was doing above but with grub instead. I’m guessing you’re aiming for something along the lines of the archived project you mentioned earlier that did this. Make sure you modify your ipxe scripts to load the shim with the shim command, and then sign whatever you’re booting from ipxe and you should be more or less there.

It’s worth noting if you want you should be able to skip the grub stage entirely, if you load the shim directly and name your ipxe binary what you’re grub binary currently is you should be able to net boot any shim pretty easily, from there the shim can automatically call mok manager as long as it’s in the same directory as your shim.

Sorry for responding so late. I’m out on training this week.

@Tom-Elliott
Hi Tom,
We’re on school holidays in Austria at the moment – I’m not at school right now. At the end of August, I’ll have to install the new image on all the pupils’ PCs. Once that’s done, I’ll be able to start trying things out again. Have a lovely summer, Alexander

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

@Tom-Elliott no, i have bypass dhcp configuration during install.

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

Hello everyone,

I am facing an issue with image capturing after performing an upgrade on my FOG server from 1.5.10 to 1.5.10.1886. Before the update, everything worked fine for me. The images were stored directly on the Synology NAS.

My Setup:

FOG Server: IP 192.168.10.220 (Debian 13) Storage: External Synology NAS with multiple virtual IPs (192.168.109.220 and 192.168.110.220). Storage Configuration: The Synology NAS is configured in FOG web UI as the Master Node for its storage group. The local Default storage node is NOT the master. Clients: Multiple clients on different subnets (e.g., 192.168.109.23 and 192.168.110.23).

The Problem:
The Partclone phase finishes successfully on the client machine. The image files are correctly uploaded via NFS directly to the Synology NAS into the /images/dev/[MAC_ADDRESS] folder.

However, right after Partclone reaches 100%, the task gets stuck in the FOG Web UI (at around 70%), and the client screen shows the following PHP FTP error:

Error returned: Type: 2, File: /var/www/html/fog/lib/fog/fogftp.class.php, Line: 709, Message: ftp_put(/images/dev/[MAC]): Failed to open stream: No such file or directory, Host: 192.168.110.220, Username: foguser

What I have verified:

I tested the FTP connection manually via CMD/PowerShell from a PC using the same foguser credentials. I am able to log in, mkdir, rename, and rmdir inside the /images and /images/dev directories on the NAS without any permission errors. If I move and rename the MAC folder manually inside Synology File Station from /images/dev/[MAC] to /images/[Image_Name], the image works fine. This setup worked flawlessly before the FOG server upgrade. The /images directory is NOT mounted locally on the FOG server itself (and never had to be). Verified FTP username and password on NAS and FOG. It's same.

It seems that fogftp.class.php is incorrectly triggering ftp_put (trying to read a local file from the FOG server) instead of doing a remote ftp_rename directly on the NAS storage node.

Has anyone encountered this bug after a recent upgrade, or is there a specific setting in the new version that I missed?

Thank you for any help.

Storage Node for NAS
Storage Node for NAS.png

Error on PC
U10-PC13.jpg