@Infojoe They are one in the same lol and you’re welcome.

@george1421 I have installed fog with DHCP server but DNS doesn’t work at all (no dns server appear on windows client) so I’m stuck.
It’s my first time installing DHCP and DNS on Debian so I think I made mistakes.
DHCP work fine.

edit : It’s fixed. I forgot to add “option domain-name” and “option domain-name-servers” in dhcpd.conf

For the script, I think it must be simple to set FOG as DHCP server at startup if after 10 min no IP is given from a DHCP server then set server to static IP and start DHCP and DNS services.
And then reverse this at shutdown.
Maybe this can be done manually first.

edit : Here is the first script.
I have create files ending with .dhcp for conf for external DHCP/DNS and file ending with .static for conf for local DHCP/DNS.
It looks to work fine.

# Configuration actuelle echo "Etat DNS local :" systemctl is-active bind9 echo "Etat DHCP local :" systemctl is-active isc-dhcp-server echo "" loc(){ # Configuration DHCP local echo "DHCP local" # Configuration if [ -e /etc/network/interfaces.static ] then echo "Copie interfaces" cp /etc/network/interfaces.static /etc/network/interfaces else echo "interfaces.static not found" exit 1 fi echo "Redemarrage service reseau" systemctl restart networking.service if [ -e /etc/resolv.conf.static ] then echo "Copie resolv.conf" cp /etc/resolv.conf.static /etc/resolv.conf else echo "resolv.conf.static not found" exit 1 fi # Services systemctl start bind9 systemctl start isc-dhcp-server } ext(){ # Configuration DHCP externe echo "DHCP externe" # Configuration if [ -e /etc/network/interfaces.dhcp ] then echo "Copie interfaces" cp /etc/network/interfaces.dhcp /etc/network/interfaces else echo "interfaces.dhcp not found" exit 1 fi echo "Redemarrage service reseau" systemctl restart networking.service if [ -e /etc/resolv.conf.dhcp ] then echo "Copie resolv.conf" cp /etc/resolv.conf.dhcp /etc/resolv.conf else echo "resolv.conf.dhcp not found" exit 1 fi # Services systemctl stop bind9 systemctl stop isc-dhcp-server } # Demande de Configuration while true; do read -p "Voulez vous passer en DHCP externe ou en DHCP local? (e:externe l:local) " el case $el in [Ee]* ) ext; break;; [Ll]* ) loc; break;; * ) echo "Please answer yes or no.";; esac done

@eliaspereira This should be fully fixed in the stable release of 1.5.10.x coming on the 15th of this month and in the dev-branch as of now.
I thought it was already fixed back in September, and it has been working in 1.6 since then but we just got a report of a related issue here https://forums.fogproject.org/topic/18081 which I believe I just fixed.

@tian @DBailey635 @eliaspereira Apologies for missing this post. This was fixed in August-ish of last year, see also:
https://github.com/FOGProject/fogproject/issues/736

I found this searching for a post I wrote about it, as I’m pushing another fix for this for a bug just found in 1.5.10.x

If you update to the latest dev-branch (or what will be stable on the 15th of this month) or give the working-1.6 branch aka 1.6-beta a try, you’ll find the queuing problems fixed.

@Tom-Elliott

Great news!

I updated my server to Debian Bookworm, restarted the Fog installation, and the accent problem disappeared. Awesome!

Thanks for your help and happy new year 2026, all the best for the FOG project!

@Tom-Elliott Thank you, Tom. The init version is now 2025xxx. I’ll test soon to confirm the SSD info is showing in logs.

@Florent Thanks Florent. Hopefully it does!

The issues I’ve listed here do seem to only affect older models of Dell, however UEFI (despite having the word unified in the name) varies wildly by vendor, and even within Vendors, so I wouldn’t be surprised to learn there are similar or different issues affecting newer Dells or even non-Dell machines.

That said, based on my experience at work. I can’t say I’ve seen too many machines have the number of bizarre issues as I have seen with the older Dell PCs we have.

As with all things, I’d suggest testing it on some of the machines common in your fleet of computers and seeing what works and what doesn’t.

@Tom-Elliott Really for the purposes of user tracking. It is helpful for us to keep track of who is deploying and capturing. This is purely for transparency and accountability. I can instruct my team to always register devices they are imaging but I cannot force it.

EDIT: Is there a way to force full reg prior to image deployment? Like a prereq for deployment.

@brent could you specify exactly at which point of the installation you see this error? If you notice the installer hangs or fails specifically during the “pinning” stage, it is likely a name resolution issue.

I’ve found a solution for this: you need to manually edit the Windows hosts file at C:\Windows\System32\drivers\etc\hosts and add an entry with your FOG server’s IP address followed by the name “fogserver”. This ensures the SmartInstaller.exe recognizes the server and can download the certificate properly.

Finally, I did my update.

The problem was that I was running Debian Buster, so I first had to upgrade to Debian Bullseye so that the installer could install the new packages.

Then, I made a copy of the fogproject/ folder, deleted the folder to initiate a git clone
Next, I followed the tutorial and restarted the installer, which restored my old settings. The web interface is working, so I assume my clones will work as well.
Thank you.

@ramone

