Problem resizing partitions on install



  • Server
    • FOG Version: 1.3.5
    • OS: Centos7
    Client
    • Service Version:
    • OS:
    Description

    There is an error when I try to deploy a image to a computer with a smaller HD than the one used to capture the image (280GB). I have tried with two different computers with 80GB and 180GB HD, with same error.

    Here is a capture of the error screen in the 80GB HD:
    0_1490186188853_20170322_123253.jpg

    And the contents of the image files:
    d1.minimum.partitions
    label: dos
    label-id: 0x849ae652
    device: /dev/sda
    unit: sectors

    /dev/sda1 : start= 2048, size= 79872, type=7, bootable
    /dev/sda2 : start= 2923520, size= 52866560, type=7
    /dev/sda3 : start= 155704320, size= 308224, type=7

    d1.partitions
    label: dos
    label-id: 0x849ae652
    device: /dev/sda
    unit: sectors

    /dev/sda1 : start= 2048, size= 2921472, type=7, bootable
    /dev/sda2 : start= 2923520, size= 152780800, type=7
    /dev/sda3 : start= 155704320, size= 821068288, type=7



  • @Tom-Elliott Understood ;) I will probably do a custom report to have the information about the images and their partition layout. Thank you again!


  • Senior Developer

    @michelsantana The partition data is stored in the DB. The Fixed size partitions, ideally, should not be editable really. Being able to edit manually is “useful” but ultimately just a bandaid.

    Hopefully editing this file will no longer be needed.

    That said, you should not have needed to recapture the image for the fix to work, but glad that it did work for you.



  • @Tom-Elliott Applied the patch, captured the image from a 300GB HD and ended with this parameters:
    d1.partitions
    label: dos
    label-id: 0x849ae652
    device: /dev/sda
    unit: sectors

    /dev/sda1 : start= 2048, size= 2921472, type=7, bootable
    /dev/sda2 : start= 2923520, size= 286721536, type=7
    /dev/sda3 : start= 289645056, size= 335495680, type=7

    d1.minimum.partitions
    label: dos
    label-id: 0x849ae652
    device: /dev/sda
    unit: sectors

    /dev/sda1 : start= 2048, size= 60416, type=7, bootable
    /dev/sda2 : start= 2923520, size= 53114368, type=7
    /dev/sda3 : start= 289645056, size= 235008, type=7

    Then I deployed the image in debug mode to a 80GB HD. The captures of the partition process (deploy in debug mode)

    0_1490279431919_Captura de pantalla 2017-03-23 a las 14.06.55.png
    0_1490279441439_Captura de pantalla 2017-03-23 a las 14.07.23.png
    0_1490279448602_Captura de pantalla 2017-03-23 a las 14.07.42.png

    There were no errors and seems that everything is working fine. Finally I’ve got three partitions with the right proportions (338MB, 36,69GB and 42,93GB).

    Thank you very much for your help!

    P.S.
    I would be great in future releases to have information about the partition layout of the images in the “Image Management” section, and also to have the possibility of fixing the size of one partition there, without the need of editing the file d1.fixed_size_partitions


  • Senior Developer

    I’ve made a modification to how to implement a bit more properly.

    Mind trying it?

    wget -O /var/www/fog/service/ipxe/init.xz http://mastacontrola.com/init.xz
    wget -O /var/www/fog/service/ipxe/init_32.xz http://mastacontrola.com/init_32.xz
    

  • Senior Developer

    @michelsantana Fixing the partition would work. As I said earlier, however, I’m going to try to figure out a way to know the “minimum” size as well as the “original” size. It may be a bit before I have a method that will work.

    One of the problems I foresee, is because of the “percentage” handling. This is always “possible” even if the disk is larger than the “size” required. Having a nice mechanism to ensure the size will at least be as large as the size needed for a partition would be a better route, I think.

    This can work now, of course, but only if you don’t mind losing the “scaling” capabilities.



  • @Tom-Elliott That is exactly what happens. Now I’m trying to deploy the whole image into the computer with 80GB disk fixing the size of the second partition and then resize the partitions and capture again from that computer. That should guarantee that this deployment will work in disks of at least 80GB and above.
    I will post the results.

    Thank you



  • @Tom-Elliott Exactly. Partclone starts and deploy the first partition, but when it tries to deploy the second, throws the error.


  • Senior Developer

    So to understand what’s happening.

    Resizing works on this formula (now)

    Take the original partition information (d1.partitions).
    Figure out the original partition sizes and gather the percentage of difference between partitions.
    Take the new disk size information.
    For each resizable partition resize by the percentage gathered earlier.

    In your case

    Partition 1 was originally:
    1495793664 bytes or about 1.5 gb.
    Partition 2 was originally:
    32325509120 bytes or about 32.3 gb.
    Partition 3 was originally:
    286247969280 bytes or about 286 gb.
    In total your disk was:
    320070320640 or about 320 gb.


    The resizing structure in percentage of use is

    Partition 1:
    0.4% the size of the original disk approximately.
    Partition 2:
    1.0% the size of the original disk approximately.
    Partition 3:
    89.4% the size of the original disk approximately.

    Taking this into consideration for the “smaller” drives:

    Partition 1 is being set to:
    373817344 bytes or approximately 370 mb – far smaller than the original. This is fine as the minimal space needed for the partition is 30932992 bytes or approximately 30mb.
    Partition 3 is being set to:
    71568982016 bytes or approximately 71 gb – far smaller than the original. This is fine as the minimal space needed for the partition is 133693440 bytes or approximately 133 mb.
    Total disk size is 80026009600 bytes or approximately 80 gb (based solely on the pictures you’ve provided at least.)

    Below is the portion of what you’re seeing as failing.

    Partition 2 is being set to:
    8082136064 bytes or approximately 8.0 gb – far smaller than the original but also smaller than the minimal space needed which is 27034386432 bytes or approximately 27 gb.

    Hopefully this helps clarify what you’re seeing. This isn’t a bug (persay) but I will see if there’s a way for me to more appropriately pull in the information as it “should” not care as long as there’s enough space to place the data. in the mean time, you might want to make partition 2 a “fixed” size partition. Making it a fixed size partition will not make the disk scale appropriately though. While the 80gb would work fine, at a disk size of around 64gb (in this case) the last partition would end up being equal or smaller to the second partition.


  • Senior Developer

    @michelsantana Very good information. Thank you. So to clarify, as you’re not the first to have the error, partclone IS indeed running, but before it can complete the tasking it throws the error in the last picture, correct?



  • In order to clarify if it’s a normal behaviour or a bug, I have repartitioned and checked the partition schema and sizes of the partitions.
    The starting point is a computer with a 298GB HD with three primary partitions:
    sda1: NTFS, System Reserved. Size: 1,38GB
    sda2: NTFS, Boot. Size: 30,11GB with 3,74GB free space
    sda3: NTFS. Size: 266,59GB with 266,43GB free space

    After doing a “sysprep”, I captured the HD with fog and this are the content of the config files in the image directory:
    d1.partitions
    label: dos
    label-id: 0x849ae652
    device: /dev/sda
    unit: sectors

    /dev/sda1 : start= 2048, size= 2921472, type=7, bootable
    /dev/sda2 : start= 2923520, size= 63135760, type=7
    /dev/sda3 : start= 66059280, size= 559078065, type=7

    d1.minimum.partitions
    label: dos
    label-id: 0x849ae652
    device: /dev/sda
    unit: sectors

    /dev/sda1 : start= 2048, size= 60416, type=7, bootable
    /dev/sda2 : start= 2923520, size= 52801536, type=7
    /dev/sda3 : start= 66059280, size= 261120, type=7

    When I try to restore this image into a computer with a smaller HD (80GB) that should be enough to fit the three partitions, it gives me the same error.

    I made the deployment as a debug task and using the “ismajordebug=1” kernel argument. Here are the screen captures:
    0_1490200550838_20170322_163036.jpg

    0_1490200628535_20170322_163105.jpg

    0_1490200638049_20170322_163129.jpg

    0_1490200646766_20170322_163203.jpg

    I hope this helps to clarify what is happening. Let me know if you need more tests.

    Thank you very much



  • @Junkhacker @Tom-Elliott Now I’m rebuilding the whole partition schema in order to have all the information detailed. I will post it in less than an hour.

    Thank you


  • Developer

    could you tell us more about how the partitions are laid out? which ones are restore/recovery/system/efi partitions?


  • Senior Developer

    I don’t see how this is a bug.

    Your minimum partitions second partition appears to be 270 gigs? Maybe my math is off as I’m stuck to a cell phone.


Log in to reply
 

333
Online

38727
Users

10554
Topics

99920
Posts

Looks like your connection to FOG Project was lost, please wait while we try to reconnect.