Error trying to restore GPT partition tables. Exit returned code 4
-
@Sebastian-Roth Hi Seb, finally my trick resolve issue on some smaller disk (works now on 120GB disk with image created on 128GB disk), but some old computer with 60GB have still same error, can you take a look to d1.mbr file here ?
https://send.firefox.com/download/f8a134b57bdefad8/#lyrswaozWAFfuWTEcrYrNQ
Maybe some hex modification as in this topic is possible ? https://forums.fogproject.org/topic/13220/error-trying-to-restore-gpt-partition-deploying-an-image-to-smaller-disk/7Thanks
Matthieu -
@Matthieu-Jacquart Sorry for the long delay but I have not found the time to look into this any ealier. The
d1.mbr
file you posted shows the following partition table:label: gpt label-id: 4C01BDD7-29D4-4B8C-99D8-987EEA909303 device: /dev/sda unit: sectors first-lba: 34 last-lba: 1073741790 /dev/sda1 : start= 2048, size= 1021952, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=081D3F0B-1B52-4643-8A24-684A7C1A8429, name="Basic data partition", attrs="RequiredPartition GUID:63" /dev/sda2 : start= 1024000, size= 204800, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=607139A0-16C8-4261-BB87-253F40D707BD, name="EFI system partition", attrs="GUID:63" /dev/sda3 : start= 1228800, size= 32768, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=485F8027-C27D-4519-AA08-3980851152A7, name="Microsoft reserved partition", attrs="GUID:63" /dev/sda4 : start= 1261568, size= 233179648, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=5BB64B2B-6646-419B-BE8A-13BB2269F0E8, name="Basic data partition"
The layout and UUIDs match the one you posted here on May 27, 2019, 7:29 PM. It’s very important exactly which image and partition layout we are talking about. I thought we were still discussing the other one with three partitions you mentioned on June 27, 2019, 3:32 PM. I just say this because if we confuse things here we won’t be able to properly help you. So in any case you want support with this, make sure you give us all the details for each image you want us to help you with. Every partition layout is different and there is no general answer or solution for all of them.
Ok, back to the partition layout from 27th of May. The
d1.mbr
file you uploaded has four partitions and the last partitions starts at sector 1261568 and is 233179648 sectors in size (see numbers above). Now that makes 234441216 the least amount of sectors you need on a disk to be able to deploy this image. 233179648 * 512 KB sector size is roughly 112 GB and it won’t fit onto a 60 GB disk! Too bad I can’t fix thisd1.mbr
for you because I am missing some important information.In that post mentioned we see that the partitions 2, 3 and 4 are detected as fixed size and therefore FOG does not shrink those when capturing the image. So at this point we don’t know how much data you have on that partition and can’t fix the
d1.mbr
.To be able to fix this we would need to find out why FOG detects the fourth partitions as fixed. Can you please schedule a debug upload task on the machine you usually capture the image from. Boot it up and when you get to the shell run
parted /dev/sda print
, take a picture and post here. -
@Sebastian-Roth Hi, to speak about the same and only d1.mbr, d1.partitions and d1.miminumpartitions, I continue test and I made fresh win10 UEFI install and revert Fog to 1.5.5 version. But problem was the same, capture and deploy image on SSD 128GB is ok, but deploy on 50GB disk failed.
A colleague made some change on these 3 files (d1.mbr and the 2 d1 partitions files) to change dev/sda4 size from 248745984 to 104857600, and now it works great !!!
So I think it’s a Fog capture problem, here’s a link with 2 folders : Win10 for original capture which failed on smaller disk, and 50GB with working modified files
https://send.firefox.com/download/28dabd13930e0bc0/#BMGg3OazBC_kUld0vkPs6wThanks
-
@Matthieu-Jacquart What’s on the first partition? It’s currently not marked as fixed size, is this to be expected?
-
@Quazz Hi, first partition is Recover (500Mb), I don’t know why it’s not marked as fixed, I still can edit file ta add 1: at the beginning ? But sda1 size is not the on d1.partitions and d1.miminum.partitions
-
@Matthieu-Jacquart Thanks for posting more details. Can you do me one more favor. On the machine you capture this image from schedule a debug capture task. Boot it up and when you get to the shell run
parted -l
. Take a picture of the output and post here. Make sure we have all the information in the picture - especially the flags at the end of each line.We definitely should find out why it doesn’t mark the first partition as fixed and this will help us!
-
@Sebastian-Roth Hi, sorry for the delay but so much work and so little time…
here is the result from parted -l command with debug capture task, il it can help…I’m on vacation in few minutes and I’ll be back in August 16th
Thanks
-
@Matthieu-Jacquart Thanks!! I’ll play with this over the weekend and will let you know what I find.
-
@Matthieu-Jacquart I have tested a fair bit and it seems like some or most of the issues you reported here seem to be related to the problem we are tracking down in another topic as well. I am testing fixes at the moment.
But there is still one thing that doesn’t make sense for me. Your
d1.fixed_size_partitions
being set to:2:3
just doesn’t add up for me. My guess is that with reverting back to 1.5.5 you are still using the “old” inits that use label based detection of fixed partitions.I will let you know as soon as the new init’s are ready so you can test!
-
@Matthieu-Jacquart Ok, new inits are ready. Download 64 Bit and 32 Bit and put those in
/var/www/html/fog/service/ipxe/
dir on your FOG server. Probably good to rename the original ones instead of overwriting.As well you need to check the RAM SIZE option in FOG configuration, FOg settings. Need to be 275000 with the newer inits.
With those I hope you won’t have the random issues anymore.
-
@Sebastian-Roth Hi, thanks so much for your work and help, I’ll test as soon as I came back to work, after 19th August.