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

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

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

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

@jmeyer Myself and another form moderator (Wayne Workman) came up with the concept of a mobile fog deployment server. The concept is that you would load FOG on a portable device (laptop or mini computer) with all of the necessary items for image deployment. IMO if this was going to be a truly portable computer a laptop with the built in screen and keyboard would be a better option. If you functioning as a MSP wanted to sell an imaging service than the mini or micro computer would be a better choice.

So the concept of the mobile fog deployment server is that the portable computer would have a full fog system installed on it. To minimize setup the mobile deployment server will have its IP address assigned by the remote site’s dhcp server. In this case FOG would not be your remote’s site dhcp server but it would function as a dhcp client (more on this in a bit). The next part you need to address is how to get the pxe boot information in the remote sites dhcp environment. You will do that with dnsmasq configured in a proxy dhcp mode (I have a tutorial on how to set this up in fog in the tutorial section). In this mode the FOG server (dnsmasq) will only provide pxe boot details leaving the remote site’s dhcp server untouched. With this configuration once the mobile fog server is removed from the site no pxe booting information is left behind to cause the remote site’s issues.

The issue you will have is that because FOG’s configuration is intended to be static, having the fog server’s IP address being assigned by dhcp will cause the FOG server to fail to pxe boot, to fix that issue Wayne created a script to automatically update the statically defined fields in FOG to make the IP addresses a bit more dynamic (note this is a fog server issue and has nothing to do with the target network or computers) That script is here: https://github.com/FOGProject/fog-community-scripts/tree/master/MakeFogMobile Looking at it that script is 8 years old, I can’t speak to the suitability of that script with the current version of FOG. It may need to be tweaked, but that’s the beauty of opensource software, if it doesn’t do what you need, you can fix it yourself.

It is possible to create a mobile fog deployment server, and back in the day the one I used worked great. So it is possible to do with little effort.

@djgalloway said in The DDP package file was not found or could not be read:

The DDP package file was not found or could not be read. Entering Safe Mode

This specific issue is the default fog kernel doesn’t contain the required firmware that is required to communicate with your E810 network adapter.

If I built a custom fog kernel for you in the past you already know this, but for the folks that find this post in the future… The fog developers in an effort to make a super fast imaging engine designed it using the 90/10 rule in that they will build a kernel for 90% of the deployments (which mean desktop computers) and leaving the rest for one-off builds. The supermicro servers or servers in general are in a different class than desktop/workstation computers. The desktop/workstation computers are pretty much the same even from different vendors. So the 90% rule has almost all of the hardware drivers built into the kernel. Servers class computers on the other hand have specialty components to aid in redundancy, performance, or monitoring (that other 10%) that are not typically found in the workstation class computers. Natively supporting that remaining 10% means almost doubling the size of the FOS engine kernel as well as having an impact on imaging speed. That is why the native FOS kernel doesn’t have every hardware driver built in. In your case the Intel E810 is a server class network adapter with QSFP28 ports (not something typically found in a workstation class computer).

With that said, I’m sure either the FOG kernel developers or I can create a one-off kernel for you. I will need to resetup my development environment because I just built a new linux server and haven’t move the files over from my old server, so it may take me a day or so to be in the position to create a current kernel with the required firmware built in for the nic.

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

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

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.

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

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