Posts made by 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!

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

@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

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

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

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

@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 Sorry, should have said. I’m running FOG 1.5.4, and the clients are using kernel version 4.19.64

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