Image file does not "expand" the full size of the drive it is being deployed to
-
for clarification, I chose “Single disk - resizable”
-
@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.
-
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
-
@caw001 I’m currently looking at a 7280 I deployed this AM to see if it is also impacted.
-
@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.
-
@george1421 Interesting. Ours are also EUFI I believe. Current model HP ProBook 640.
Does the boot type matter? Legacy vs EUFI?
-
@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.partitionsFrom the image directory on the fog server. There has to be something unique here we can feed to the developers.
-
It might be related to 4k sector sizes…
-
@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) -
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.
-
@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.
-
@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.
-
Tom will also have a 4K drive soon.
-
I booted in debug mode and ran the command fdisk -l /dev/nvme0n1
Below are screenshots of output
![1_1506439862790_2.jpg](Uploading 100%) ![0_1506439862789_1.jpg](Uploading 100%) -
@rboan Seems like yout pictures did not upload properly. Please try again.
-
-
@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. -
@rboan Bump…
-
@rboan Bumping again…
-
@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.