MacOSX Fix damaged partition map

Question

I recently completely crashed my system by plugging an 11.1v power source into the USB unintentionally frying the machine. I have since replaced the machine and went to transfer my information from the old HD when I discovered that the partition map is damaged.

I have spent some time researching the fix, spending time reading the following questions:

How Can I Fix My Partition Table

How to fix Mac hard drive partition showing as FDisk_partition_scheme

How to fix GUID hard drive corrupted to MBR

Recovering OS X partition: wrong boundaries calculated, can't mount disk0s2

Missing Mac partitions - unrecognized file system

diskutil list shows this is the disk in question:

/dev/disk3 (external, physical):
#:                       TYPE NAME                    SIZE       IDENTIFIER
0:     FDisk_partition_scheme                        *1.0 TB     disk3
1:                       0xEE                         1.0 TB     disk3s1

sudo gpt -r show disk3 gets the following:

      start       size  index  contents
      0          1         PMBR
      1  244190645       

And a hexdump sudo dd if=/dev/disk3 bs=512 skip=409640 count=1 | hexdump results in:

1+0 records in
1+0 records out
0000000 97 3a 51 22 3c 4f 4f 76 01 00 00 00 00 00 00 00
0000010 9e 71 d0 00 00 00 00 00 01 00 00 80 00 00 00 00
512 bytes transferred in 0.001052 secs (486627 bytes/sec)
0000020 4e 58 53 42 00 10 00 00 ac 45 8d 0e 00 00 00 00
0000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0000040 02 00 00 00 00 00 00 00 6d 9f 9e a8 cf 71 46 7b
0000050 85 9c e5 df 32 15 1b a2 33 30 a7 00 00 00 00 00
0000060 9f 71 d0 00 00 00 00 00 18 01 00 00 5c 6c 00 00
0000070 e7 10 03 00 00 00 00 00 86 4c 02 00 00 00 00 00
0000080 0e 01 00 00 d0 3b 00 00 0b 01 00 00 03 00 00 00
0000090 13 3b 00 00 bd 00 00 00 f6 11 00 00 00 00 00 00
00000a0 83 8e 14 00 00 00 00 00 01 04 00 00 00 00 00 00
00000b0 00 00 00 00 64 00 00 00 03 04 00 00 00 00 00 00
00000c0 eb 11 00 00 00 00 00 00 ed 11 00 00 00 00 00 00
00000d0 ae af 00 00 00 00 00 00 b8 b8 00 00 00 00 00 00
00000e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
*
0000200

Here is diskutil info /dev/disk3:

   Device Identifier:         disk3
   Device Node:               /dev/disk3
   Whole:                     Yes
   Part of Whole:             disk3
   Device / Media Name:       500SSD1
Volume Name:               Not applicable (no file system)
   Mounted:                   Not applicable (no file system)
   File System:               None
Content (IOContent):       FDisk_partition_scheme
   OS Can Be Installed:       No
   Media Type:                Generic
   Protocol:                  USB
   SMART Status:              Not Supported
Disk Size:                 1.0 TB (1000204886016 Bytes) (exactly 1953525168 512-Byte-Units)
   Device Block Size:         4096 Bytes
Read-Only Media:           No
   Read-Only Volume:          Not applicable (no file system)
Device Location:           External
   Removable Media:           Fixed
Solid State:               Info not available
   Virtual:                   No

And lastly fdisk /dev/disk3:

Disk: disk3 geometry: 15200/255/63 [244190646 sectors]
Sector size: 4096 bytes
Signature: 0xAA55
     Starting       Ending
#: id  cyl  hd sec -  cyl  hd sec [     start -       size]
------------------------------------------------------------------------
1: EE 1023 254  63 - 1023 254  63 [         1 - 1953525167] <Unknown ID>
2: 00    0   0   0 -    0   0   0 [         0 -          0] unused      
3: 00    0   0   0 -    0   0   0 [         0 -          0] unused      
4: 00    0   0   0 -    0   0   0 [         0 -          0] unused      

