Error trying to restore GPT partition deploying an Image to Smaller Disk

[Sebastian Roth]

@scosta I can reproduce the error but only if I use a disk sized 60 GB or smaller. As soon as I use a disk around 120 GB (as you mentioned) I don’t have any issue deploying using the partition layout you posted.

Please re-run the debug deploy test on your VM and when it fails and you get to the shell please run fdisk -l /dev/sda, take a picture and post here.

It’s still possible I am missing something here. If so it’s probably something I can’t get from the partition layout text files. Then I may ask you to upload d1.mbr so I can test with that.

[scosta]

@Sebastian-Roth thanks for answering, and sorry for my absense, i was travelling to remote sites to implement more fogstorages

Here’s the output of fdisk as you requested:

here’s a link all files except the big img ones:
https://drive.google.com/drive/folders/1LLdjb_OsqiFrrOTesQDlxvrb0RF3hDUC?usp=sharing

[Sebastian Roth]

@scosta Thanks for uploading the files. I wouldn’t have had a chance without those. Turns out the partition start sector information is different in d1.partitions versus what we see in d1.mbr. I still have no idea how that can happen. It doesn’t match any logic I have come across so far. It’s not a 4k block size thing and I have no idea what’s going on - not yet.

But I have a quick fix for you. Get a good hex editor and a copy of your d1.mbr file (keep a copy of the original somewhere just in case). Open it and go down a few lines till you get to position 07A0. Should look like this:

00000780   A2 A0 D0 EB  E5 B9 33 44  87 C0 68 B6  B7 26 99 C7  ......3D..h..&..
00000790   18 46 DC CB  86 67 E9 11  97 EA F8 22  01 FA 30 3B  .F...g....."..0;
000007A0   00 02 D0 0E  00 00 00 00  F7 FC 9E 0F  00 00 00 00  ................

Simply change the hex numbers in the last line (07A0

00000780   A2 A0 D0 EB  E5 B9 33 44  87 C0 68 B6  B7 26 99 C7  ......3D..h..&..
00000790   18 46 DC CB  86 67 E9 11  97 EA F8 22  01 FA 30 3B  .F...g....."..0;
000007A0   00 96 8E 07  00 00 00 00  F7 90 5D 08  00 00 00 00  ..........].....

Save the file and put into your image directory on the FOG server as /images/W10_SEMSIS_MULTI_1.01/d1.mbr. Now try to deploy again. Should work.

I know this sounds really strange and I am fairly sure we’ll find out why this has happened. But for the time being I hope you can get this fixed as simple as described above to be able to deploy this image again.

[Sebastian Roth]

@scosta Thinking a bit more about it I am wondering if you did resize the partitions on your master at some point. I am not sure but possibly this could lead to the situation we see with different partition start information.

Please schedule a debug capture task and when you get to the shell run sfdisk -d /dev/sda and gdisk -l /dev/sda - take a picture and post here.

[scosta]

@Sebastian-Roth I’ll be running your requests asap, but I can antecipate you that the only manual alteration I tried before posting here was to adjust the d1.minimim.partitions sizes to match the d1.partitions, because using the d1.fixed_size_partitions was not forcing my system partition to 60Gb (/dev/sda3 and i need it to never be resized.)

Maybe the capture process have anything to do with this? What I did: Prepare the image using UEFI Bios, then switch to Legacy for the FOG Capture, then reverting back to UEFI. Same deal on the deploy: change to legacy to Fog Deploy, then reverting back to UEFI.

[Sebastian Roth]

@scosta Hey, any news on this?

We might have a similar issue here: https://forums.fogproject.org/topic/13302/error-trying-to-restore-gpt-partition-tables-exit-returned-code-4

Did you use mbr2gpt to convert your system from legacy to UEFI at some point in time?

[scosta]

@Sebastian-Roth yeah, we did… To solve the problem i did that HEX edition on the d1.mbr file you suggested and it fixed my issue. what still intrigues me is the fact that using d1.fixed_size_partitions, i.e. changing it to :2:3:4 is not ensuring those partitions to stay with fixed size as i needed. to make it happen, i had to make the sizes on both d1.partitions and d1.minium.partitions the same.

i’ll take a look on this other forum link you mentioned.

[Sebastian Roth]

@scosta Thanks for letting us know. Great to hear the hex edit foo worked for you as well. Very strange case indeed.

what still intrigues me is the fact that using d1.fixed_size_partitions, i.e. changing it to :2:3:4 is not ensuring those partitions to stay with fixed size as i needed.

Now about this. I don’t get what you say here. For the partition layout you posted above it doesn’t make much sense to me to set fixed to “:2:3:4” as this would force it to be a non-resizable deploy. Or is that what you are saying? You want it to be non-resizable? Why not use the right image type then. Sure the behavior might be a bit unexpected but this is kind of like saying I would like to have a car with automatic transmission but don’t want to have it change gear by itself. Well kind of, just kidding.

[scosta]

@Sebastian-Roth said in Error trying to restore GPT partition deploying an Image to Smaller Disk:

it doesn’t make much sense to me to set fixed to “:2:3:4”

indeed it does not make sense, because i confused myself haha =D
i meant to set fixed to “:1:2:3”, intending to keep the 3 first partitions fixed and the last one resizable as need. that also did not work.

i really don’t mind changing the files to achieve the desired result, but if fixed_size_partitions works, it would be a LOT more easier

[Sebastian Roth]

@scosta I know it’s been a long time but have not found enough time to work on this earlier. We now have a first version of init.xz capable of capturing and deploying a Windows 10 2004 UEFI/GPT install with recovery partition at the end. Would you give that a try.

Please be aware this is still in kind of a pre-release phase. Make sure you have a backup of your original image as well as the machine you pull the master from, just in case!!