partition shrink, no margin on C: after deploy



  • Hello,
    Working on 1.5.7.55 version, I have a problem using single disk -resible image.
    Working from a 250Go master with 34.1Go πŸ˜„ partition.
    Deploying on a 55Go VM for test, I get a full πŸ˜„ partition on deploy.
    I di not see any error during capturing and deploying

    Here are the defintion files of the image :

    cat win10light-1903/d1.fixed_size_partitions
    1
    
    cat win10light-1903/d1.minimum.partitions 
    label: dos
    label-id: 0x17fda016
    device: /dev/sda
    unit: sectors
    
    /dev/sda1 : start=        2048, size=     1021952, type=7, bootable
    /dev/sda2 : start=     1024000, size=    34329556, type=7
    /dev/sda3 : start=    76800000, size=      112166, type=7
    
     cat win10light-1903/d1.original.fstypes 
    /dev/sda2 ntfs
    /dev/sda3 ntfs
    
    cat win10light-1903/d1.partitions 
    label: dos
    label-id: 0x17fda016
    device: /dev/sda
    unit: sectors
    
    /dev/sda1 : start=        2048, size=     1021952, type=7, bootable
    /dev/sda2 : start=     1024000, size=    71680000, type=7
    /dev/sda3 : start=    76800000, size=    38541312, type=7
    

  • Moderator

    You have 2 resizable partitions.

    FOG attempts to maintain the percentage that those partitions take up for its resize logic.

    So, because your 2nd partition is approx 53% of πŸ˜„ it will attempt to organize the partitions as such on deployment too.

    But since your πŸ˜„ partition needs a minimum of 34GB of 55GB to function, that means that approx 62% is already taken up, forcing the system to allocate whatever remains to the other partition (D: presumably) to make sure it’s more or less the expected outcome.

    In other words; you need to either make the 2nd partition smaller before capture or deploy to a larger disk.



  • @Quazz
    Thank you for your answer, I did not know that deployed partitions were prorated to captured partitions.
    It’s clear for me now


  • Moderator

    You have 2 resizable partitions.

    FOG attempts to maintain the percentage that those partitions take up for its resize logic.

    So, because your 2nd partition is approx 53% of πŸ˜„ it will attempt to organize the partitions as such on deployment too.

    But since your πŸ˜„ partition needs a minimum of 34GB of 55GB to function, that means that approx 62% is already taken up, forcing the system to allocate whatever remains to the other partition (D: presumably) to make sure it’s more or less the expected outcome.

    In other words; you need to either make the 2nd partition smaller before capture or deploy to a larger disk.


Log in to reply
 

323
Online

7.5k
Users

14.6k
Topics

137.4k
Posts