@bond007fink I want to push back on the conclusion being drawn here.

There are multiple workarounds mentioned in this thread, and at least one other user has already pointed out that this behavior correlates with recent Microsoft updates. That strongly suggests a change in how Windows is laying out or flagging the filesystem — not a regression in FOG itself.

FOG does not implement NTFS.
FOG does not write partclone.
FOG orchestrates existing, well-established tooling to capture and deploy disk images.

When Microsoft changes disk metadata behavior in a way that causes ntfsclone/partclone to behave differently, that does not automatically make it a “FOG bug.” At best, it’s an upstream compatibility issue; at worst, it’s Windows leaving the filesystem in a state that violates assumptions those tools rely on.

For something to be classified as a FOG bug, it needs to meet at least one of the following:

A regression introduced by a FOG code change Incorrect parameters being passed to the underlying tooling A failure in FOG’s logic that independently causes the issue

None of that has been demonstrated here.

If someone can provide

A reproducible case across systems Debug runs showing FOG invoking tooling incorrectly Evidence that FOG’s behavior changed independent of OS updates.

then I’m happy to investigate it as a FOG issue.

But attributing “FOG needs to fix this” to what appears to be an upstream file-system behavior change isn’t accurate, and it doesn’t help move the problem toward an actual solution.

To be clear: I don’t mind helping fix problems - even upstream or compatibility issues - if there’s a clear, reproducible failure that can be attributed to something FOG controls.

What I do mind is hand-waving the problem away with “FOG needs to fix this” without showing:

how to reliably reproduce it what changed that caused it or where FOG itself is behaving incorrectly.

Saying it works if I use an older image or it started after recent Windows updates is useful diagnostic information - but it points away from FOG being the root cause, not toward it.

If someone can demonstrate that:

FOG is passing incorrect parameters FOG logic regressed or FOG can reasonably detect and mitigate a specific file-system condition.

then I’m happy to look at code or tooling changes.

Until then, attributing this to “FOG needing to fix something” is a conclusion without evidence.

@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

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

Looking at my other Fog server at home, it does not appear to have the same issue. I can dig deeper here but on the surface, the major difference is that the home machine is Ubuntu 24.04 with fog version 1.5.10.1650

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!

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

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

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

@Tom-Elliott thx👍