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.

[bond007fink]

@Tom-Elliott you would need to fix FOG so that it works with the latest windows update, that is on FOG. Maybe its not a Bug But a Required Feature update to make it compatible with the latest windows 11 update.

I would get a windows computer updated to the latest build and try to capture with FOG, if it works I am mistaken and I apologies for the inconvenience.

[Tom Elliott]

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