Hi All,

Just looping back to this hoping that someone can suggest a solution on how to fix the FOS so that what is happening (as shown in my prior postings) doesn’t happen to other people. Presently I’m resolving this by pulling the two network cards out so that only one network card is available while the deployment OR capturing is done. Otherwise the mac address changes to one of the other cards installed on the box. I’ve also tried with multiple network cards thinking MAYBE it has something to do with the network cards I’m installing… Sadly no solution as of yet.

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

@raul I have an Ansible role which does something akin to what you’re trying to do here:
https://forgejo.cwavs.xyz/Cwavs/ansible-role-fog it might be worth taking a look and seeing if it helps give you any ideas on how to solve your problem. Happy to answer questions about it.

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

@siarkowski

Hello All,

First hit.
I uninstalled FOG, dropped database, installed FOG again, imported users, hosts, images, started task for 31 PCs and records with taskimageID equal to 0 are being inserted again. 😞

Second hit.
I imaged OS disk, installed fresh operating system, installed FOG, imported users, hosts, images, started task for 31 PCs and records with taskimageID equal to 0 are being inserted again. 😞 😞

Third hit.
I reverted all changes, installed FOG but rev. 1.5.10.1622, imported users, hosts, images, started task for 31 PCs and no records with taskimageID equal to 0 are being inserted 🙂 Not to be so happy another issue appeared, tasks do not start automatically I have to force it to start, but it’s different story.

@Infojoe Please try the latest dev branch. this should be fixed.

The issue was simple:

Basically the arguments are stored and from what I could tell, work, but when the HTML side would go to re-display it it would make an input value of:

value=" -Execution -File "[FOG_SNAPIN].PS1""

Do you see the problem?

From HTML side, it would think the string ended at the first double quote.

This has been found and should be fixed in the latest dev-branch.

@CanadienITGuy @gchartrandCRL I had to switch from using ipxe.efi to snp.efi for all my newer HP machines. Please try changing that in your DHCP scope options.

@Tom-Elliott

I’m on Debian Bullseye.

I can’t install php-gettext, and i installed php-php-gettext (not installed), restart php7.4 but no better.

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

@bond007fink @jayrehme
By “Latest Update” do you mean the December updates for Win 11 or do you mean the latest release version of 25H2 ? I haven’t tested 25H2 yet.

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