Error trying to restore GPT Partition tables (restorepartitionTablesAndBootLoaders)

Dan_Ansel

Hello, thanks for your answer.

I’m trying to deploy Windows 10 1909, I did not make the jump to the 2004.

I’m desperately trying to avoid re creating my images.
As for the hacking way, i’m not too sure where to start.

Regards,
Dan

george1421

@Dan_Ansel can you post the content of your d1.partitions and d1.fixed_size_partitions files? Its in the /images/<image_name> directory on the fog server

Dan_Ansel

@george1421

There it is :

d1.fixed_size_partitions :

1:3

d1.partitions :

label: gpt
label-id: 38CF0A2B-CD00-11EA-B7E0-000C29541530
device: /dev/sda
unit: sectors
first-lba: 34
last-lba: 536870878
sector-size: 512

/dev/sda1 : start=        2048, size=     1185792, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=38CF0A28-CD00-11EA-B7E0-000C29541530, attrs="RequiredPartition GUID:63"
/dev/sda2 : start=     1187840, size=   535474176, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=38CF0A29-CD00-11EA-B7E0-000C29541530
/dev/sda3 : start=   536662016, size=      204800, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=38CF0A2A-CD00-11EA-B7E0-000C29541530, attrs="GUID:63"

Sebastian Roth

@Dan_Ansel As well please post d1.minimum.partitions, thanks.

Dan_Ansel

@Sebastian-Roth

Here’s the content of the d1.minimum :

label: gpt
label-id: 38CF0A2B-CD00-11EA-B7E0-000C29541530
device: /dev/sda
unit: sectors
first-lba: 34
last-lba: 536870878
sector-size: 512

/dev/sda1 : start=        2048, size=     1185792, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=38CF0A28-CD00-11EA-B7E0-000C29541530, name="attrs=\x22RequiredPartition GUID:63"
/dev/sda2 : start=     1187840, size=   282008362, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=38CF0A29-CD00-11EA-B7E0-000C29541530
/dev/sda3 : start=   536662016, size=      204800, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=38CF0A2A-CD00-11EA-B7E0-000C29541530, name="attrs=\x22GUID:63"

EDIT: bad copy paste, sorry

Dan_Ansel

@Sebastian-Roth @george1421

Do I just need to change the start value in both files (d1.partitions and d1.minimum.partitions) for /dev/sda3, and the size value of /dev/sda2 in d1.partitions ?

Regards,
Dan

george1421

@Dan_Ansel This issue is a bit complex and there is not clean solution as of now. Someone else had this issue and I suggested removing all references of that (in your case /dev/sda3) from all of the d1.xxxxxxx files (make a backup of these files first). Then when FOG goes to restore it won’t know that the partition existed.

The issue/risk is that there is a binary file d1.mbr that also contains a reference to /dev/sda3 that needs to be removed the OP of that thread said that he was able to remove the reference but didn’t explain how. Once the reference to the non-movable partition was removed from the config files the image deployed correctly. I now don’t feel confident if giving you this solution without first having to test it in my LAB.

The better issue is resolving it in FOG code, but that is going to take some time since developer time resources are low right now.

Dan_Ansel

@george1421

OK thanks for your anwser.
I’ll get working on a new image then since time is of the essence here.

I’ll keep an eye on this thread and try out ideas thrown here.
If my problem can be used as a template on how to resolve this issue, it might help others as well.

Regards,
Dan

george1421

@Dan_Ansel Maybe a quick solution is to deploy the image to a disk the same size or larger than the golden image disk. Once deployed delete that unmovable partition by inserting the disk into another computer as a second disk. Then recapture the image with fog minus that troubling partition. You should be able to do that in about 30 minutes and not have to rebuild anything.

Dan_Ansel

@george1421 the partition causing all the trouble is the EFI system one
If i remove it entirely, my OS won’t boot at all, will it ?

george1421

@Dan_Ansel Is your efi partition the last one on the disk? That is a really abnormal disk configuration. Typically the last partition is the recovery partition.

Normal is

EFI boot
System Reserved
C dirve
Recovery

In this configuration the recovery can be removed with no loss of function other than system recovery. Which in a business environment its easier to reimage with FOG than try to windows recover it.

Edit: looking at your disk map I see the efi partition is #3, very strange configuration.

Dan_Ansel

@george1421 yeah I know, I believe it’s because the image was originally in Legacy mode, and I converted it to UEFI (using mbr2pgt), so the EFI partition was created last.

