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

@george1421 noted. When I was initially testing, I did not know this and it took some digging in the forums to find this tidbit of knowledge. Given that having separate storage groups stops replication between the nodes in my mind it makes most sense to have a more distributed setup of normal servers at each site to handle all of my requirements. Thanks for the input!

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

@Tom-Elliott Thank you so much Tom, as always I appreciate your support and guidance.

Yes, I’ve had the same issue since the most recent Windows 11 updates, can’t resize the image

@Tom-Elliott Hi Tom,

Thank you, that clarifies a lot. I now understand that hostSecTime represents the expiration time, not the creation time, which fully explains the consistent +30 minute offset I was seeing. That part now makes sense and resolves my question.

The only remaining actual issue I’m trying to understand is the snapin behavior: in several cases, snapins did not execute on some hosts. I don’t see any errors in the logs. Only that the snap-in task doesn’t start, but I will work on this and gather some more data. Thank you!

@Tom-Elliott Yep, I caught that workaround in the earlier post. I moved the image folder from /images/dev to /images, but still resulted in the same error.

One thing I noticed this morning, is that the image capture process is hanging at 99% on the task page, as in for at least 45 minutes. Not sure if that is a symptom or the cause.

The previous post was suspect of a very recent init version – but i’m on the most recent dev-branch.

Thank you!

Thank you george1421 that 's was the solution.
I was troubleshooting remotely, and the technician on site insisted that images had already been downloaded onto it.

I understand your point of view, but I also have to remain anonymous to my colleagues.

Solved !

I am confident I have ruled out NFS. I can now connect to the NFS from localhost and Ubuntu to /images & /images/dev without issue and all the permissions that come with it. The only thing failing now is FOG, any guidance would be great!

@george1421

Ok so the system in question has an on board nic (enp128s31f6), 1 single port Intel PCI-E Gigabit NIC (enp5s0), and 1 dual port Intel PCI-E Gigabit NIC (enp3s0 and enp4s0).

So I booted the system with a Linux system rescue USB key. The network cable is plugged into the single port nic. You can see that it has the IP address 172.16.57.22 was fetched. Without any issues. The mac addresses on the identified nics are:

enp128s31f6 - d4:a2:cd:b7:17:f2 enp3s0 - 00:13:3b:50:b2:b0 enp4s0 - 00:13:3b:50:b2:b1 enp5s0 - ec:08:6b:04:f9:d9 (the one that is attached to the network cable)

SysResecue-Image.jpg

Now when I boot the system up into debug mode with FOG into the FOS environment it seems whatever port is pluged into the lan it adopts another NIC’s mac address as shown below:

FogClient-Image.jpg

Now you can see when the fog client boots the mac address changes on the port that is connected to the LAN as:

enp128s31f6 - d4:a2:cd:b7:17:f2 enp3s0 - 00:13:3b:50:b2:b0 enp4s0 - 00:13:3b:50:b2:b1 enp5s0 - ec:08:6b:04:f9:d9 --> Changed to 00:13:3b:50:b2:b0 (the one that is attached to the network cable)

Now I’ve plugged the cable into enp128s31f6 and setup dhcp on that port as well and tested it. When the fog client starts all of sudden the enp128s31f6 has another NIC’s mac address…

Just a re-cap if I pull the two network cards, and do the re-image on the system I have no issues. It only occurs when I put an additional nic into the system… Any suggestions?

@chevengur there is not enough information to help you in that picture. If we could see more of the error message that partclone threw (i.e. just above the top of your picture) we would know what happened. At the point in the script all we know is that partclone wasn’t happy.

@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

@Sebastian-Roth Can I bother you with this quick question ^^^

@rodluz
Problem solved - the disk with the image was damaged

@lmoysidis I’m not using fortigate but check out the following article: https://docs.fogproject.org/en/latest/installation/network-setup/proxy-dhcp/?h=
I needed to dynamically assign a boot file based on vendor class and dnsmasq did the trick!

I reverted back to a snapshot I had on the same version and it’s working as expected. Unsure how things got corrupted but I would say it’s safe to assume this is working unless others report the same issue.

Some Updates (08/12/2025): Fedora has successfully obtained a signed copy of Shim 16.1 which should fix Dell Network boot issue. You can obtain it by downloading the rawhide rpm package and extracting it. I haven’t tested it yet, but will post an update once I do. Around 9 months ago, it looks like a change was pushed to fog which actually updated the general.h header file, enabling the shim command by default. As such performing this modification manually isn’t required anymore.

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