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.

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

Here is the working config

# detect iPXE dhcp-userclass=set:ipxe,iPXE dhcp-match=set:ipxe,175 # FIRST STAGE: UEFI firmware -> iPXE using SNP dhcp-boot=tag:fog,tag:!ipxe,tag:!maas,snponly.efi,10.20.192.13,10.20.192.13 # SECOND STAGE: iPXE -> FOG (give it the script directly) dhcp-boot=tag:fog,tag:ipxe,tag:!maas,default.ipxe,10.20.192.13,10.20.192.13

Factory default.ipxe.

I think deleting autoexec.ipxe was the missing piece a la https://forums.fogproject.org/topic/17937/uefi-boot-kernel-panic-unable-to-mount-root-fs-on-dev-ram0/9?_=1768445663029? Unfortunately, I tried so many different things that I am afraid to try to reproduce the failure and not be able to get back to a working state.

Regardless, it was not a missing NIC driver as I originally suspected. Thank you for your help nonetheless.

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

@sgennadi Can you please provide more information on this?

Is this still happening in the latest 1.6?

I’m asking mainly because I’m not sure what is happening:

What I think I see:
On image create task gets ready to complete after doing the data gathering:

It correctly removes the /image/<imageNamePath>
It does NOT move /images/dev/<macaddress> -> /image/<imageNamePath>

So a work around exists (as annoying as it may be) that you can manually move the /images/dev/<macaddress> to the image name and that will still work though I agree it should be automated.

I believe 2141 may have been early on in the moving toward SSH purely for handling image moving and I would hope that this problem is addressed in newer files.