george1421

@Dan_Ansel I’m not sure which would be quicker.

Recreate your image and recapture with FOG.
Do a typical generic install of Windows OEM in UEFI mode. You really don’t care about the OS, you just need the disk structure. Just next/next/next through the windows install. Remove the recovery partition. Capture with FOG to a new image file (just in case). On that new golden computer, then deploy that single partition from your previously captured image to partition 3 on the golden image computer. You will need to change the deploy mode of your original image to single partition. So to say it the another way. Create an basic OEM install of windows. Remove the standard recovery partition. Then take partition 3 from your original golden image and overwrite the OEM partition 3. Its a bit like shuffling the playing cards around.

While its a bit off point here, this is the reason why we use MDT to create our golden images. This allows us to recreate our master golden image using the lite touch approach. We can rebuild the golden image without much pain at all since everything is all automated.

Dan_Ansel

@george1421

If I understand you correctly :

I create a new VM with a brand new Win10 install for the disk structure.
I remove the last partition, and it should normally be the recovery
I capture the C Drive partition where I have installed everything I need (I capture this specific partition)
I deploy that partition on the brand new install of Win10, writing over the empty C Drive

I’m not sure that’s exactly what you said, hence my question to confirm the steps

george1421

@Dan_Ansel said in Error trying to restore GPT Partition tables (restorepartitionTablesAndBootLoaders):

I create a new VM with a brand new Win10 install for the disk structure.

I remove the last partition, and it should normally be the recovery

I capture the C Drive partition where I have installed everything I need (I capture this specific partition)

I deploy that partition on the brand new install of Win10, writing over the empty C Drive

Almost exactly what I think. In step 3 I say make a back up of the new VM but you can do with snapshots the same. The idea is to save the new VM just in case something goes wrong.

Take your previously captured golden image and only deploy partition 3 to your new VM overwriting the new Win10 install C drive with your golden image C drive.

(I realize there is a small language differences, so I should have been more clear on my idea).

In the end you should end up with
Partition 1 new Win10 partition (EFI boot)
Partition 2 new Win10 partition (System Reserved)
Partition 3 old golden image partition 3
Partition 4 (removed new Win10 partition)

I’m thinking this will work as long as the old golden image partition 3 was converted to UEFI mode and the old golden image actually booted (somewhere) before even if partition 3 is the EFI boot partition.

Dan_Ansel

@george1421

Thank you for taking the time to make this a bit clearer to me.

I’m trying this right now.
I just hope the fact that the C Drive partition will not have the same number won’t be an issue (it was /dev/sda2 on the completed install, and will be /dev/sda3 on the new one if all goes well)

It really feels like surgery

I’ll keep you updated on how it will go (you’ll probably here from me tomorrow)

Regards,
Dan

Dan_Ansel

@george1421

There’s an issue when deploying.

First, I’ll tel you what I’ve done exactly :

I capture the specific partition containing the fully installed windows 10 (it was on /dev/sda2). I used the option Single Disk - Resizable, Partition 2 only
I installed a brand new virtual machine in UEFI from the get go to get a proper disk structure, I remove the last partition
I created the deploy task, and that’s when the problom occurs : since the partition captured wad /dev/sda2 , the task is trying to deploy over the /dev/sda2 of the new installation, and if I change the partition number in the web GUI for the image, I have an other error message telling me that there is not partition with that number to deploy in the image.

Is there a way to tell fog to deploy a partition that was /dev/sda2 over a new one that is /dev/sda3 ?

Regards,
Dan

Dan_Ansel

@george1421

I did it !!

So I basically made a Frankenstein’s monster version of my image.

As I’ve stated in my last comment, I had an issue where the windows drive did not have the same partition number.

I created a new legacy windows 10 VM, with a smaller C Drive than I created the very first time I worked on that image. I converted that installation into UEFI.
So now my newly installed win10 and my oversized image have the exact same disk structure.

I deployed the partition containing all my data onto the new VM, and I had an issue where the UEFI boot was broken.

I used the tools in the installation media to repair the EFI partition. I used diskpart to assign a letter to the EFI partition, exited diskpart and ran this command :

bcdboot C:\Windows fr-fr /s B: /f

Windows booted.
Now I’m capturing the image and I’ll deploy it to make sure it’s working fine
Thanks for all the help and ideas!!

Regards,
Dan

Error trying to restore GPT Partition tables (restorepartitionTablesAndBootLoaders)

185

12.0k

17.3k

155.2k