SSD fails at Restoring Partition Tables (GPT) with error code 4

[george1421]

@rwilsonadvantage I think you missed a step in Sebastian’s’ instructions. At the FOS Linux command prompt you needed to key in fog and then single step through the deployment until you see the error then exit by hitting ctrl-C to exit the script before the system reboots.

The file not found message was because the target computer hadn’t connected back to the fog server until the error is thrown. You can confirm that the target computer is connected back to the fog server by (on the fos linux target computer) keying in the same ls -la /images If the directory isn’t found or is blank then the fog server isn’t connected. If it returns values then you are at the point where you can run the sgdisk command. You will need to take a screen shot of that error.

[rwilsonadvantage]

@george1421
You are completely correct. I missed that completely. I am attaching both outputs here. I am also attaching the output for the image in fog itself, that way you can see it also.

[george1421]

@rwilsonadvantage The second picture explains what is wrong. Basically the captured image is to big to fit onto the 250GB disk by 8,000,000 blocks.

So what size was the disk on the source computer (i.e. where the image was captured from)? The thing you have to keep in mind is that a 250GB disk is not exactly 250GB in size.

When Sebastian gets back on line he may ask you to cat the files d1.fixed_size_partitions, d1.partitions and d1.minimum.partitions from /images/Win10HP on the fog server. These files tell a bit more about the geometry of the source system.

[rwilsonadvantage]

@george1421
Ok, quick question, with it “resizable” shouldn’t that correct the issue? The image is only 60gb or so, and the ssd is 250. The source should have been a 256 ssd. but i am pulling to confirm.

[rwilsonadvantage]

@george1421
So i double checked the source, and it was pulled from a 256 sdd, but in looking at the dis structure, i found 2 “OEM” Partitions that were located at the end of the drive. I have deleted those, and am pulling an image now. I hope that solves the issue. I will keep everyone posted.

[Sebastian Roth]

@rwilsonadvantage said in SSD fails at Restoring Partition Tables (GPT) with error code 4:

i found 2 “OEM” Partitions that were located at the end of the drive. I have deleted those, and am pulling an image now. I hope that solves the issue.

Right there! I am fairly sure that will help.

FOG doesn’t want to move those partitions because some of the OEM recovery partitions need to stay on the same sector or wouldn’t work.

[rwilsonadvantage]

@Sebastian-Roth
Since we aren’t using them, we are “hoping” they aren’t needed. Fingers crossed, last set of updates before the new image pull.

[george1421]

@rwilsonadvantage In the FWIW bucket, when we build our golden image (using MDT), we configure MDT to not create the recover partition so we don’t have that non-movable partition a the end of the disk, leaving the drive the ability to expand or shrink to the size of the destination media as its the last partition on the disk.

[rwilsonadvantage]

@Sebastian-Roth
HUZZAH!!! A man of Quality!! the image was able to pull once i was able to remove the old partitions. You guys are awesome!!! How do i mark this as solved?

[Sebastian Roth]

@rwilsonadvantage You are welcome! I just marked it as solved (Topic Tools -> Mark as solved, not sure if you have access to this).