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 -
@badgerhill Can you please post the content of the text files
d1.partitions
,d1.minimum.partitions
andd1.fixed_size_partitions
here. You find those in the image directory of that particular image on your FOG server. -
This post is deleted! -
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.