@Sebastian-Roth
No no, you’ve made clear that it is a lost cause trying to sort this out. If I had a clean capture and deploy on this version showing the system partition shrinking it would be different. Your comments made that clear. Thanks for the help.

@Sebastian-Roth
Good points.
I haven’t kept logs that would detail which version of fog I was on. It could be that the drive was initially that size when captured, but that is an odd number (37MB). This particular image has probably been deployed, updated, used, and recaptured meaning it has been passed through various versions of fog. This is surely asking for it, but I’ve yet to find a workstation backup method that gave me the fuzzies.

Just to be clear, as I’ve not fiddled with these files directly before, we are talking about image files from a host previously captured? Further, entering “:1” in this image file means that, upon deployment, it will inflate the first partition to it’s original (at time of capture) size?

I can’t seem to search the forums (404?) so I’m, just posting today’s fun.
edit: search works again, yet I’m not sure I want to delete the post

I tried to upgrade a deployed drive image from win10: 1803 to 1809 today. It told me my system partition was too small. Well it was quite small at 37MB. I’m guessing it was shrunk from the typical 100MB on capture and not inflated at deployment, but I can’t be sure. At any rate, the ensuing resize/raw FS/convert-to-NTFS fun landed me back at a redeployment of the same image that produces the small system partition.

Maybe I’ve missed the setting, or I’m using FOG in an A-typical way, but this could be an issue for quite a few.

If anyone has any thoughts on how to avoid/remedy the issue, I’d be happy to hear it.

@Zerpie
I know it doesn’t directly address your issue; forgive me.

Hardware raid cards are pretty darn cheap (used server pulls etc). Have you ever tried to rebuild one of those fakie raids? I’ve seen really poor results when it actually comes down to rebuilding a mirror, and the performance of general use is garbage.

I agree. Fog should tell you “these images won’t really be deleted, I’m just going to pretend… you’ll need to ssh in and clean up”

I revived this thread, because I’m seeing this issue. I see other threads saying it works, but I am on
FOG 1.5.4 kernel 4.18.3 and have to ssh to actually delete the files.

@george1421

I consider it resolved. Thanks for chiming in.

@george1421

I feel like a bit of a dummy. It works now, and I suspect I just needed to run the “chkdsk /f” from prompt instead of what I figure is the less thorough one from disk properties. For completeness I’ve included what didn’t work.

Nice thought, but the thread you note doesn’t hold my solution.
https://forums.fogproject.org/topic/10824/image-upload-deploy-taking-a-long-time/43
Bit locker is off as evidenced by the encryption control commands.
manage-bde -off C:
manage-bde -status C:

“Way 1” from the FOG wiki made no change either.
https://wiki.fogproject.org/wiki/index.php?title=Windows_Dirty_Bit

I believe command prompt “chkdsk /F” corrected the issue. I had previously just used disk check from disk properties, which doesn’t lock the drive. This was, however, in conjunction with a bios setting dealing with power saving that was causing hangs.

It sounds like your VM handler doesn’t know how to boot off PXE. I had to fiddle with VBox some to find the right NIC settings, but I was able to PXE boot VBox eventually. If your physical boxes can do it, FOG would seem to be up and functional.

I’ve captured most of the boxes around the house, but a couple of them don’t appear to resize. FOG tells me I’m capturing 232GB images.

During capture the bar says it is basically done at 122GB.

Image lists show it at 232GB

The folder shows something like 42GB

I’ve run cleanup, chkdsk, & defrags. These boxes aren’t encrypted.

Any tips to get these to behave/report properly?