@bond007fink The Could not adjust the bad sector list error generally indicates that NTFS metadata (bitmap / bad cluster map) is in an inconsistent state. FOG relies on ntfsresize and partclone to safely shrink and copy NTFS volumes, and if those tools cannot reliably map the filesystem, the capture will correctly fail.

This can occur even when the drive is physically healthy. A filesystem marked dirty will prevent offline resize operations. In that case, FOG is behaving as designed — failing here is preferable to deploying a potentially corrupt image to multiple systems.

We are seeing this more frequently after recent Windows updates, which appear to be leaving or reasserting the NTFS dirty bit.

Please boot the source machine into Windows and run a full filesystem and encryption check. Make sure to adjust the drive letter if your system volume is not C:.

chkdsk /x /r /f C: manage-bde -ff C:

Also ensure hibernation is disabled, as it can leave NTFS in a state that prevents offline resizing:

powercfg -h off

If capture succeeds when resizing is disabled, that further confirms this is a Windows filesystem state issue rather than a FOG defect.

FOG cannot safely work around filesystem states imposed by other vendors. Ignoring NTFS safety checks would risk data integrity, and that is not something FOG should or will do.

My Fog version : 1.5.10.1734 over Ubuntu 22.
It just looks like double-quotes escaping problem…

@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

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

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

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!

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

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

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.

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