Error trying to restore GPT partition tables. Exit returned code 4

[Matthieu Jacquart]

@Sebastian-Roth lastlog command is installed but doesn’t return any result for fogproject user, and same problem for fog and root account ! I just don’t understand, very strange…

For error deploying image, I tried to uplaod image on another computer and now I’ve got this…

Debug command parted -l /dev/sda give this

I don’t understand but I’m leaving office now for a big week-end until monday, I’ll chek this next week !

Thanks
Matthieu

[Sebastian Roth]

@Matthieu-Jacquart I am not sure we’ll get to anything here. There are too many strains of topics combined in one forum thread. This makes it very hard to follow and quite often we seem to mix up things here.

For the parted -l /dev/sda output it would have been interesting to see the one with the four partitions.

[Matthieu Jacquart]

@Sebastian-Roth Ok I continue test, upgrading image to 1903 but still same problem.
So these are results on PC I used to update masters, Dell Optiplex 3020 with SSD 128GB. I have no problem to upload and deploy image on this model, but all others models failed with “Error trying to restore GPT partition tables. Exit returned code 4”

d1.partitions :

label: gpt
label-id: 24A810B8-1662-11E9-AB92-B083FE947687
device: /dev/sda
unit: sectors
first-lba: 34
last-lba: 250069646

/dev/sda1 : start=        2048, size=   248742296, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=24A810B5-1662-11E9-AB92-B083FE947687
/dev/sda2 : start=   248745984, size=     1116160, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=5F6E777F-5719-4379-A14B-0397E0C234B2, attrs="RequiredPartition GUID:63"
/dev/sda3 : start=   249862656, size=      206848, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=24A810B6-1662-11E9-AB92-B083FE947687

d1.minimum.partitions :

label: gpt
label-id: 24A810B8-1662-11E9-AB92-B083FE947687
device: /dev/sda
unit: sectors
first-lba: 34
last-lba: 250069646

/dev/sda1 : start=        2048, size=    55035482, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=24A810B5-1662-11E9-AB92-B083FE947687
/dev/sda2 : start=   248745984, size=     1116160, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=5F6E777F-5719-4379-A14B-0397E0C234B2, name="attrs=\x22RequiredPartition GUID:63"
/dev/sda3 : start=   249862656, size=      206848, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=24A810B6-1662-11E9-AB92-B083FE947687

d1.fixed_size_partitions :

:3:2:2:3

And for parted -l /dev/sda command :

Thanks
Matthieu

[Quazz]

@Matthieu-Jacquart Pretty weird layout, that’s not going to be pretty on devices with larger or smaller disks.

[Matthieu Jacquart]

@Quazz yeah, strange layout I agree
Any way to restore a good layout (gparted or else) ?

[Joe Gill]

@phishphan Did you read this? Looks similar to what you’re experiencing.

[Sebastian Roth]

@Matthieu-Jacquart Well GParted might be able to shuffle around the partitions for you. It’s a GPT layout and hopefully a real EFI setup. Moving the boot partition (now sda3) might work without breaking the whole thing. But I highly recommend you take a sector by sector backup copy of that machine first before trying!

Make the smaller partitions first and then the larger data/windows partitions last.

[drumnj]

I ran into the same issue. Upgraded to 1.5.6 and got this error when deploying my image. It was working on 1.5.5 before I updated, then recaptured a new image. If it helps…the 1.5.6 captured image doesn’t work, but the 1.5.5 captured image does. Used the same image that was captured on 1.5.6 on both versions, get this error. Using the 1.5.5 captured image on both versions, no error.

Running:
Ubuntu 18.04.2 LTS
Hyper-V

[Sebastian Roth]

@drumnj Please don’t cross post those kind of partition layout issues!!! Each and every partition layout is different - peroid and therefore every one of those issues is kind of different too.

Please open a new topic and post at least d1.partitions, d1.minimum.partitions and d1.fixed_size_partitions of your particular image as well as the image you just uploaded. Thanks!

[drumnj]

@Sebastian-Roth Looks like it’s the same type of error. I did my tests using the same checkpoint on my image, multiple times, so nothing changed with my partitions, just the FOG version. I’m just going to stick with 1.5.5 since it works. I’ll test again when another version comes out.

[Sebastian Roth]

@drumnj If you don’t give us your particular partition layout details we can’t fix the issue (if there is one in 1.5.6). It’s as simple as that!!

[Matthieu Jacquart]

@Sebastian-Roth Ok I have same issue on another computer with standard layout, I think it coul be related to Win10 1903 update ? If I upload image before sysprep and deploy on another configuration, it’s ok. But if I sysprep and then capture image, deploy failed