I got your message on the github repo. In regards to the DHCP issue, I’ve updated the code and it should work now. Please test and follow up in the issue thread. Please note that some of the variables in the .env file have changed so you might want to review that before starting it up.

thanks!!

88

Just adding my case here in case it helps someone else with the same error.

I’m running FOG 1.5.10 on RHEL 9.5. In my case the problem was not iPXE, kernels or init.xz, but a broken NFS setup on the FOG server.

When I tried to rerun installfog.sh, it always failed at “Starting NFS server” with a systemd dependency error. Checking systemctl list-dependencies --failed nfs-server.service showed that one dependency was a failed mount coming from /etc/fstab. It was an old ISO mount pointing to a path that no longer existed.

Because that mount failed, nfs-server could not start, and FOS Linux failed to mount its root filesystem over NFS, causing the kernel panic on UEFI clients.

After removing the invalid mount from /etc/fstab, running systemctl daemon-reload, fixing NFS exports and starting nfs-server, I was able to complete installfog.sh and UEFI PXE boot started working again.

@pbriec Sorry that your post got lost in the shuffle, I saw it pop up with @raul’s response.
I imagine/hope you got past this in the last year but just in case, the fix would most likely be resetting the host encryption from the web ui (removes some token related database entries on the host record) then restarting the fog service on the client.

If that didn’t do the trick, then restarting the fog service along with resetting the hots encryption should fix it.

@Hojjati I’ve found a solution for this issue that worked for me.
You need to manually edit the Windows hosts file at C:\Windows\System32\drivers\etc\hosts and add an entry with your FOG server’s IP address followed by the name “fogserver”.

This is necessary because SmartInstaller.exe performs a pinning process during installation, if you notice the installer hangs or fails exactly at that pinning stage, it is definitely due to this resolution issue.

Adding the entry ensures the installer recognizes the server and can download the certificate properly.

@nicolas-moraes I managed to solve it and in my case it was not a FOG or network issue. I verified that DHCP was working correctly (confirmed with tcpdump), options 66/67 were unchanged, TFTP was running, and the FOG web/ipxe boot.php were reachable.

The key test was that when the client stayed at “Start PXE over IPv4”, the FOG server was not receiving any DHCP or TFTP requests at all, which pointed to a client-side problem. Even though Secure Boot and Fast Boot were already disabled, the issue was caused by the BIOS state.

After restoring BIOS defaults on the HP laptop and re-enabling PXE IPv4 boot, everything started working again. It seems some UEFI/PXE flags were stuck, and resetting the BIOS fixed it.

@lucasgfaj Thanks for letting us know:

I think I’ve found the issue and pushed a code change to try to fix this.

There is a FOS image experimental release that is building currently (2025-12-21) that should contain this once it’s complete. Please download the inits and install them and run a test to see if this is correcting the issue of capture/deploy Multi Partition Image - All disks and let us know if this new version fixes the issue you’ve reported.

Thank you!

@Kureebow I’ve had this happen to me before. These are the two cases that I’ve seen:

1 - I captured an image in UEFI and the computer that I was deploying it to was in Legacy mode. I also had the inverse of this, where I captured in Legacy and was trying to deploy to UEFI.
2 (the most common for me) - Some sort of RAID or volume management device is enabled in the UEFI. I only use HP so I don’t know what it would be called on Dell, but on HP there is an option that I have to disable “Configure Storage Controller for VMD”.

@CoNickt @avh2025
Not all usb ethernet adapters are created equal. I would usually say to just bite the bullet and get the vendor specific adapter but it looks like you already did that. I have usb and usb-c adapters that work fine but different uefi firmwares behave differently. i.e. Microsoft surface just has to have its surface branded adapter for native boot to work. HP will work sometimes with the dell or lenovo pxe capable usb-c adapters. We also recently got 2 different hp laptop models where one had to use snponly.efi and the other was fine with ipxe.efi. I maintain a table of models and which adapters work with what we have. Lots of things do just work once you have a collection of usb adapters. Unfortunately, it’s an issue of hardware vendors adding proprietary limitations, but luckily between fog and ipxe you can typically get it working pretty smooth.

Generally if you’re able to pxe boot though, it should find the adapter within pxe. It could be a case of it being too “new” an adapter that requires a different driver not in ipxe. In that case though, I would try using snponly.efi as it may have different behavior with less things loaded in the pxe side. It may also be a driver or setting needed in ipxe that could be handled in a custom compile of ipxe, there’s some info on that here https://docs.fogproject.org/en/latest/compile_ipxe_binaries

It’s also possible to use a tool such as rEFInd to get to a uefi cli console. If you load the ipxe.efi and or snponly.efi and then if you can obtain them the efi driver for the adapter you can do a fs0: to enter the usb disk (it may be fs1: or fs2: you gotta ls on each disk to find the right one) then load usb-network-driver.efi then ipxe.efi to ensure the usb network driver is loaded in the efi for that session and then boot direct to the pxe file which will start the fog network boot. It’s a bit of a hassle but it usually works for me when all else fails. I have an old startech usb 2 ethernet adapter I do this with. This has worked universally but it’s not an ideal solution, but can be poc that it can be done on any device.

I hope my rant was helpful.