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



  • 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?


  • Developer



  • @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.


  • Developer

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



  • @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.


  • Developer

    @rboan Bumping again…


  • Developer

    @rboan Bump…


  • Developer

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



  • 1_1506440119351_2.jpg 0_1506440119350_1.jpg


  • Developer

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



  • @sebastian-roth

    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%)



  • Tom will also have a 4K drive soon.


  • Moderator

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


  • Developer

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


  • Moderator

    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.
    

  • Developer

    @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)



  • It might be related to 4k sector sizes…


  • Moderator

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



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

    Does the boot type matter? Legacy vs EUFI?


  • Moderator

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


 

440
Online

41.9k
Users

12.4k
Topics

116.7k
Posts