Need to recover SSD partition table using Gdisk on Samsung 512GB on MBP MID 2015

Since you posted this in the Bootcamp forum, I will assume that you have Windows and macOS both on the SSD. If that is the case, and if the GPT table entries are invalid, there is a default configuration for Apple SSDs.

The disk partition typically starts at sector 40, with EFI being 409600 sectors (~200MB). The first 40 sectors contain the primary GPT table and some padding. The secondary GPT table is at the end of the disk in a reverse layout.

We can build a default primary GPT table. Once that is done, we can use Testdisk to scan and see what it can find.

Be aware that there is a second layout which is also used which has an EFI partition of 314.6 MB. It should still begin at sector 40.

BackBay wrote:

Ok ran this

sudo dd id=/dev/rdisk0 count=5 2>/dev/null | hexdump -C

And it went right back to the command line prompt. I don't think any process is working

You missed typed "id=" should be "if=". No need to be that complicated. You can use this command:

sudo  hexdump  -C  /dev/disk0

Or if you want a native macOS solution:

sudo  xxd  /dev/disk0

BackBay wrote:

As far as making a back up I still must see if GNU needs to be mounted. I tread CCC and it would not recognize the owc enclosure.. it takes time for the owc enclosure (with the original Samsung SSD) to even be recognized on current booted up HD and in disk util. Also disk util will not make an image of it either it just runs the program and seems to not produce anything.

I highly recommend using GNU ddrescue if you already have Homebrew installed. GNU ddrescue does not need a mounted drive/volume. GNU ddrescue also allows you to see the progress as well as resume the clone if it is interrupted (as long as you use the logging/mapping file option). Just make sure to get the source & destination correct since it doesn't use the "if=" and "of=" options, but instead uses relative location (first file/device is the source input, the second file/device is the destination, and the third file is is the logging file). You can also use the "--ask" option to prompt you for confirmation of the command (and it shows what will happen).

BackBay wrote:

Thx for catching that typo. I am now running

sudo dd if=/dev/rdisk2 count=5 2>/dev/null | hexdump -C

(the SSD im trying to fix is listed as Disk 2 in DiskUtil)

It is still running.

As far as using GNU

I nothing against it but if it is a cloning method then it wont work and (dd) may be the better option.

GNU ddrescue is basically an updated and better version of "dd". It is basically "dd" on steroids. There are some cases where "dd" is the better or easier option.

This is because, as wacky as this sounds, when I install the new OWC 480GB aura SSD (which works fine) the owc external case with the factory installed Samsung SSD will not show up. I originally intended to clone it this way but

1 I could never get the Samsung to show up when the OWC aura SSD was installed, and;

2 The CCC software and the diskutility would never recognize the external drive to image/clone.

CCC & Disk Utility need a mounted volume to clone. Like "dd", GNU ddrescue does not need a drive to be mounted in order to access the physical drive which is why I suggested its use when you mentioned you wanted to clone the SSD.

Definitely contact OWC tech support if you are unsure if the product is compatible with your hardware. I find OWC tech support to be very friendly and helpful.

I agree with @LonerT that the Apple SSD likely has a controller issue if it is getting extremely hot. Most of the SSD failures I have encountered have involved not being able to communicate with the SSD at all (regardless of the OS used). macOS is very particular and can even refuse to operate when the Apple hardware isn't working as expected so it doesn't surprise me that macOS may not see the SSD when installed internally. Plus by installing the SSD in a USB enclosure you are blocking some of the natural communication with the SSD. Really hard to say why one works and the other does not without gathering more information using a Linux boot disk.

It may be interesting to create a bootable Knoppix Linux USB drive to see whether Linux is able to detect the bad SSD when the bad SSD is internally. You can also use Knoppix to perform the clone using GNU ddrescue since Knoppix includes this utility by default. If you are interested in this method instead let me know since the directions are just slightly different than the ones I provided for macOS below.

In my previous post I provided a template for the command you can use with ddrescue at least on the first pass. If errors are encountered and you need to run another pass in an attempt to read any troublesome blocks, then the command should be modified by removing the " -n " option flag.

If you are cloning directly to another bare drive instead of a raw image file you may need to add the " -f " option flag after the " -n " option flag in order to force the utility to overwrite existing data on the destination drive. I believe the utility will alert you if this necessary.

This command will clone the SSD to a raw image file on your Desktop called "samsung-clone.img" along with "mapping-file.txt" which is needed if you restart an interrupted clone or to start another pass (see the previous post for some more information about this command and what you need to customize such as replacing "diskN" with the correct drive identifier):

sudo  ddrescue  --ask  -n  /dev/diskN   ~/Desktop/samsung-clone.img   ~/Desktop/mapping-file.txt

If you are going to clone the bad SSD to another equal or larger drive, then you need to modify the destination to point to the correct drive identifier for the destination drive which must not be mounted or ejected. To unmount a drive without ejecting the drive you need to use the following command (replacing the "Y" in "diskY" with the correct drive identifier):

diskutil  unmountDisk  diskY

Then you would use this template to clone to another bare drive:

sudo  ddrescue  --ask  -n  -f  /dev/diskN   /dev/diskY   ~/Desktop/mapping-file.txt

Notice I added the " -f " option flag to force the utility to overwrite data on the destination drive "diskY". I also modified the destination parameter from a raw image file on the Desktop to "/dev/diskY" which is the physical drive identified as "diskY". If you mix up the source & destinations, then you will overwrite your data (assuming it still exists) so be very careful.

This is all you really should need for your situation regarding ddrescue. I do recommend at least browsing the ddrescue manual on the website just to understand the basics of how the utility works and which parameters are for the source, destination, and mapping file. You do not need to read everything (I actually skimmed & skipped serveral sections myself).

As for downloading GNU ddrescue I suggest installing Homebrew so that you can access the newest version of GNU ddrescue when using macOS. Follow the instructions on the Homebrew website for installing Homebrew itself:

https://brew.sh/

To install Homebrew you can just cut & paste this command directly into macOS Terminal app (If you cut & paste this command from their website make sure not to include the leading "$" character which I've removed here):

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install.sh)"

Once Home brew is installed it is very easy to install GNU ddrescue with the following command:

brew  install  ddrescue

FYI, I make it a point in my posts here to emphasize it is "GNU ddrescue" since there is another version of this utility just called "ddrescue" as well which isn't as good or the same utility. I'm not even sure if this other version still exists, but I want to ensure people use the correct utility. It is Ok for others to just reference it as "ddrescue" for simplicity.