Manipulating Partition Sizes of Captured Image For Deployment

[sudburr]

Server

• FOG Version: RC10 or higher
• OS: CentOS_7.2.1511

Client

• Service Version: n/a
• OS: any Windows 10 version

Description

An original Windows 10 installation with a WinRE partition is on a 256 GB HDD consisting of 3 partitions

1= 260 MiB (EFI System Partition)
2= 236 GiB NTFS (Boot, Page File, Crash Dump, Primary Partition)
3= 1000 MiB (Recovery Partition)

Without rebuilding the install is there a way to massage the captured image files to be able to deploy onto a different size HDD (eg: a smaller 128 GB) that maintains the sizes of partitions 1 and 3, but resizes partition 2 to fill the available remaining (larger or smaller) space?

The original was captured as Single Disk Resizable.

[Tom Elliott]

Is partition 2 not already resized?

[sudburr]

Partition 2 resizes, but so does Partition 3. I don’t want Partition 3 to resize, only Partition 2.

Correct me if I’m wrong, but as I understand the Windows 10 Recovery Environment partition as the operating system receives major updates, it also updates the Recovery Partition.

When FOG deploys the image it resizes partition 3 unacceptably smaller. I want to maintain the original size of the WinRE partition.

[Tom Elliott]

@sudburr We don’t know what partition will become the recovery partition, not in the least.

That said, if you alter the d1.fixed_size_partitions file and add the partition number you need to be fixed, (additionals are separated by colons) you should be good.

For example:

d1.fixed_size_partitions might have: 1:3 meaning partitions 1 and 3 must be of a “fixed” size.

[sudburr]

Interestingly, the d1.fixed_size_partitions file contains:

1:2:1

A second :1 ?

Looking closer at the original drive, there are actually 4 partitions.

1 System 260 MB
2 Reserved 16 MB
3 Primary 240 GB
4 Recover 1000 MB

Hmm.

For now I will try a deployment with 1:2:1:4 and see what happens; while I furrow my brow at that mystery `Reserved’ partition.

[Tom Elliott]

@sudburr You can remove one of the 1’s. This image was likely created semi-fairly in the past?

[sudburr]

The image was created September 28th with RC10.

[sudburr]

How does FOG determine if a partition is resizable when it is capturing? Is it strictly a file system match or does it look at the partition’s flag or type?

[sudburr]

I just captured the original drive with RC13 and it again generates a d1.fixed_size_partitions with:

:1:2:1

[Tom Elliott]

@sudburr That’s not the end of the world.

Basically anything before the “main” partition is calculated as fixed. Also, an partition that is not of a resizable type (ext or ntfs) will be listed in there.

[sudburr]

The original HDD as reported by Gnome Partition Editor 0.26.1-5:

Partition | Name | Label | File System | Flags
/dev/sda1 | EFI system partition |  | fat32 | boot, hidden, esp
/dev/sda2 | Microsoft reserved partition |  | unknown | msftres
/dev/sda3 | Basic data partition | Windows |ntfs | msftdata
/dev/sda4 | Basic data partition | WinRE_DRV |ntfs | hidden, diag

Editing d1.fixed_size_partitions of the captured image to be:

:1:2:4

… then deploying the image to a smaller HDD results in this:

* Attempting to expand/fill partitions ... Done
* Seems like you are trying to restore to an empty disk.  Be aware this will most probably cause trouble.

Attempting to deploy image
Using Partclone

An error has been detected!

No image file(s) found that would match the partition(s) to be restored (performRestore>
Args Passed: /dev/sda /images/test all

Computer will reboot in 1 minute

Deploying the same image to a larger (500 GB) HDD results in:

Partition | Name | Label | File System | Flags
/dev/sda1 | EFI system partition |  | fat32 | boot, esp
/dev/sda2 | Microsoft reserved partition |  | unknown | msftres
/dev/sda3 | Basic data partition | Windows | ntfs | msftdata (still shrunk at 25.4 GB)
unallocated (211.82 GB)
/dev/sda4 | Basic data partition | WinRE_DRV | ntfs | hidden, diag (correctly sized to 1000 MB)
unallocated (227.29 GB)

GParted initially launches with this error:

Not all of the space available to /dev/sda appears to be used, you can fix the GPT to use all of the space (an extra 2014 blocks) or continue with the current setting?

Selecting FIX or IGNORE doesn’t change the partitions.

So it more or less mirrored the original 256 GB HDD layout onto the 500 GB HDD leaving the extra space after sda4 empty, instead of dumping sda4 onto the end of the space, then expanding sda3 into the donut hole.