Error trying to restore GPT partition tables

aephk

Hi folks, I’ve been running in to some issues deploying a recent image to certain drives, resulting in the “Error trying to restore to GPT partition tables” error.

I have seen similar threads recently reporting the same error message but they appear to be caused by other issues.

The image is Windows 10 and was captured from a 240GB SanDisk SSD, and I am trying to deploy to the same size, brand, and model of drive, just an older revision which seems to be a very slightly different size. I am able to deploy without issues to the newer drives, but not the older ones. I am not sure if this is related however, as there is no mention of a size mismatch being the cause of the issue.

I have also noticed that the image capture is failing to resize on of the partitions so the image “On client” size is showing at around 223GB or so. I’m not sure what is causing this as other Windows 10 images have been captured fine, and in fact this one was built using a previous image as it’s starting point.

Having a look at the image’s files on the server, all partitions are marked as fixed in d1.fixed_size_partitions, I have tried removing the largest partition from this file to see if it would allow the image to go out but no luck there.

Any help on this issue is much appreciated!

Cheers,
aephk

aephk

I may have found the issue here.

I was curious as to why FOG was refusing to resize the disk, so I thought I’d try a manual resize in linux/gparted. Booting in to the gparted live cd, gparted could see the drive and all of the partitions but it was failing to read the contents of partition 4.

I Googled this and it looks like it may have been caused by bad sectors and running chkdsk /f had fixed it for others so I tried that, went back in to gparted and now everything looked fine. So I’ve run a new capture and it appears to have shrunk the 4th partition as expected. I’m currently deploying it to one of the drives that was failing and all is looking good so far.

I’m not sure what caused the issue in the first place, I hadn’t modified the partition table at all, I had just installed an admittedly fairly large number of programs to an existing image and tried to recapture it.

@Quazz @Sebastian-Roth @EduardoTSeoane Thanks for your help on this folks!

Quazz

What FOG version are you running?

aephk

@Quazz Sorry, should have said. I’m running FOG 1.5.4, and the clients are using kernel version 4.19.64

Quazz

@aephk Try updating to FOG 1.5.7 and try again

aephk

@Quazz Unfortunately we’re using Ubuntu for the server and looking at the announcement for 1.5.7 it sin’t recommended to upgrade an existing install on Ubuntu to this release.

Quazz

@aephk

Try updating just the init.xz files then

https://fogproject.org/inits/init.xz

and

https://fogproject.org/inits/init_32.xz

They go in /var/www/fog/service/ipxe

aephk

@Quazz Still seeing the same error after updating with the files you linked, unfortunately.

Sebastian Roth

@aephk Using the newer inits as suggested by Quazz is a good try. But you will also have to update the kernel binaries for compatibility und as well with the newer kernels/ints you need to manually change a settings. Go to the FOG web UI -> FOG Configuration -> FOG Settings -> FTP Server and increase KERNEL RAMDISK SIZE from 127000 to 275000.

Quazz

@aephk You may have to recapture the image (I assume image type is single disk - resizable) to get the data correct.

I’m guessing your target is slightly smaller which makes the partition table not fit, but once the resizable aspect works correctly this should work fine.

It’s also possible you have an odd partition layout (eg a recovery partition after your windows partition) that’s ballooning your image size.

aephk

@Quazz Will attempt recapture now.

Checking in Windows on the source drive it only shows 3 partitions, however, FOG seems to be picking it up as having 4 which is odd…

@Sebastian-Roth I have the client in question using the 4.19.64 kernel, and had changed the ramdisk size when troubleshooting the issue initially.

Sebastian Roth

@aephk said in Error trying to restore GPT partition tables:

Having a look at the image’s files on the server, all partitions are marked as fixed in d1.fixed_size_partitions,

Re-reading the post I just saw this. So this seems to be a different issue to what we have fixed in the latest inits. No wonder updating those doesn’t help.

Please schedule a debug capture task on the source machine, boot it up to the shell and run parted -l (l as in lion!) Post a picture of the output here.

aephk

@Sebastian-Roth I’m just re-running a capture with the new inits. It will take quite a bit as it’s around 170GB in size. I’ll give this a go as soon as I can.

aephk

@Quazz I’ve rerun the capture with the new inits but the same issue is present.

@Sebastian-Roth Here is the output of parted -l from a debug capture of the image:
alt text

Sebastian Roth

@aephk From the picture you posted the partition layout looks fine. Not saying that there can’t be another issue but it’s good to know this part seems ok as a start.

Having a look at the image’s files on the server, all partitions are marked as fixed in d1.fixed_size_partitions

