Image file does not "expand" the full size of the drive it is being deployed to

[rboan]

I am creating a Win10 universal image for the 3 laptop models at work. I created the original Master image on a drive that has 3 partitions:
(1- system reserved 500Mb)
(2- boot OS partition 500Gb)
(3- Recovery partition 4.65Gb)

I chose the first option for type --> Single partition/single drive so it was expandable --> image file size approx. 22 Gb

---

When I deployed this image to a second laptop with original 3 partitions:
(1- system reserved 500Mb)
(2- boot OS partition 220Gb)
(3- Recovery partition 4.65Gb)

The resulting drive size for the Boot OS partition is whatever the size of the image was (22 Gb is this case)
I see the rest of the drive in Device Manager as ~200 Gb UNALLOCATED

---

If I choose to capture my image on Laptop A (bigger hdd) as a Multi-partition Single Disk, I get a 500 Gb size image file and then it cannot deploy to my smaller drive (220Gb ) on Laptop B

If I choose to capture my image on Laptop B (smaller hdd) as a Multi-partition Single Disk, I get a 220 Gb size image file, it will deploy to Laptop A, HOWEVER, the Boot OS drive shows up as the size of the image file (220 Gb) and the rest is UNALLOCATED in Device Manager.

WHAT AM I DOING WRONG???

I want to image either/or as a, capturing all 3 partitions, creating an image file that is only the size of the actual data (22 Gb) and deploy it to other laptops that will have drive sizes from 200 Gb to 2 Tb - and show up as whatever size partitions it has expanded to 100%.

Is this possible?

[george1421]

well we need a bit more info here.

What version of FOG are you using?
What do you have configured for image type? Single disk resizable?

Don’t think about partitions here, think about disks unless you are trying to do something really strange with your imaging (we do have people that need that function).

[rboan]

I am running Fog version 1.4.4 on Ubuntu 16.04

My original image capture was configured for Single partition- resizable and it creates an image file the size of the data (e.g. 22Gb) which is ideal.

However this image, when deployed to a smaller hdd system, only creates the primary OS partition as the size of the data (22 Gb) and leaves the rest of the drive as unallocated space in disk manager

[rboan]

for clarification, I chose “Single disk - resizable”

[caw001]

@george1421 I am having the same issue. How do we get the image to deploy and utilize the full disk? I have a very similar disk setup. Standard Windows disk layout.

[x23piracy]

i am not sure but in the end of a deployment you will see a line in the shell like: expanding filesystem, this normally take some seconds or maybe 1 minute to finish depending on the drive, maybe you can look for this maybe it ends immediately or throws an error into the console.

Possibly my mind is sending me traps and i think about capturing where it also resizes the partition to its smallest possible size. Not sure

I capture with similar settings and all my images expand just fine, an example:

Only a thougth.

Regards X23

[george1421]

@caw001 I’m currently looking at a 7280 I deployed this AM to see if it is also impacted.

[george1421]

@caw001 On the uefi system I imaged this morning it did resize, but left 6GB of unallocated space.

Our reference images are built on a VM that has a 70GB hard drive. I deployed it to a 238GB NVMe drive. The boot and recover partitions were the original size and the C went from 68GB in the reference image to 235 on the target system. I don’t understand why it skipped the 6GB in its calculations for expansion.

[caw001]

@george1421 Interesting. Ours are also EUFI I believe. Current model HP ProBook 640.

Does the boot type matter? Legacy vs EUFI?

[george1421]

@caw001 It shouldn’t matter.

I’m pretty sure your situation isn’t unique (obviously because of this thread). We need to understand why some systems expand correctly and some don’t. I’ve got a meeting right now, but it may be useful to compare what you have in the following files.

d1.minimum.partitions
d1.fixed_size_partitions
d1.partitions

From the image directory on the fog server. There has to be something unique here we can feed to the developers.

[Wayne Workman]

It might be related to 4k sector sizes…

[Sebastian Roth]

@Wayne-Workman said:

It might be related to 4k sector sizes…

Good point. @caw001 Could you please schedule a debug task (upload or deploy doesn’t matter) on the destination host and run the following command when you get to the shell: fdisk -l /dev/nvme0n1 (take a picture and post here)

[george1421]

While this post is unrelated to the issue at hand, here is the output of the command Sebastian just posted. This is the output of my linux mint laptop running on a Sandisk x300 sata ssd. It does point out something interesting. Its a 4k physical drive that must support 512e because of the logical / physical mismatch. Also the second partition doesn’t start on a 4K boundary.

$ sudo fdisk -l /dev/sda
Disk /dev/sda: 232.9 GiB, 250059350016 bytes, 488397168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0xcb247ec0

Device     Boot     Start       End   Sectors  Size Id Type
/dev/sda1  *         2048 471818239 471816192  225G 83 Linux
/dev/sda2       471820286 488396799  16576514  7.9G  5 Extended
/dev/sda5       471820288 488396799  16576512  7.9G 82 Linux swap / Solaris

Partition 2 does not start on physical sector boundary.

[Sebastian Roth]

@george1421 Yeah you definitely have one of these 512e disks that still “emulate” being a 512 sector size disk. The second partition is just the extended partition container, so it doesn’t matter. Your SWAP at least is on a 2048 sector boundary so it’s not too bad at all.

I’ve looked into real 4096 sector disks and I am sure we need to tackle this as we’ll see more and more of those disks.

[george1421]

@sebastian-roth I’ll just mention this, I have several real 4Kn sata drives I could throw in a laptop if you needed to test something.

[Wayne Workman]

Tom will also have a 4K drive soon.

[rboan]

@sebastian-roth

I booted in debug mode and ran the command fdisk -l /dev/nvme0n1
Below are screenshots of output
 

[Sebastian Roth]

@rboan Seems like yout pictures did not upload properly. Please try again.

[rboan]

[Sebastian Roth]

@rboan Why do we see the “Invalid OS ID” now? Why 0 (zero)? Please check the image settings in the FOG web UI. As well please run fdisk -l in a debug task and hopefully we’ll see what disk you have.