Error Trying to Restore GPT Partition Tables

[thennessey]

Hey folks

I’m trying to deploy a new Win10 image to some UEFI Dell desktops. The image captures fine but when I try to deploy it I get the below error.

I’ve tried re-capturing the image in both Single Disk - Resizeable and Multiple Partition image - single Disk Not Resizable. I’ve been looking through old forum posts and it looks like this has happened before, but I couldn’t find a fix.

Any Ideas?

[Sebastian Roth]

@thennessey Search the forums for sgdisk and debug mode. This should give you instructions on how to figure out why it falls.

[thennessey]

Here’s what came back after I ran through it in debug. I guess it has something to do with the partition size. But the disk I’m putting the image onto is larger than the one I captured it from.

[Sebastian Roth]

@thennessey From experience I’d guess that you have some kind of recovery partition at the end of your disk and FOG doesn’t like moving those and cannot resize your main Windows partition because of that. Though this is more a guess. If you post the contents of the text file /images/Win10UEFITest/d1.minimum.partitions from your FOG server here we’d know.

[thennessey]

@Sebastian-Roth label:
gpt
label-id: E8EC6BDA-24D2-4E9E-8EF5-0DB329E9FB15
device: /dev/sda
unit: sectors
first-lba: 34
last-lba: 209715166

/dev/sda1 : start= 2048, size= 818168, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=8A107DC1-ECF5-4B60-88AD-AA36777564FE, name=“Basic data partition”, attrs=“RequiredPartition GUID:63”
/dev/sda2 : start= 1085440, size= 202752, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=E4456E58-EEEA-4834-8B33-A288002CB881, name=“EFI system partition”, attrs=“GUID:63”
/dev/sda3 : start= 1288192, size= 32768, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=B84F88AA-6F50-4CE0-8401-74539AB43F78, name=“Microsoft reserved partition”, attrs=“GUID:63”
/dev/sda4 : start= 1320960, size= 35678354, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=89B4CEA2-F0BE-437A-898F-BCEB05CF13E5, name=“Basic data partition”

[Sebastian Roth]

@thennessey Ok, little different than what I had expected. Can you please post the contents of the text file /images/Win10UEFITest/d1.fixed_size_partitions too?

[thennessey]

all it has in there is

2:3

[Sebastian Roth]

@thennessey What size is the destination disk? From the partition table it needs to be at least 17.64 GB and I am fairly sure it’s big enough, right?

Last time we had this kind of issue it turned out to be caused by converting the partition table using mbr2gpt. Did you use that by any chance? I ended up modifying the users d1.mbr using a hex editor to fix that and make it deploy properly. But we never found a proper solution that would make a fresh captured d1.mbr work.

https://forums.fogproject.org/topic/13220/error-trying-to-restore-gpt-partition-deploying-an-image-to-smaller-disk

[thennessey]

Yeah there’s plenty of room on the disk. I haven’t done any conversions to the partition table, but I am capturing the image from an AHV VM. Have they caused issues in the past?

[Sebastian Roth]

@thennessey I haven’t used AHV myself yet. Reading a bit about it I get the impression that it uses existing technology like XenServer, VMware and Hyper-V. Is that right or does it also have it’s own native virtualization technology?

Anyhow, I can’t think of a way the virtualization technology can cause this issue.

Can you please grab the binary file d1.mbr of your image, upload to a file sharing platform and post a link here. I shall take a look at it to see if it’s the same issue as described in the other topic.

By the way, in the first picture you had the image named Win10UEFI while it’s Win10UEFITest in the second. Are they both captured from the exact same master machine? Best if you upload both (if you still have them).

[thennessey]

@Sebastian-Roth Because this sounds like this will only fix the one image I went ahead and captured one that’s ready for deployment. Here’s all the files for the new image.

https://drive.google.com/drive/folders/16txyC6sRJa9d8IJDNBYZEvrc9ijlCjuz?usp=sharing

[Sebastian Roth]

@thennessey Sorry for the long delay but this is something I need time and concentration to work on. I had a play with the files you shared in the google drive and I am wondering if you have tried to deploy this image to a machine yet?!? Because I couldn’t find the same problem that I had described in the other post with your d1.mbr and then just did the practical test of trying to deploy a test machine (VirtualBox VM) with your partition layout files. Worked absolutely great on a 100 GB disk in the VM.

So it looks like you have some difference in the images and the latest one doesn’t seem to have the problem! I am almost absolutely sure this image will deploy to any disk as small as roughly 20 GB!!

There must be something in the disk layout of the other images you made that was causing the initial problem. Can you please provide the same files from those images so I can take a look and hopefully I might even figure out a way to detect this problem within the deployment process and correct on the fly or show an appropriate message to the user.

[thennessey]

@Sebastian-Roth Yeah sure enough it worked. I think it might also have to do with some BIOS options on the Dell 3050/3070s I was deploying to. I changed the boot drive to AHCI mode instead of their weird raid thing. Everything seems to be working now.

I swapped out the files in the google drive link for the ones that are associated with the win10UEFItest image that I originally had questions about. Thanks for all your help!

[Sebastian Roth]

@thennessey I will take a look at the other files…

[Sebastian Roth]

@thennessey said in Error Trying to Restore GPT Partition Tables:

I swapped out the files in the google drive link for the ones that are associated with the win10UEFItest image that I originally had questions about.

I see you swapped those out (numbers in the files are different) but I still cannot reproduce the issue as reported. The numbers seem ok and I can deploy using those files to a 100 GB size VM disk perfectly fine…