@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

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

I remplaced grubx64 by grubnetx64 (not sure if needed but was recommanded for PXE) and create a “grub” directory in tftpboot with “grub.cfg” inside.
Grub signed look for cfg file in a subdir called “grub” by default.

cp /usr/lib/grub/x86_64-efi-signed/grubnetx64.efi.signed /tftpboot/grubx64.efi mkdir /tftpboot/grub chmod -R a+rX /tftpboot/grub

I get grub menu.

update (10 am) :
I copied snponly.efi in grub directory and signed it with the FOG-MOK key I generated before.

sbsign --key /root/secureboot/FOG-MOK.key --cert /root/secureboot/FOG-MOK.crt /tftpboot/snponly.efi --output /tftpboot/grub/snponly.efi

I end with “error ; bad shim signature”.
I think I need to import the key on the computer with command “mokutil --import /chemin/vers/FOG-MOK.der”

I keep on searching…

2nd update (12:30 am):

To enroll key :

cp /usr/lib/shim/mmx64.efi.signed /tftpboot/mmx64.efi

and in tftpboot/grub/grub.cfg

menuentry 'Enroll MOK' { insmod tftp insmod chain chainloader (tftp,192.168.69.10)/mmx64.efi boot } menuentry 'Boot FOG (iPXE)' { insmod efinet insmod tftp insmod chain net_bootp chainloader (tftp,192.168.69.10)/grub/snponly.efi boot }

Copy the .der on usb key, put it on the computer, run “Enroll MOK” in pxe grub menu then “Enroll from disk”
Reboot and run “Boot FOG” in pxe menu.

And at least I have the FOG menu ! 😎
I think I’m in the right way. 😅

Let’s keep on working.

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

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

@Cpasjuste I already have one working if you just want to contribute to that. I think the difference in mine vs yours is that it has been a little bit further tested and it uses ENV variables. It also gets re-built into a working image every time upstream FOG pushes a new version.

https://github.com/88fingerslukee/fog-docker

@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

Works well ! 😊

Works well ! 😁

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

@Tom-Elliott

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

Thanks @Tom-Elliott !

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

@Nono Edit your /opt/fog/.fogsettings file and replace entries of ‘mysql-client’ with ‘mariadb-client’

I suspect they’ve updated the repo to solely exist for mariadb-client, but you had it before that package switch/change occurred so your fogsettings file is just expecting mysql-client always.

I might also recommend removing the existing mysql-client package just to ensure clean flow, though of course get a backup before any such actions.

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

@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