Error Trying to Restore GPT Partition Tables
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.
@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.
@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.mbrof 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
Win10UEFITestin the second. Are they both captured from the exact same master machine? Best if you upload both (if you still have them).
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?
@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.mbrusing a hex editor to fix that and make it deploy properly. But we never found a proper solution that would make a fresh captured
all it has in there is
@thennessey Ok, little different than what I had expected. Can you please post the contents of the text file
/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”
@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.partitionsfrom your FOG server here we’d know.
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.
@thennessey Search the forums for
sgdiskand debug mode. This should give you instructions on how to figure out why it falls.