@JYost
Thank you George…this pointed me to the etc/network/interfaces file where I found that the dns-search field only had “domain.local” and was missing “domain.com”. Once I added that into the dns-search field all was good and FOG was able to see devices which were online (denoted by green Windows icon).
Thanks again guys…great support as always!!!
Go ahead and mark this as solved.
Best posts made by JYost
-
RE: Fog Host Management Screen - Creating new hosts issueposted in FOG Problems
-
RE: Snapins check in but don't installposted in FOG Problems
Disregard - problem has been solved. I renamed a .msi setup file but forgot to edit the filename in the snapin configuration.
-
RE: Unable to Image a Lenovo E14 Gen2 (Type 20TA/20TB)posted in FOG Problems
Just heard back from our Cali, Columbia office. All is well, device imaged fine with no errors. Thanks again for the awesome support!
Latest posts made by JYost
-
Windows Recovery Screen after imaging with USB dongleposted in FOG Problems
After a couple of recent FOG upgrades we are experiencing a strange issue when imaging laptops. If the laptop is equipped with an on board LAN port (RJ45) the image works fine, snapins install, and all is good. If the laptop only has a USB-C port and we use a USB adapter the image will come down fine, however after the restart it will immediately come up to the recovery screen. We are using the MAC address of the USB adapter and we have LAN pass through disabled in the BIOS. We are using Ubuntu 24.03 with FOG 1.5.10.1721, however it happened with the previous version as well (Sept.2025). The laptops we’ve encountered this on thus far have both been Lenovo L14 Gen2 (Type 20X1/20X2), however these devices imaged with USB dongles without any problem before the 2 most recent FOG updates. Any ideas/suggestions would be greatly appreciated. Thank you in advance!!
-
RE: Broken iPXE boot loaderposted in FOG Problems
I’ve downloaded the file ipxescript.txt file - Does the extension needs to be renamed to something else as it’s a script (i.e. .sh (bash??)? Also, what directory do I place the script in? (Sorry for the ignorance…I’m not a Linux guru)
Thanks again guys!
-
Broken iPXE boot loaderposted in FOG Problems
I did something dumb…tried to update my iPXE boot loader using the following tutorial…
https://forums.fogproject.org/topic/15826/updating-compiling-the-latest-version-of-ipxe?_=1734560565182
I thought that our FOG server was initially set up using the git method, but apparently it was done so using the tarball extractor. After running the commands shown (adjusting for a different folder structure) I am now left with the following error when trying to PXE boot and download an image…
How do I go about fixing this? Thanks in advance for any assistance.
(FOG 1.5.10 on Ubuntu 20.04) -
Snapin File Exists option missing from Create New Snapin after 1.5.10 updateposted in FOG Problems
The dropdown option “Snapin file exists” has disappeared from the Create new snapin page after the 1.5.10 update. I used to be able to copy a file to the snapin directory, then select it using the dropdown. Now it forces me to browse to the file and download to the /snapin folder. I selected the .msi I wanted to import into the /snapin folder but it never shows up. I must be missing something but there doesn’t seem to be a way to create a new snapin any longer.
-
Disabled snapins are still showing up in snapin selection screenposted in FOG Problems
I have about 20 snapins which I’ve made available for techs to select during the pre-imaging setup for workstations. One of the newly created snapins I have disabled temporarily as I did not want it made available (YET), however it is showing up in the “Available Snapin” list, and techs are able to select it and install it without any problem. To me, disabling a snapin (should) make it unavailable for selection to install although I may be incorrect in my assumption of exactly what disabling a snapin does. Can you elaborate - is this a bug or normal operation? Aside from actually deleting the snapin is there a way to have the snapin present, but not available for techs to select/install? Thanks in advance. FOG 1.5.10 on Ubuntu 20.04.
-
RE: Domain username name not auto populating in fieldposted in General Problems
@Sebastian-Roth
Thank you Sebastian, I will give that a try. Thanks again for the excellent support! You can close this ticket. -
Domain username name not auto populating in fieldposted in General Problems
Background: We recently changed the user account that we use with FOG to join the domain. That account was set in the FOG settings page / Active Directory section.
Whenever we image devices now we come to the Active Directory tab in the web interface, but it is still showing the old user account in the Domain Username field. If we uncheck and re-check the ‘Join Domain After Deploy’ checkbox the field auto-populates with the correct/new username. My question is whether there is some cached data that we need to clear out so that the new account name automatically appears in the Domain Username field without having to uncheck and recheck the top checkbox. We have over 2000 hosts on multiple servers - that is a lot of unchecking and rechecking boxes!!!We’re running FOG 1.5.9 on Ubuntu 20.04
-
RE: Unable to capture image after performing iPXE boot loader updateposted in FOG Problems
I just tried another capture after changing the FOG client on the image to point to our FOG server in Germany. This time there was a normal 1 minute pause during the resizing process then Partclone G-zip started and imaged without problems. All seems normal again…gremlins have been eradicated. You can mark this as solved.
-
RE: Unable to capture image after performing iPXE boot loader updateposted in FOG Problems
I did notice something odd about the latest image capture though…
Normally using Partclone G-Zip we end up with 10 files in the image…this time we ended up with 11 files:
And here is the 21H2 image I captured immediately prior to the iPXE boot loader update - 10 files:

-
RE: Unable to capture image after performing iPXE boot loader updateposted in FOG Problems
@george1421
The VM partition is 60GB - as far as fragmentation goes the partition resides on an SSD which shouldn’t be defragmented. I’m not of the opinion that fragmentation had anything to do with the slow resizing as the image I captured immediately before the iPXE boot loader update resized within a minute or so. The same image was captured after the boot loader update (the only difference being the FOG client installation using a different IP.)Even with the long resizing the second time around the image uploaded and downloaded fine without any errors.
Sidenote: You stated that FOG 1.5.9 had issues with 20H2 and possibly even 20H1. Ironically we have been using FOG 1.5.9 with 20H1, 20H2, and 21H1 without any issues whatsoever. 21H2 is where we ran into problems.
So, moving forward…for the rest of our fog servers I take it that the order of operations to fully update our servers should be as follows:
1.) Update FOG to v.1.5.9.111 by updating the FOS init (is server restart or re-run install fog.sh required here?)
2.) Update Kernel to latest version, then restart FOG server
3.) Update iPXE to latest version, then re-run installfog.shAgain, thank you George, Sebastian, et al. for the excellent tech support. You guys are geniuses.