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.

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

Installing package: sysv-rc-conf............................Failed! (Will try later)

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!! The installer was not able to run all the way to the end as   !!
!! something has caused it to fail. The following few lines are  !!
!! from the error log file which might help us figure out what's !!
!! wrong. Please add this information when reporting an error.   !!
!! As well you might want to take a look at the full error log   !!
!! in /root/fogproject/bin/error_logs/fog_error_1.6.0-beta.2644.log !!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

      * In systemd-sysv:amd64 is available in versions 257.13-1~deb13u1, 257.8-1~deb13u2:
        - systemd-sysv:amd64=257.8-1~deb13u2 is not selected for install
   2. sysvinit-core:amd64 is selected for install because:
      1. sysv-rc-conf:amd64=0.99-10 is selected for install
      2. sysv-rc-conf:amd64 Dépend sysvinit-core

Error logs are :

Les paquets suivants contiennent des dépendances non satisfaites :
 systemd-sysv : Est en conflit avec: initscripts mais 3.14-4 devra être installé
                Est en conflit avec: insserv mais 1.26.0-1 devra être installé
                Est en conflit avec: startpar mais 0.66-1 devra être installé
                Est en conflit avec: sysv-rc mais 3.14-4 devra être installé
                Est en conflit avec: sysvinit-core mais 3.14-4 devra être installé
 sysvinit-core : Est en conflit avec: systemd-sysv mais 257.13-1~deb13u1 devra être installé
                 Recommande: orphan-sysvinit-scripts mais ne sera pas installé
E: Erreur, pkgProblem::Resolve a généré des ruptures, ce qui a pu être causé par les paquets devant être gardés en l'état.
E: The following information from --solver 3.0 may provide additional context:
   Unable to satisfy dependencies. Reached two conflicting decisions:
   1. sysvinit-core:amd64 is not selected for install because:
      1. systemd-sysv:amd64 is selected for install
      2. systemd-sysv:amd64 is available in versions 257.13-1~deb13u1, 257.8-1~deb13u2
         [selected systemd-sysv:amd64=257.13-1~deb13u1 for install]
      3. sysvinit-core:amd64 Est en conflit avec systemd-sysv
         [selected systemd-sysv:amd64=257.13-1~deb13u1]
      For context, additional choices that could not be installed:
      * In systemd-sysv:amd64 is available in versions 257.13-1~deb13u1, 257.8-1~deb13u2:
        - systemd-sysv:amd64=257.8-1~deb13u2 is not selected for install
   2. sysvinit-core:amd64 is selected for install because:
      1. sysv-rc-conf:amd64=0.99-10 is selected for install
      2. sysv-rc-conf:amd64 Dépend sysvinit-core

Any idea to fix this ?

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

FOG 1.5.9

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.

“An error has been detected! … Resize test failed! … Device name: /dev/sda3 … Space in use: 10535MB (16.6%) … Needed relocations: 1610313 (6596MB) … ERROR(28): Could not update runlist for attribute 0x80 in inode 156294: No space left on device (shrink partition) Args Passed: /dev/sda /images…”

Previously I had no issue capturing an install using Windows 11 Build 28000.1836 via FOG. The older build allowed for smaller VM disk size such as 40GB if I recall. The newer June 2026 ISO Build requires around 50GB for Windows 11Enterprise to install (else there is an error) so I allocated 60GB to the current VM (where I am getting the capture error).

I found that on the June 2026 Build (28000.2269) if I set the EFI partition size to 2GB (still using 60GB VM disk size) during the installation using diskpart, complete the install, enter audit mode, sysprep, and then attempt the capture I am successful and there is no resize failure. Why does setting the EFI partition to a larger size allow the capture process to succeed? (I found this by accident as I was increasing the EFI partition for another reason discussed in the side note here)

Stopping FOG Status Reporter…Done
Mounting directory…Done
Changing hostname…Done
Mounting directory…Done
Task Complete
Updating Database…Failed
Error returned: No Active Task found for Host: XXXXXX-01 (mac address here)
Reattempting to update database…Failed
Error returned: No Active Task found for Host: XXXXXX-01 (mac address here)
(The last two lines above repeat 10 times)

