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

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

[Sebastian Roth]

@rboan Bump…

[Sebastian Roth]

@rboan Bumping again…

[caw001]

@sebastian-roth I work with Robyn. This looks good. We are now able to boot and capture images. We are just having trouble restoring them back to drives of a larger size. I don’t see that covered in your guide anywhere unless I missed it. We are still continuing to test… But don’t don’t really have a resolution yet.

[Sebastian Roth]

@caw001 said in Image file does not "expand" the full size of the drive it is being deployed to:

We are just having trouble restoring them back to drives of a larger size. I don’t see that covered in your guide anywhere unless I missed it.

Well I don’t have a ready solution for you guys yet. We are in the process of helping you to find and fix this issue. Last @rboan posted was a screenshot with the error message “Invalid OS ID (0) (determineOS)” and so I answered:

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.

I still want to help you guys and need more information to be able to do so.

[caw001]

@sebastian-roth Sorry, just spoke to her. (She’s working on trying our Mac capture at the moment). The issue she was experiencing at that moment was because she had no selected the OS type when setting up the capture. Once she did that we were able to successfully capture and image. That’s when we ran into the issue of restoring the image back to a larger disk and it not expanding to the full size.