Fog Server won't shrink partition

[Anieto93]

I keep trying to capture an image with my fog server. But the image size matches the size of the partitions on the disk. I have verified bitlocker is off, I have the image set as single disk-resizable. While capturing the image, it does see the correct amount of space in use and the correct amount of free space yet it seems to capture the entirety instead of shrinking the partition to the space just used. What can I check for? Is there a setting I’m missing? Editing to add that I am using version Fog vers 1.5.9 and the image I’m capturing is a station using windows 10 build 21h2

[george1421]

@anieto93 When you are capturing the image, in the partclone screen see if it say RAW when cloning the C Drive partition. If it does then bitlocker is enabled for free space on the drive.

You can double check to see / turn it off with this command

Open command prompt as admin.

manage-bde -off C:

manage-bde -status C:

[Anieto93]

@george1421 It does not say raw. It does recognize the file system as NTFS!

[george1421]

@anieto93 OK at least we’ve identified that its not bitlocker causing the issue.

Ah OK you’ve hit the other issue with windows. As of 20h2 microsoft changed the disk structure that prevents FOG from shrinking the partitions.

If you are willing to switch over to the dev branch then that will bring your fog install to 1.5.9.110 or later that has the fix in it for 20h2 and later OS. I’m not sure if it addresses this issue, but it WILL address an issue with the ability to shrink the disk before image capture.

To switch to the dev branch change into the directory you cloned with git. Typically /root/fogproject.

cd /root/fogproject
git pull
git checkout dev-branch
git pull
cd bin
./installfog.sh

When fog 1.5.10 is release in a few weeks you will need to switch your repository back to the main branch

cd /root/fogproject
git pull
git checkout master
git pull
cd bin
./installfog.sh

[Anieto93]

@george1421 Ah ok. I will switch to the dev on and let you know how it goes

[Anieto93]

@george1421 It seems this did not resolve the issue. The image is still capturing as I type this but it is still showing 19.703 of 465.215. Which usually means the end size on client will be 465.215.

[george1421]

@anieto93 Interesting.

When the image capture completes, what does disk manager say about the partition layout. If its capturing in ntfs mode it should be able to shrink the partitions unless there is something strange going on.

Did you try the manage-bde commands?

In the long run running 1.5.9.110 or later is a good thing. Side note you might want to update the kernel to 5.10.x again because 4.9.65 will be reinstalled when the installer runs. FOG 1.5.10 will come with 5.15.x (latest LTS build of the linux kernel) when its released.

[Anieto93]

@george1421 I did try the manage-bde commands before creating this thread as I saw it in other threads and was hoping that would be my issue. In the screenshot I provided, you can see that not only is it capturing it in NTFS, but that it properly reads how much of the partition is in use and how much is free space.

Edit: I should mention that I ran disk check and disk defrag before taking the image.

[george1421]

@anieto93 Lets post what the disk structure looks like with a screen shot from windows disk manager.

Also from the FOG server in the image directory of the captured host. What is the contents of the d1.partitions file. We may need to get a developer involved with this discussion because everything sounds like it should be working.

[Anieto93]

Hey, sorry for not replying. We ended up going through and trying to clone pcs until we found one that would properly shrink the partition. So we did confirm the issue was on the stations we were trying to clone. We used that station to remake all our images and are good to go now. We didn’t however find out what it was on windows that was causing them to be unshrinkable.

[george1421]

@anieto93 There was a fixed that was pushed out just recently in FOG 1.5.9.120 (or later that should also address this). Starting with FOG 1.5.9.110 in the dev branch that fixed an issue that existing in FOG 1.5.9GA towhere MS changed the disk structure in Win10 20H2 that caused the disk to not expand correctly. It was that small recover partition that was keeping the drive from expanding. Removing the recovery partition fixed the issue with 1.5.9GA. There was a workaround for the change added to FOG 1.5.9.110. And now a new issue was fixed with resizing with 1.5.9.120 but I don’t know the details with that.

I’m glad you have it sorted out before the fix was published.