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

@88fingerslukee hello,
As promise, i ve tried your image and i wont confirm that works with external and different port database! i just wanna compliment for you work. you made it.

There is one small problem that i think is mine, but i havent found the cause:
when i running up the docker-compose.yml, the fog server and the database goes up, but the login page return itself in a loop when i try to log in (http://fog_server_ip/fog/management/login if i im not going wrong). Can you help me to find the cause?
Thanks.

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

@lukebarone Thanks, i will try !

@Infojoe I tried escaping the quotes but that didn’t change anything on my side. And it’s odd that the template form in the snap pack does not include escapes if they are required.

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

Quick Update (19/12/2025):

Hi Everyone,

I’ll probably open another topic for this in the coming weeks, as it probably deserves it’s own thread for bug reports and feature requests etc (mostly need to convince myself to write it, but also wanted to double check which category such a thread should go under, is tutorials fine?), but I’ve created an ansible role to help with the installation and configuration of fog.

Notably it will help with creating a secureboot valid setup with shim like above. It should implement most of the important functions of the fog installer, and can also automatically perform a lot of the steps in the guide above for you.

I figured I’d drop it here on the forum somewhere in case it’s helpful for others. More detailed usage information will be added to the readme or the new topic. Naturally I’ll link to a new topic here once I get around to making it.

The role is currently hosted on my forgejo instance here: https://forgejo.cwavs.xyz/Cwavs/ansible-role-fog

Hi Again guys

I have some news about this problem.
I found a work around.

I change the file d1.fixed_size_partitions deleting the recovery Windows partition. This change generated and error when I made the deploy image in Client PC.
But if I cancel the job in the CLI fog server and reset the client machine after fog show the error
It boot ok.

I’ll continue reading …
Thanks

@mmoore5553 Understood and appreciate the return with new information.

i’m not sure what caused it but glad it has since been addressed/fixed.

Thank you! And yes, I gave an upvote!

@romprager The simple answer is depends on the iso image and what OS will boot from the ISO image.

I do have several how tos in the forum that shows how to net boot several different installers.

https://forums.fogproject.org/topic/10944/using-fog-to-pxe-boot-into-your-favorite-installer-images

@rodluz I know you were talking to the other person, but if you like you can send me the kernels for testing.