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

@siarkowski I believe I have found the cause of this.
A while back, right after the version you reverted too, we added an improved queueing system. It was a simple syntax error (the wrong $task->id vs $task->get('id') ).

This should also greatly improve the experience of the imaging task queue (see also https://github.com/FOGProject/fogproject/issues/736 and https://github.com/FOGProject/fogproject/issues/691) I thought I also wrote a post somewhere in the forum walking through the updated process that fixed some longstanding date math issues, but I can’t find that now.

Point being, if you would be so kind as to update to the latest dev-branch version and see if it fixes the issue, that would be very helpful.

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

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

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

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.

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

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.

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

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

@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

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

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

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

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

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