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

[rwilsonadvantage]

I have a system, HP Probook 450 g3, that will image just fine, until i install a new crucial 2.5 250gb ssd. Once we do that, the image process fails at"Restoring Partition Tables (GPT) CMD Tried sgdisk -gl /images(correct image path)/d1.mbr /dev/sda." I have tried other hard drives, and it works great, but once i place a crucial 250 gb drive in the system it fails. I have tried 3 of the crucial drives, and get the same result. I can use larger or smaller normal drives (disk), and they work fine, along with m.2 ssd drives.

Yes i know this is a duplicated post, but as i have an entire batch of systems that i can no longer use until i correct the issue, i figured i would try here.

[george1421]

I don’t have an answer for you, but to collect a bit more info, what form factor is this crucial drive? Is it sata, m.2 sata, or nvme?

[Sebastian Roth]

@rwilsonadvantage Is the image type set to resizable or non-resizable?

Please try the following:

• Make sure you have one of the crucial 2.5 250gb SSDs in the target host.
• Schedule a new deploy for this particular host but before you click “Create Task” tick the checkbox for debug.
• Boot up the client and hit ENTER twice to get to the shell - run command fog and step through till you hit the error.
• Now back in the shell manually run sgdisk -gl /images/(correct image path)/d1.mbr /dev/sda, take a picture and post that here.

[Sebastian Roth]

Cross linking the other topic here: https://forums.fogproject.org/topic/13877/gpt-partition-fails-error-code-4-crucial-ssd

[rwilsonadvantage]

@Sebastian-Roth image is set to resizable. We have a very basic config, and only have 1 image. I see the error here, but it is confusing because the image works on the other machines, and this machine with another drive. 

[rwilsonadvantage]

@Sebastian-Roth

[rwilsonadvantage]

@george1421 the drive is 2.5 Sata SSD. Part number CT250MX500SSD1Z.PK01

[george1421]

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

CT250MX500SSD1Z.

Well I was hoping I had one, but I only have MX100s and MX300s here. The thought would be to see if I could duplicate what you are seeing here.

Could you post the output of this command: ls -la /images/Win10HP This will show us what files are in that directory.

Also just as a side note, if you use putty you can ssh into the fog server. It will make it easier to copy and paste text into the fog server’s console.

[rwilsonadvantage]

@george1421

[root@serv-mitch-fog Win10HP]# ls -la
total 44958000
drwxrwxrwx. 2 fogproject root         238 Nov  8 08:52 .
drwxrwxrwx. 5 fogproject root          76 Sep 19 16:11 ..
-rwxrwxrwx. 1 fogproject root           9 Sep 19 15:54 d1.fixed_size_partitions
-rwxrwxrwx. 1 fogproject root     1048576 Nov  8 08:51 d1.mbr
-rwxrwxrwx. 1 fogproject root        1082 Sep 19 15:54 d1.minimum.partitions
-rwxrwxrwx. 1 fogproject root          60 Sep 19 15:54 d1.original.fstypes
-rwxrwxrwx. 1 fogproject root           0 Sep 19 15:54 d1.original.swapuuids
-rwxrwxrwx. 1 fogproject root    31647083 Sep 19 15:54 d1p1.img
-rwxrwxrwx. 1 fogproject root   113433917 Sep 19 15:54 d1p2.img
-rwxrwxrwx. 1 fogproject root 28878471852 Sep 19 16:07 d1p3.img
-rwxrwxrwx. 1 fogproject root   689768015 Sep 19 16:07 d1p4.img
-rwxrwxrwx. 1 fogproject root 16322594957 Sep 19 16:11 d1p5.img
-rwxrwxrwx. 1 fogproject root        1082 Sep 19 15:54 d1.partitions
[root@serv-mitch-fog Win10HP]#

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