Categories

  • 12k Topics
    114k Posts
    Tom ElliottT

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

  • Get the latest news on what's happening.
    184 Topics
    825 Posts
    A

    @Tom-Elliott I really appreciate that you are putting effort into providing more frequent releases, which makes it easier for everyone to deploy new security fixes in time. Keep up the good work!

  • View tutorials or talk about FOG in general.
    2k Topics
    19k Posts
    K
    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. - I have now tested the new shim, and can confirm it works. 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.
  • Report bugs, request features, or get the latest progress.
    2k Topics
    21k Posts
    F

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

144

Online

12.4k

Users

17.5k

Topics

156.0k

Posts