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

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

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

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

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

Also occurring on Dell Latitude 5450 laptops.

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

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