FOG Not resizing partitions

[Tom Elliott]

@Derek-Newbold The most immediate thing I see is the “minimum” d1.minimum.partitions) and “original” (d1.partitions) are identical. There’s nothing to base “resizing” off of. Was the originally captured image captured in a “broken” version of resizing?

[Derek Newbold]

@Tom-Elliott Sorry my technical knowledge on this is limited. I usually take a VM snapshot of the image before capturing so that I can revert to the snapshot if I want to make further changes and then snapshot/sysprep/capture it again. Due to this process as far as I know the VM should not be in a “broken” state.

It was all working with this image up until the latest capture which I done after upgrading FOG. Maybe something broke in the last capture, would you like me to go through the process to capture it again and take some screenshots?

I don’t mind if it doesn’t shrink the image any further as I’ve made it smaller than any of our HDD’s in our hosts, all I need it to do is to expand the image to use all the disk space of the destination host like it used to.

[Tom Elliott]

@Derek-Newbold what’s in the d1.fixed_size_partitions file?

[Derek Newbold]

@Tom-Elliott I think I had that in my previous post? However I’ll post it here again for you, I assume this is what you are after? To me it looks like it shouldn’t have the ‘:2’ in it however I’m not sure how to fix that?

administrator@NHS-FOG-01:/images$ cat /images/ADOBEIMAGEWIN7/d1.fixed_size_partitions
:1:2

[Sebastian Roth]

@Derek-Newbold Sorry for not getting back any earlier. As I see it the issue is that with the new version of FOG (at least in your case, don’t think this applies to everyone!) does see both partitions (sda1 and sda2) as fixed size. So surely it won’t deploy to a smaller disk and neither would it expand on a bigger disk. So if you change d1.fixed_size_partitions by Hand and just make it read 1 (no space or colon or anything else in that one line) then I am pretty sure it will work as expected.

Now why doesn’t it generate d1.fixed_size_partitions properly? The only thing I can think of is you are seeing this message when capturing: New fixed partition for (/dev/sda2) added.. This is because this partition is labeled as RECOVERY or RESERVED for an unknown reason. Please check in the windows disk management tool. Usually those labels not used for the C:\ (system) partition and we use those to detect so called “boot” or “recovery” partitions.

[Tom Elliott]

@Sebastian-Roth To add on, I think removing the 2 from the file will certainly help (at least in getting to to expand to larger disks).

[lmioperations]

@derek-newbold This likely has nothing to do with the issues you’re having, but you might want to consider this workflow instead:

You have a base guest VM that you build out with everything you want it to have, then once you have it where you like it, you create a snapshot.

Anytime you need to capture this guest VM, you first create a clone of it. Then you finish up whatever else you need to do to the cloned VM before sysprep’ing and capturing it.

Anytime you need to add/change something in the base VM, you do so, then verify if everything is still good with the base. If so, you delete the snapshot to permanently commit the changes, then create a new snapshot.

[Derek Newbold]

Hi Sebastian,

Thankyou for your reply. This makes sense to me, I have checked the partitions and the ‘C:’ partition has the label ‘Boot’ so I assume that is why it is being detected as not resizable (see screenshot below). Would it be advisable to try and change the boot partition to be on the ‘System Reserved’ partition instead if possible? Or just continue with the manual fix that you mentioned?

Also I tried manually changing ‘d1.fixed_size_partitions’ to just have ‘1’ and then reimaged a host, this time it tried to resize the ‘sda2’ partition however it failed and came up with ‘Cluster accounting failed’ errors and that ‘NTFS is inconsistent. Run chkdsk /f’. Do you have any advice on what might cause this and how I can stop it from happening? Again, I had no problems with the old version of FOG doing the same processes so I’m unsure what is causing these issues.

Thankyou again,

Derek

[Sebastian Roth]

@Derek-Newbold Please read through this https://wiki.fogproject.org/wiki/index.php?title=Windows_Dirty_Bit and make sure you to a proper filesystem scan in windows (jst as the message suggested). Then capture the image again and try deploying it!

[Tom Elliott]

Then you might want to get on 1.4.4 and try again. I suggest this as there was a bug in init’s moving the start position of the next partition improperly. 1.4.4, we believe, fixed this.

[Tom Elliott]

@derek-newbold What’s interesting, to me however, is your partclone shows SDA2 as being 23.4GB partition, but the windows image shows the drive as being a 100mb reserved partition. Is the partition 2 in the d1.fixed_size_partitions file.

[Sebastian Roth]

@tom-elliott said in FOG Not resizing partitions:

What’s interesting, to me however, is your partclone shows SDA2 as being 23.4GB partition, but the windows image shows the drive as being a 100mb reserved partition. Is the partition 2 in the d1.fixed_size_partitions file.

Windows disk management does not show the partitions in order in that list (which is super stupid I find)…

[Derek Newbold]

@sebastian-roth I finally got around to trying this out the other day and after running a check disk and recapturing the image it is now resizing the partitions correctly upon deployment. I didn’t have to modify the ‘d1.fixed_size_partitions’ again so I’m assuming that the capture process either worked correctly after running check disk, or else it just continued to use my modified version of that file.

Thanks for your help in resolving this issue everyone, much appreciated!