restoring original partition layout in capture mode
-
B
badgerhill 2 minutes agosure 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
-
Sebastian,
this issue is reproduciblei 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.
-
@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. -
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 -
@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 thed1.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/11200I will keep digging and work on fixing this in the RC1 as soon as possible.
-
@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.
-
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
-
@badgerhill Please re-pull from github and re-run the installer - this issue should be fixed! Marking as solved.
-
@Sebastian-Roth
Thanks Sebastian for the fast fix. Will do so, retest, and report back. -
@badgerhill
downloaded init.xz from jenkins and exchanged it on my fog server.
restoring original partition layout in capture mode is working now.
thanksp.s.: did not find new commit on github, that’s why i downloaded init.xz from jenkins
-
@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!
-
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.