Unable to Capture an image: ERROR: Could not adjust the bad sector list

[bond007fink]

Hi Fog Support Community,

I am all of a sudden having an issue capturing an image the error is

Error: Could not adjust the bad sector list
(ShrinkPartition)
Args Passed: /dev/sda3 /images/00155d0a050f/d1.orignal.fstypes 1:2:4:5

I have tried the following
chkdsk via both the command prompt and windows media
Updating FOG to the latest
Change the Kernel Version
Changed CAPTURERESIZEPCT to 15
Fog Debut FixPart

Still no go, I am able to deploy my old image still but not capture

I still have plenty of disk space

[bond007fink]

@bond007fink I also did a check disk using gparted.

I am able to capture the image if I turn off compression using Multiple Partition single disk (Not Resizable)

[jayrehme]

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

[bond007fink]

@jayrehme Thank you, I updated the files I need on an October image and it worked. Looks like its a bug that Fog is going to need to fix.

[Tom Elliott]

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