@Tom-Elliott I can confirm that it works with v1.5.10.1760. 🎉 Thank you very much! 🙇

@The-Dealman Awesome thank you! and we did publish 1754 specifically due to this issue (manually running the automated processes just in case your org is worried at all 🙂 )

@Tom-Elliott Sorry for the lack of clarity in my explanations and the use of screenshots unrelated to my problem.

I have upgrade to the last beta and deploy on registered host works well.
Thank you.

I’ll check if not registered host now appear in Pending Hosts.

I had some problems with AMD computers and found this

https://knowledge.broadcom.com/external/article/269598/firmware-settings-for-ipxe-boot-on-lenov.html

"Resolution
During iPXE troubleshooting it has been determined that the following settings in Firmware/BIOS for Lenovo Thinkpad L15 Gen 3 need to be adjusted to allow for a successful iPXE boot:

Memory protection - Set to ‘disabled’
AMD V™ Technology - Set to ‘disabled’

There also may be certain environments that require further changes. For further information contact Lenovo Support.

Additional DS (Deployment Solution) and GSS (Ghost Solution Suite) files can be found in KB article Updated 64-bit ipxe.efi (ipxe v1.21.1+) binaries

NOTE: The files in the above KB article are not a pointfix but are new version binaries signed by Microsoft"

Leaving it here, because it solved my problem and it sounds like your problem

@george1421
to be adding some to this topic since our system was broken again with the same problems.

I updated recently to newer fog version (1.5.10.1751 and today to 1.5.10.1754) and that seems to break it again.
I noticed that updating also starts using latest Initrd. (2025.02.4)

Things are broken with latest Initrd. I set it back to 2024.02.9 AMD/Intel 64 bit and it is working again.
Then i updated Initrd to 202502.0 AMD/Intel 64 bit and it is still working.

Strange thing is that in webinterface the latest version is shown multiple times.
When I open and download the upper one during pxe boot I see version 20251221 loaded. That one is not working.

Is there anywhere to analyse what the differences are?

I also want to add that we were focussing on nvme. But VROC doesn’t seem to work with nvme in raid.
There are sata ssd/nvme in those slots.

4bcbb845-8bb5-458c-b27a-8794b9b0a5b6-afbeelding.png

@alexamore90 I think you’re asking for something like this? https://forums.fogproject.org/topic/9463/fog-postinit-scripts-before-the-magic-begins?_=1768874256297

Also occurring on Dell Latitude 5450 laptops.

@sgennadi
Fixed by
touch /images/dev/.mntcheck

Problem exists also with latest 1.6 builds…
I think problem something in my database…
When fog competed image early I see failed to update database… latest version no error but folder with previous version of image removed
Task present not removed

@alperi The bit if detail you are missing is what the kernel parameters were that was sent to the fog client. From what you posted it appears that the FOG server has all of the bits in the right spots.

In the kernel parameters that are passed to bzImage during boot up it lists where the FOS engine can find the deployment server. I would verify the IP addresses are correct. If everything appears correct with the parameters, we can debug this a bit more by debug deploy and then manually interact with the fos engine from the target PC’s console.

@djgalloway Just to add a bit of detail here. All of the work you did was on the iPXE side, which is great work by the way. The kernel driver I updated was after you select an FOG iPXE menu item that is when bzImage is loaded and run. It relies on kernel parameters that is provided by iPXE to find the root file system. This is technically what you fixed by ensuring that default.ipxe/boot.php from the fog server was being called. At the end of the day, I’m glad you got that working because your setup is definitely an edge case that works well in your environment.

@Tom-Elliott Alrighty. So my FOG server at another location is acting up in the same fashion with the failure to check in.

Before we used it I updated to 1.60-beta.2265 to hopefully negate it but I did not drop the fog table from mysql before doing so.

Are there any logs you want me to pull?