I have wxHexEditor installed and can post the screenshots here if needed. My understanding is basically I need to replace the GUID Partition Map with the proper partitions. The disk had two only two partitions - the standard EFI System Partition and then the other one. Drive is a Crucial MX500 SSD 1 TB.

Can someone please help with the calculations and commands to restore the partitions?

Answer 1

The output you have posted does not indicate any problems with the partition map. The output does indicate the drive is in the wrong USB drive enclosure. The drive has a 512 byte sector size and the USB enclosure is silently converting 512 byte sectors to 4096 byte sectors. Your best option here is to find an enclosure that does not do this conversion. Otherwise, proceed as follows.

Note: The OP indicated in a comment that the problem was solved by changing enclosures. Therefore, the answer below was never used.

Below is what the output from gpt -r show disk0 looked like when the drive was being used by the now fried the machine.

    start       size  index  contents
          0          1         PMBR
          1          1         Pri GPT header
          2         32         Pri GPT table
         34          6         
         40     409600      1  GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B
     409640 1953115488      2  GPT part - 7C3457EF-0000-11AA-AA11-00306543ECAC
 1953525128          7         
 1953525135         32         Sec GPT table
 1953525167          1         Sec GPT header

The two partition entries shown in the above table can be converted from a 512 byte sector size to a 4096 byte sector size by dividing by 8. The result is shown below.

          5      51200      1  GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B
      51205  244139436      2  GPT part - 7C3457EF-0000-11AA-AA11-00306543ECAC

If you create a new empty GPT, then output from gpt -r show disk3 will look like the following.

      start       size  index  contents
          0          1         PMBR
          1          1         Pri GPT header
          2          4         Pri GPT table
          6  244190635
  244190641          4         Sec GPT table
  244190645          1         Sec GPT header

At this point two problems are revealed:

• Creating a new empty GPT will overwrite the first 4096 byte sector of the first partition on the drive. This would be the FAT32 formatted EFI partition.

• The size in 4096 bytes sectors of EFI partition is 51200. This is below the minimum of 65527 required by the FAT32 format. This is stated in the Microsoft article UEFI/GPT-based hard drive partitions. The pertinent part is shown below.

  

So, either problem separately or together results in an unusable EFI partition. If you are only interested in mounting the APFS volume(s), then you can enter the commands given below. These commands were derived from klanomath's answer to the question How to fix Mac hard drive partition showing as FDisk_partition_scheme.

Note: You will only be adding the APFS container to the new GPT.

Below I assume your external drive is still disk3.

sudo dd if=/dev/zero bs=4096 count=6 of=/dev/disk3 
sudo gpt create /dev/disk3
sudo gpt add -b 51205 -i 1 -s 244139436 -t apfs disk3

Steps Needed to Move the EFI Partition

Note: Since the OP indicated interest in transfer information from the old HD, I only outlined the steps. I assume the OP is going to erase the entire drive once the information is transferred. If so, then the OP can ignore this section.

These steps leave the EFI partition at the end of the drive. When testing formatting operations which require an EFI partition, macOS seems to accept an EFI partition that is not at the beginning of the drive.

1. Use the Disk Utility to create a sparse disk image of a large enough drive so a EFI partition would be automatically created.
2. Use the dd command to copy the EFI partition from the external drive to EFI partition in the disk image.
3. Create the empty GPT, then add the APFS partition.
4. Use the diskutil command to shrink the APFS partition by at least 300 MiB.
5. Use the gpt command to create a 300 MiB EFI partition below the APFS partition.
6. Use the newfs_msdos to FAT32 format the new EFI partition with the volume label EFI.
7. Mount both EFI partitions and use the Finder to copy the contents from EFI partition on the disk image to the EFI partition on the external drive.
8. Unmount both EFI partitions, then eject the disk image and place sparse disk image file in the trash.

Other References

USB adapters silently change sector size