@george1421 Thank you for this suggestion. This disabling of “fastboot” worked PERFECTLY! I interrupted the OOBE with Shift + F10 and got the command line window. I shutdown using the “shutdown.exe -s -t 0” command you suggested. Then after booting up, the FOG capture task I had already started took over and it captured 100% as it should have.

Essentially, I had forgotten to disable fastboot like I normally do on EVERY computer I have. So when it “rebooted” it technically wasn’t rebooting the device since fastboot is a misguided absurd hibernation feature Microsoft developed. The error I got was nearly identical to the one in the original post.

Thanks so much for this suggestion George and all!

9d53d15e-eb10-4045-9c90-31f6c156aa7d-image.png

I know this is an ancient topic, but I wanted to make sure I updated anybody who was interested in a docker image to my new one.

please check my post here

https://forums.fogproject.org/topic/18000/unofficial-docker-image-beta

Ok so I now have a second system with the EXACT same issue. I purchased a Dell Precision 7875 which has 2 on-board nics. I updated our dhcp server to issue an IP address for one of the two NICs. With the system connected to that interface I PXE booted the system. The first stage of the fog shows as it notices the system is not registered and asking whether I would like to register the system. Yet once I say do full registration that’s it it will not proceed further.

So similar to the issue that I’ve raised prior with multiple NICs and @george1421 suggested I PXE booted the system again but went into DEBUG mode. Well as it appears the unused MAC address is now showing up on the interface that I had configured to connect to the network. Seeing that I did not assign an IP address to the second mac address the system would not proceed any further. The odd thing is that BOTH interfaces show up having the same mac address. It seems that there’s an issue with the FOS with newer Dell systems with multiple NICs.

If I disable one of the two NICs in the BIOS, and do the re-imaging process everything works fine…

Really looking for a fix for this…

Cheers

Jason Naughton

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