restoring original partition layout in capture mode

[badgerhill]

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

[Sebastian Roth]

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

[badgerhill]

This post is deleted!

[badgerhill]

@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

[badgerhill]

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]

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

[badgerhill]

@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

[Sebastian Roth]

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

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

[Sebastian Roth]

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

[Sebastian Roth]

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

[badgerhill]

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

[badgerhill]

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

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

[Sebastian Roth]

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.