@Bristow-0 I’m not able to replicate the issue:

@Bristow-0 I’m pretty sure its your systems fonts don’t have a way to represent those particular characters. The encoding displays correctly on my machine looking in a terminal.

I’m assuming this worked, then you did an update and it stopped working? I might look at what fonts recently got updated or removed?

@siarkowski That’s perfectly understandable and much appreciated. Sorry I don’t have a simple “here’s what to do” right now, and maybe a fresh install will fix the issue altogether, but right now it we have limited information. Thank you again for your understanding a patience with this as well.

@siarkowski I understand what you’re saying, what I don’t understand is why this is happening at all. If this was a normal issue, we’d have been notified of this issue probably many many times.

I’m not saying this couldn’t be a bug, I just have no way to replicate the issue in a consistent manner.

Might you be able to pull a backup of your database using FOG Configuration -> Configuration Save -> Export

(After cleaning up the Task issue) and see if you can use a secondary system to import that DB and (as a test) and ensure all the data you require is there (not necessarily the physical images)).

I don’t know what to suggest or say here other than I suspect the database is corrupted and it’s that corruption adding and exploding task records. This (again) isn’t to say there isn’t a bug, but I want try to start with a clean baseline and see if things worked properly under “sanitized” environment.

If a fresh server (if you can share your images that much better) works without adding/exploding the task table, that at least proves it’s a DB Corruption issue. If it, too, starts exploding in task table records, then it shows there’s something in the code that’s doing this unexpectedly but at least we narrowed the scope to exactly where to being looking (somewhere in the task checkin process it seems?)

@siarkowski Thanks, the scheduledTasks you’re showing aren’t showing anything out of the ordinary other than these were “Delayed” tasks

First was delayed to run at 2023-04-19 16:30:00 (UTC)
Second was delayed to run at 2025-03-04 16:30:00 (UTC)

I am pretty sure, this isn’t the issue you’re seeing at least.

So I wonder if there’s some corruption due to running out of disk space that’s causing this?

@siarkowski I’m not aware of anything that might be causing this.

The fact that your taskTypeID == 0 in these cases is interesting.

FOG doesn’t have a “create a new task” from Checking in or anything which makes me think what you’re seeing is a symptom, not a cause.

The way tasks get created is either via UI, API, or (similar to UI/API pair) by having a scheduled task.

We have (although it may need more refinement) checks to make sure that type of task that does get created are valid (of which taskTypeID 0 != valid task)

Can you check your scheduled tasks table and see if maybe something there is doing this at some time?

The fact the task was created at 2026-01-02 09:52:02 looks like it could be a schedule task that somehow has a now invalid task type id that’s just managing to get through.

@lucasgfaj Thanks for letting us know:

I think I’ve found the issue and pushed a code change to try to fix this.

There is a FOS image experimental release that is building currently (2025-12-21) that should contain this once it’s complete. Please download the inits and install them and run a test to see if this is correcting the issue of capture/deploy Multi Partition Image - All disks and let us know if this new version fixes the issue you’ve reported.

Thank you!

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

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

@mmoore5553 Understood and appreciate the return with new information.

i’m not sure what caused it but glad it has since been addressed/fixed.

Thank you! And yes, I gave an upvote!

@mashina I’m not sure I understand what “problem” you’re actually seeing?

The TOKEN was written at x time, the SECTOKEN expires 30 minutes later, this is expected.

The REset Encryption token butten IS expected to show up so you can, well, reset the encryption token if needed.

This token is generated on a cycle, but there are potential cases where they become desyncronized.

Are you seeing a problem or just reporting something that was noticed?

@zzeuss1969 normally unable to find image store means the file/folder of that image does not exist. Can you check the image path in the Ui and verify that path exists on the fog server? Most likely it could be multiple things but based on what I can tell, it’s mounting nfs just fine, so I suspect a few things , image store (typically /images) does not have the folder and files for that image, or what you have as the “new” store is not being shared by the fog server.

@mmoore5553 We dont’ ahve any information, examples of the problem, anything beyond “What’s the issue”

Please provide more information as you have already clearly stated that there’s nothing that seems to be wrong with FOG at all, but rather something specifica to VM Workstation 17.

I don’t know what VirtualBox extensions have ot do with this, but Omnissa is it’s own thing (was VMware).

We don’t know what you’ve tried, if you’ve tried back with Workstation 16 and all works? You have just said “something’s broke, what is it?”

@rogalskij What you’re seeing is a list of all available kernels for download. The on that’s installed is the currently full release one. I don’t know which version that iss off the top of my head, but I believe it’s the October 14, 2025 at this point.

@rogalskij I believe this is expected to be honest.

The kernel version these are based off of is “Linux Kernel 6.12.35”

The date is when the FOS side built that specific kernel with whatever changes.

@Clebboii https://wiki.fogproject.org/wiki/index.php?title=Troubleshoot_MySQL#Database_Maintenance_Commands

Please see if this helps? Specifically the task related items. Sometimes stale (old/bad items suddenly show up from long ago.) admittedly I’d love to know what caused (or causes?) this but it has so far eluded me this far.

@chevengur The flag is onDemand -> 0 = No, 1 = yes.

@chevengur I believe you just check the box for perform immediately and dont’ define anythign against the cron side of things.

@AlexisPHC I’m hesitant to add such a feature.

While I can definitely see the appeal, I almost think this would be better as a plugin rather than an OOB nature of FOG as we’ve been around doing Quick Reg for quite a long time.

Now could this have been requested in the past and just missed? Absolutely.

I still think I would envision this type of thing more as a plugin (maybe even separating Quick registration as a whole) as a plugin.

Why?

All the features FOG does provide out of the box is quite extensive and difficult to manage at the best of times.

Now as to why quick reg, in it’s current state, is included in the baseline FOG? Because it’s more than just the UI interactions but also the FOS side of the house.

So the way Quick reg exists today in the FOS/UI would likely remain as is. As for adding new features? I think this is the part where it can be incorporated completely separate from the UI/FOS side as a plugin.

I have to think about how it could be done, but just wanted to give a base line thought process I have going on.

(Seeing at least what you’re requesting is more about the PHP side of things and managing them - including beign able to more generalize what kind of key flags could be used to name the device - more than just SYSSERIAL for example.)

Sorry for the bit of ramble, just the thoughts as I see them.

@AlexisPHC Ha, I’m faster than most would expect. lol