-I have tried multi-casting with different images and on different workstations and I get the same error messages.

-I have actually done a fresh install of Arch and then a fresh install of FOG(using the same version listed above) on a different server without any kind of migration from my existing server and successfully captured my image, but then when trying to multi-cast it back out to the workstations, I get the same error messages.

-I did deploy my image to a single workstation(using the deploy button in the Hosts tab) and that did work correctly without any errors.

-The image is indeed written to the workstations when using the multi-cast method and I am able to boot the workstations. However, I believe because the task isn’t finishing properly, the renaming of the workstation and the joining of the workstation to the active directory are not being initiated.

Please let me know if there is anything else I can try on my end to help troubleshoot this issue!

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

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

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

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.

I am having a problem deploying and capturing images with FOG on a HPE MicroServer Gen11 using Intel VROC RAID1.

Environment:

• FOG 1.5.10.1754
• Ubuntu 24.04.3 LTS
• Latest FOS kernel and init tested (20260306)
• HPE MicroServer Gen11
• Intel VROC SATA RAID Controller
• PCI ID: 8086:2826
• RAID1 volume named “SISTEMA”
• RAID size: 150 GB
• Two 1 TB SATA drives

Symptoms:

• Windows Server 2025 installs and boots correctly on the RAID1 volume.
• Intel VROC reports the array as healthy.
• Sysprep completes successfully.
• FOG can capture and deploy the image.
• However, after deployment the RAID becomes degraded and Windows fails to boot with INACCESSIBLE_BOOT_DEVICE (0x7B).

What I found:

• In FOS debug mode, lsblk only shows the physical disks:

/dev/sda 931.5G
/dev/sdb 931.5G

The RAID volume itself is never exposed as an md device.

mdadm can detect the Intel IMSM metadata:

mdadm --examine /dev/sda

Output includes:

Magic : Intel Raid ISM Cfg Sig
RAID Level : 1
Array Size : 150.00 GiB
Volume Name : SISTEMA

However:

mdadm --detail-platform

returns:

mdadm: imsm capabilities not found for controller:
/sys/devices/pci0000:00/0000:00:17.0 (type SATA)

Additional tests performed:

• Updated bzImage to 20260306
• Updated init.xz to 20260306
• Tested IMSM_NO_PLATFORM=1 mdadm --assemble --scan
• Tested mdadm -IRs
• Tested mdadm --assemble --scan --force

None of these create an md device and lsblk continues to show only sda and sdb.

It appears that FOS can read the IMSM metadata but cannot assemble or expose the Intel VROC RAID volume, causing deployment to operate directly on the physical disks instead of the RAID volume.

Has anyone successfully used Intel VROC (PCI ID 8086:2826) with FOG/FOS?

Any advice, patches, custom kernels, custom init.xz images, or mdadm workarounds would be greatly appreciated.

Thank you.

Sorry for the delay 😞

I checked what you told me to do. It appears I have a file that I didn’t check : /etc/php/8.4/fpm/pool.d/www.conf
I set display_error=off and now I don’t have all those warnings.

Thank you for your help.

This is perfect 🙂

• No problem to get an IP and access the FOG server
• Registration works great
• When trying to image I get a /tmp/hinfo.txt not found and then a lot of errors I guess linked to the missing hardware info

So I tried to verify :

wget -q -O hinfo.txt “http://192.168.2.254/fog/service/hostinfo.php?mac=002432ae6bb2”
And I just get " cannot view from browser"

Other PXE bootable computers works perfectly

Any idea on what could cause this ? Many thanks

Any help you can provide in helping me re-gain access to the web interface would be greatly appreciated. Thank you!

www-error.log

I did a complete Ubnutu and fog fresh install to make sure I wasn’t missing anything and noticed during the installation it was grabbing my WAN IP as the fog server IP and then somehow changing the fog server IP to my LAN IP. So when I clicked on the link from the terminal after it had finished it was 192.168.1.148 however everything was setup “certs, storage Ipxe” ect as my WAN IP 20.21.X.X.

All I had to do was just change the fog settings so the IP’s matched re ran the installer to grab the new files and everything is running perfect now.