d1.fixed_size_partitions
:2:2

d1.minimum.partitions
label: gpt
label-id: 6A1C2439-885F-11E9-BB12-1866DA164C99
device: /dev/sda
unit: sectors
first-lba: 34
last-lba: 250069646

/dev/sda1 : start=        2048, size=       24940, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=6A1C2436-885F-11E9-BB12-1866DA164C99, name="attrs=\x22RequiredPartition GUID:63"
/dev/sda2 : start=     1979904, size=      202752, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=6A1C2437-885F-11E9-BB12-1866DA164C99, name="attrs=\x22GUID:63"
/dev/sda3 : start=     2182656, size=    46627670, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=6A1C2438-885F-11E9-BB12-1866DA164C99

d1.partitions
label: gpt
label-id: 6A1C2439-885F-11E9-BB12-1866DA164C99
device: /dev/sda
unit: sectors
first-lba: 34
last-lba: 250069646

/dev/sda1 : start=        2048, size=     1977856, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=6A1C2436-885F-11E9-BB12-1866DA164C99, name="attrs=\x22RequiredPartition GUID:63"
/dev/sda2 : start=     1979904, size=      202752, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=6A1C2437-885F-11E9-BB12-1866DA164C99, name="attrs=\x22GUID:63"
/dev/sda3 : start=     2182656, size=   247886848, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=6A1C2438-885F-11E9-BB12-1866DA164C99

I passed this script but same result

dism /online /cleanup-image /startcomponentcleanup
dism /online /cleanup-image /scanhealth
dism /online /cleanup-image /checkhealth
dism /online /cleanup-image /restorehealth
sfc /scannow
chkdsk C: /f

[Quazz]

@Matthieu-Jacquart 1903 is no problem on my end, though I must highlight I’m confused by your partition layout.

On a standard W10 GPT install you’d expect 4 partitions (minimum), and on a standard MBR install you’d expect 2.

What FOG version you on?

[Matthieu Jacquart]

@Quazz It’s fog 1.5.6.4 with latest kernel (4.19.36 and 4.19.48).
Indeed I’ve got 2 images with 4 partitions (one is hidden 16MB, not showed on disk manager but listed with diskpart) and no problem to deploy these ones, but on 2 other images there’s just 3 partitions (OEM, system and windows) and I’ve got trouble on different configuration…
So it may be related to mbr2gpt command I use to transform legacy to UEFI but I made it for my 4 images and 2 only are ok, I don’t know why and how to fix that…

[Sebastian Roth]

@Matthieu-Jacquart Beside the layout being a bit weird with the three partitions it actually looks very good for being properly re-sizable! The smaller unmovable partitions are in the front (sda1 and sda2) while the big Windows partition is last.

Interesting that you were not able to deploy this. Let me ask you a few questions:

1. What size is the disk you captured the image from?
2. What size is the disk you tried to deploy it to?
3. Can you please schedule another deploy on this machine but schedule as debug this time!? Start the task as usual till you hit the error and get back to the shell. Now run the following command
4. Can you please upload d1.mbr of that exact image to a fileshare and post a link here?

This one you just posted reminds me on a topic that we had some weeks ago. In the end I think it turned out to be a very strange partition start number issue that was only in the d1.mbr file but not in the text-based partition layout files. I still have no idea why something like this would happen: https://forums.fogproject.org/topic/13220/error-trying-to-restore-gpt-partition-deploying-an-image-to-smaller-disk

[Matthieu Jacquart]

@Sebastian-Roth Image was captured on 128GB SSD and failed to deploy on 120GB SSD, but I found an ugly solution that resolved my problem very well : thanks to you and @Quazz I did’nt notice that good layout contains 4 and not 3 partitions, so I just copy all files from a “good” image to a bad image folder, exept windows data partition that I renamed from d1p3.img to d1p4.img and everything works great !!!

Defective image

Fonctionnal image

New image by copy all files from fonctionnal image except d1p4.img from defective image

So for me this problem is resolved, big thanks to Fog team
Matthieu

[Sebastian Roth]

@Matthieu-Jacquart Wow that’s a real nasty hack to just combine the images. If it works for you - great - go ahead!

Image was captured on 128GB SSD and failed to deploy on 120GB SSD

Yeah I guess this is why it fails. Not because your partition layout is not re-sizeable but because some strange thing in the d1.mbr is causing the issue I reckon.

[Matthieu Jacquart]

@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/7

Thanks
Matthieu

[Sebastian Roth]

@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 this d1.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.

[Matthieu Jacquart]

@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_kUld0vkPs6w

Thanks