Error trying to restore GPT partition tables

[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:

[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.

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

[Sebastian Roth]

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

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

Sorry but with this kind of problem there is no general solution that works for everyone. Please open your own topic in the forums and post all your own details: full contents of the file d1.partitions, d1.minimum.partitions and d1.fixed_size_partitions.