restoring original partition layout in capture mode



  • Hi,
    I have the following issue when capturing an image. The original partition layout is not restored.
    I am capturing an entire disk 120gb
    dev/sda1 26GB (ext4)
    dev/sda2 swap ~1GB
    dev/sda3 93GB (ext4)

    Image Type is “Single Disk - Resizable”
    After capturing I can read:
    “Image captured
    Restoring original partition layout” which takes a while.
    After reboot I do a “df -h” which shows the first partition has shrunk to ~11GB, which is around 2GB more than the used space. Same for sda3.
    So for some reason the restoring of the original partitionlayout does not seem to work in capture mode.

    If I deploy that image back onto the machine, the part. layout is fine.

    As I am new to fog, my question is, is this default behavior, or did i miss sth. in the documentation? It is reproducable.
    I am using Fog 1.5.9-RC1


  • Senior Developer

    As I just stumbled upon this topic again I might update as well. This is fixed upstream and we already use the version fixed by buildroot in version 2020.02.2.


  • Senior Developer

    @badgerhill said in restoring original partition layout in capture mode:

    did not find new commit on github, that’s why i downloaded init.xz from jenkins

    In this case there was no new commit in the fogproject repo needed, only in the fos repo. The installer will pull the latest init from the server if you use dev-branch or RC. But manual download will also work!



  • @badgerhill
    downloaded init.xz from jenkins and exchanged it on my fog server.
    restoring original partition layout in capture mode is working now.
    thanks

    p.s.: did not find new commit on github, that’s why i downloaded init.xz from jenkins



  • @Sebastian-Roth
    Thanks Sebastian for the fast fix. Will do so, retest, and report back.


  • Senior Developer

    @badgerhill Please re-pull from github and re-run the installer - this issue should be fixed! Marking as solved.


  • Senior Developer

    Build is running, new init.xz will be available here in 3 hours for testing: https://dev.fogproject.org/blue/organizations/jenkins/fos/detail/master/128/artifacts


  • Senior Developer

    @badgerhill After a bit more research I found the issue is sector-size header was added to the output generated by sfdisk since version 2.35 but the same version fails on reading input with that header.

    The issue has been fixed upstream already and I will report this to the buildroot developers to include the upstream fix as soon as possible. Meanwhile I’ll compile a manually fixed version. Will report back soon.


  • Senior Developer

    @badgerhill Thanks heaps for providing the detailed information! I was able to reproduce the issue and found there is a problem in current sfdisk tool from the util-linux package. It’s unable to read the d1.partitions line “sector-size: 512” which was generated by the very same tool - very strange. I found a first hint here: https://gitlab.alpinelinux.org/alpine/aports/issues/11200

    I will keep digging and work on fixing this in the RC1 as soon as possible.



  • @Sebastian-Roth

    here is the link for the linux d1.mbr:
    d1.mbr
    https://we.tl/t-AeLW69whx3

    ::::::::::::::
    d1.partitions
    ::::::::::::::
    label: gpt
    label-id: B646C882-4828-4B16-BFB4-400B45E224A2
    device: /dev/sda
    unit: sectors
    first-lba: 34
    last-lba: 250069646
    sector-size: 512
    
    /dev/sda1 : start=        2048, size=     1083392, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=DEB202CA-7F3C-45A9-913B-B18645FFC8CE, name="Basic data partition", attrs="RequiredPartition GUID:63"
    /dev/sda2 : start=     1085440, size=      204800, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=ECCC7B27-F0AB-4B4C-BAAC-3D69BE295DE6, name="EFI system partition", attrs="GUID:63"
    /dev/sda3 : start=     1290240, size=       32768, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=A32700D3-64B2-4F23-A87D-BE1BE726A980, name="Microsoft reserved partition", attrs="GUID:63"
    /dev/sda4 : start=     1323008, size=   248746496, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=36DDF74E-1A1E-4299-A35C-578A01B8207E, name="Basic data partition"
    ::::::::::::::
    d1.minimum.partitions
    ::::::::::::::
    label: gpt
    label-id: B646C882-4828-4B16-BFB4-400B45E224A2
    device: /dev/sda
    unit: sectors
    first-lba: 34
    last-lba: 250069646
    sector-size: 512
    
    /dev/sda1 : start=        2048, size=     1083392, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=DEB202CA-7F3C-45A9-913B-B18645FFC8CE, name="Basic data partition", attrs="RequiredPartition GUID:63"
    /dev/sda2 : start=     1085440, size=      204800, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=ECCC7B27-F0AB-4B4C-BAAC-3D69BE295DE6, name="EFI system partition", attrs="GUID:63"
    /dev/sda3 : start=     1290240, size=       32768, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=A32700D3-64B2-4F23-A87D-BE1BE726A980, name="Microsoft reserved partition", attrs="GUID:63"
    /dev/sda4 : start=     1323008, size=    37690322, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=36DDF74E-1A1E-4299-A35C-578A01B8207E, name="Basic data partition"
    ::::::::::::::
    d1.fixed_size_partitions
    ::::::::::::::
    1:2:3
    

    and here the windows d1.mbr
    https://we.tl/t-0UBcB4uTAW


  • Senior Developer

    @badgerhill I will look into this issue later on today when I have some more time. Can you please post the very same information from your Windows image? Issues like this that have been reported before were usually due to special partition layouts. This is why I am asking for this information.

    You might also upload the binary file d1.mbr of both the images to an external file share and post a link here.



  • Sebastian,
    this issue is reproducible

    i did a fresh install of ubuntu 20.04 desktop
    installed fog 1.5.9-RC1
    did a capture of my linux machine - and the original partition layout was not restored after that.
    in addition to that i also captured a windows 10 machine with the samre result - actually win 10 is not really usable after the capture due to the lack of disk space.

    redeploying either machine fixes the issue.



  • @Sebastian-Roth

    B
    badgerhill 2 minutes ago

    sure i can:

    d1.partitions:

    label: dos
    label-id: 0x98702b27
    device: /dev/sda
    unit: sectors
    sector-size: 512
    
    /dev/sda1 : start=        2048, size=    54685696, type=83, bootable
    /dev/sda2 : start=    54687744, size=     2000896, type=82
    /dev/sda3 : start=    56688640, size=   193380864, type=83
    

    d1.minimum.partitions

    label: dos
    label-id: 0x98702b27
    device: /dev/sda
    unit: sectors
    sector-size: 512
    
    /dev/sda1 : start=        2048, size=    20189232, type=83, bootable
    /dev/sda2 : start=    54687744, size=     2000896, type=82
    /dev/sda3 : start=    56688640, size=     2063796, type=83
    
    

    d1.fixed_size_partitions

    2
    


  • This post is deleted!

  • Senior Developer

    @badgerhill Can you please post the content of the text files d1.partitions, d1.minimum.partitions and d1.fixed_size_partitions here. You find those in the image directory of that particular image on your FOG server.


Log in to reply
 

287
Online

7.2k
Users

14.4k
Topics

135.7k
Posts