I guess we need the details to be able to help. Please post the full contents of the file d1.partitions, d1.minimum.partitions and d1.fixed_size_partitions here.

Checking in Windows on the source drive it only shows 3 partitions, however, FOG seems to be picking it up as having 4 which is odd…

This is ok because Windows disk management doesn’t show partitions marked as hidden.

aephk

@Sebastian-Roth Here is the contents of d1.partitions, d1.minimum.partitions and d1.fixed_size_partitions:

d1.partitions:
label: gpt
label-id: 02B6114B-E445-46A0-B7A7-8C38BA5BB203
device: /dev/sda
unit: sectors
first-lba: 34
last-lba: 468877278

/dev/sda1 : start= 2048, size= 1021952, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=C744BEC7-CF95-4626-A819-48285257F9A9, name=“Basic data partition”, attrs=“RequiredPartition GUID:63”
/dev/sda2 : start= 1024000, size= 204800, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=8546EE7F-82E0-447F-913A-C13E109A61FF, name=“EFI system partition”, attrs=“GUID:63”
/dev/sda3 : start= 1228800, size= 32768, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=C2B8A2B0-B751-402C-BCA3-D19E134D3CD1, name=“Microsoft reserved partition”, attrs=“GUID:63”
/dev/sda4 : start= 1261568, size= 467615232, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=285E434A-1556-455C-B60A-E65C92C9DDAC, name=“Basic data partition”

d1.minimum.partitions:
label: gpt
label-id: 02B6114B-E445-46A0-B7A7-8C38BA5BB203
device: /dev/sda
unit: sectors
first-lba: 34
last-lba: 468877278

/dev/sda1 : start= 2048, size= 1021952, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=C744BEC7-CF95-4626-A819-48285257F9A9, name=“Basic data partition”, attrs=“RequiredPartition GUID:63”
/dev/sda2 : start= 1024000, size= 204800, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=8546EE7F-82E0-447F-913A-C13E109A61FF, name=“EFI system partition”, attrs=“GUID:63”
/dev/sda3 : start= 1228800, size= 32768, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=C2B8A2B0-B751-402C-BCA3-D19E134D3CD1, name=“Microsoft reserved partition”, attrs=“GUID:63”
/dev/sda4 : start= 1261568, size= 467615232, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=285E434A-1556-455C-B60A-E65C92C9DDAC, name=“Basic data partition”

d1.fixed_size_partitions:
1:2:3:4

Sebastian Roth

@aephk Ok, the files show that FOS (FOG OS) does not seem to shrink the fourth partition before capturing. Both, d1.partitions and d1.minimum.partitions are identical which should not be the case.

image “On client” size is showing at around 223GB

How much space is actually used on the disk when you boot up Windows and have a look? Possibly bitlocker is somehow enabled here? Open a cmd shell as administrator and run

manage-bde -status C:
manage-bde -off C:
manage-bde -status C:

Other than that there is no other way than you scheduling a debug capture task for this machine. Boot it up, hit ENTER till you get to the shell and run fog command to start the process. Now step through it and take pictures of it all. Post the pictures here.

aephk

@Sebastian-Roth Hi, here are the photos of the debug capture. After this it just goes on to capture as normal.

alt text

EDIT: If I manually shrink the 4th partition in Windows, run a capture then try to deploy to one of the drives that fails it works fine.

EduardoTSeoane

@aephk
This is not a solution, but maybe can help you.

All our images on the Images store are manually shrinked, we adjust the final size of the partitions from the postdownload script with our own criteria.

We are doing this from fog1.3.2, we are currently on FOG1.5.6.

aephk

I may have found the issue here.

I was curious as to why FOG was refusing to resize the disk, so I thought I’d try a manual resize in linux/gparted. Booting in to the gparted live cd, gparted could see the drive and all of the partitions but it was failing to read the contents of partition 4.

I Googled this and it looks like it may have been caused by bad sectors and running chkdsk /f had fixed it for others so I tried that, went back in to gparted and now everything looked fine. So I’ve run a new capture and it appears to have shrunk the 4th partition as expected. I’m currently deploying it to one of the drives that was failing and all is looking good so far.

I’m not sure what caused the issue in the first place, I hadn’t modified the partition table at all, I had just installed an admittedly fairly large number of programs to an existing image and tried to recapture it.

@Quazz @Sebastian-Roth @EduardoTSeoane Thanks for your help on this folks!

phm2000

hi

I have same problem with fog 1.5.7, is there a solution ?

Thanks

Error trying to restore GPT partition tables

209

12.0k

17.3k

155.2k