Was not sure which ubuntu version of these (20.04, 22.04, or 24.04) was used as the basis for the FOG release v1.5.10.1734.

Thanks, @FOGBreaker101, for the version you are using.

Some software doesn’t use the latest released version of the OS distro, but often one major version back.

@Clebboii Are you still seeing these issues?

We did find another (separate but similar) bug relating to Phantom tasks as well, so you may need to update to the latest and this should be addressed too.

Please let us know, thank you!

Can you help me with bug topic ?
Fog 1.6.0-beta.2141 remove folder with image

I am very interested in doing this. I have a working FOG server which is working in my home network with no mods to my router which is a Firewalla gold if it matters. I have several FOG menu items that work but I am finding it increasingly harder to keep them up to date, for example parted image, which I can’t get to work with the latest versions despite reading alot of stuff in the forums. I also created a ventoy USB which also seems to work with what I have added to it so far with a few exceptions but having it all be in PXE would be even better since it is centrally located. The problem I have run into with FOG booting ISOs almost always comes down to the size of ISO though. Does iventoy via PXE solve that by any chance? I can also pull apart the ISOs but then I am micromanaging and spending hours getting it all to work which I am trying to minimize. I like the nerdyness of it all but I have enough other nerdy projects for now. lol. Dropping ISOs into iVentoy PXE would be super simple. If anyone else has done this, could you post your configs for FOG please? I really prefer to not make changes to my Firewalla if possible. FWIW, I have wired ethernet throughout the entire house which made PXE booting pretty easy.

@CanadienITGuy Just for your and anyone’s fyi the autoexec.ipxe... Not Found is not an error. It’s more of an info message than a warning or error.
I actually have tested adding an autoexec.ipxe, even just an empty file to remove that message but even an empty file or a file that is even just a symlink or copy/paste of our normal ipxe/boot menu files causes things to break in the process.
The autoexec.ipxe is meant for adding customization to the ipxe process without needing to re-build the ipxe binary. But my testing with it within the fog workflow was that it’s best to just let that message exist and to see it as it being not found means the process will not be altered from your expected Fog ipxe workflow

@george1421 Thank you for this suggestion. This disabling of “fastboot” worked PERFECTLY! I interrupted the OOBE with Shift + F10 and got the command line window. I shutdown using the “shutdown.exe -s -t 0” command you suggested. Then after booting up, the FOG capture task I had already started took over and it captured 100% as it should have.

Essentially, I had forgotten to disable fastboot like I normally do on EVERY computer I have. So when it “rebooted” it technically wasn’t rebooting the device since fastboot is a misguided absurd hibernation feature Microsoft developed. The error I got was nearly identical to the one in the original post.

Thanks so much for this suggestion George and all!

9d53d15e-eb10-4045-9c90-31f6c156aa7d-image.png

I know this is an ancient topic, but I wanted to make sure I updated anybody who was interested in a docker image to my new one.

please check my post here

https://forums.fogproject.org/topic/18000/unofficial-docker-image-beta

Ok so I now have a second system with the EXACT same issue. I purchased a Dell Precision 7875 which has 2 on-board nics. I updated our dhcp server to issue an IP address for one of the two NICs. With the system connected to that interface I PXE booted the system. The first stage of the fog shows as it notices the system is not registered and asking whether I would like to register the system. Yet once I say do full registration that’s it it will not proceed further.

So similar to the issue that I’ve raised prior with multiple NICs and @george1421 suggested I PXE booted the system again but went into DEBUG mode. Well as it appears the unused MAC address is now showing up on the interface that I had configured to connect to the network. Seeing that I did not assign an IP address to the second mac address the system would not proceed any further. The odd thing is that BOTH interfaces show up having the same mac address. It seems that there’s an issue with the FOS with newer Dell systems with multiple NICs.

If I disable one of the two NICs in the BIOS, and do the re-imaging process everything works fine…

Really looking for a fix for this…

Cheers

Jason Naughton