FOG Not resizing partitions

[Derek Newbold]

Server

• FOG Version: 1.4.3 SVN Revision 6075
• OS: Ubuntu 16.04

Client

• Service Version: 0.11.12
• OS: Windows 7 Enterprise Service Pack 1 64bit

Description

I have recently upgraded our FOG from 1.2.0 to 1.4.3 and also updated the client on my Windows 7 image. My image from before the upgrade was set to ‘Single Disk - Resizable’ and when capturing the image it used to resize the main partition (C:) to as small as possible, and then when deployed it would resize it again to use all the space on the destination host.

Now since the upgrade I tried to deploy the image to a computer that had a smaller hard drive (128GB) than what I had set on the VM that I created the image on (140GB capacity, approx 80GB used). The imaging failed basically saying that the destination host drive wasn’t large enough, however it was never a problem before due to FOG resizing/shrinking the C:\ parition before capturing it.

So as a test I shrunk the partition in Windows to about 100GB and recaptured the image. The image now deploys to the computer with the 128GB drive however it is not resizing the C:\ partition (or any other partition) to use up any free space on the drive.

I hope this all makes sense, does anyone have any suggestions on what is causing this behavior and how to fix it?

Thankyou in anticipation!

[Sebastian Roth]

@Derek-Newbold Please douple check that image is still set to resizable (and OS ID to windows 7)! When it deploys (and on upload) do you see messages on screen that say something about resizing - it should! Please give us more information about the image files stored on your FOG server.

ls -al /images/<IMAGENAME>
cat /images/<IMAGENAME>/d1.fixed_size_partitions
cat /images/<IMAGENAME>/d1.partitions
cat /images/<IMAGENAME>/d1.minimum.partitions
cat /images/<IMAGENAME>/d1.original.fstypes

Run all those commands (replace <IMAGENAME> with the real name of your image name) and post the full text output or a picture here!

[Derek Newbold]

Hi Sebastian,

Thankyou for your prompt reply, and for helping with this problem. Sorry about the delay in getting back to you, I’m from Australia so there is probably some time difference!

I have gathered all the information you have asked for and attached it to this post except for screenshots of capturing the image. Please let me know if you can see anything from this information or whether you need me to recapture my image again to take some screenshots of the capture process.

I have also checked that the image is set to resizable and OS ID is set to Windows 7 (as you can see in my screenshot). I assume this is all correct?

administrator@NHS-FOG-01:/images$ ls -al /images/ADOBEIMAGEWIN7
total 79658372
drwxrwxrwx  2 root root        4096 Jul 21 22:28 .
drwxrwxrwx 16 fog  root        4096 Jul 21 22:28 ..
-rwxrwxrwx  1 root root           5 Jul 21 21:56 d1.fixed_size_partitions
-rwxrwxrwx  1 root root     1048576 Jul 21 21:56 d1.mbr
-rwxrwxrwx  1 root root         190 Jul 21 21:56 d1.minimum.partitions
-rwxrwxrwx  1 root root          15 Jul 21 21:56 d1.original.fstypes
-rwxrwxrwx  1 root root           0 Jul 21 21:56 d1.original.swapuuids
-rwxrwxrwx  1 root root    25477300 Jul 21 21:56 d1p1.img
-rwxrwxrwx  1 root root 81543607445 Jul 21 22:28 d1p2.img
-rwxrwxrwx  1 root root         190 Jul 21 21:56 d1.partitions


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


administrator@NHS-FOG-01:/images$ cat /images/ADOBEIMAGEWIN7/d1.partitions
label: dos
label-id: 0xf8268334
device: /dev/sda
unit: sectors

/dev/sda1 : start=        2048, size=      204800, type=7, bootable
/dev/sda2 : start=      206848, size=   204800000, type=7


administrator@NHS-FOG-01:/images$ cat /images/ADOBEIMAGEWIN7/d1.minimum.partitions
label: dos
label-id: 0xf8268334
device: /dev/sda
unit: sectors

/dev/sda1 : start=        2048, size=      204800, type=7, bootable
/dev/sda2 : start=      206848, size=   204800000, type=7


administrator@NHS-FOG-01:/images$ cat /images/ADOBEIMAGEWIN7/d1.original.fstypes
/dev/sda2 ntfs

[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!