GPT looks valid. Diskutil sees empty disk

disk-utilitydiskutilfilesystemhard drivepartition

External 3 TB disk.

Stopped working after a power bump.

GPT reports as follows:

bash-3.2# gpt show /dev/disk6
       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  2930266584      2  GPT part - 48465300-0000-11AA-AA11-00306543ECAC
  2930676224      262144         
  2930938368  2929332616      3  GPT part - 48465300-0000-11AA-AA11-00306543ECAC
  5860270984      262151         
  5860533135          32         Sec GPT table
  5860533167           1         Sec GPT header

This looks normal.

bash-3.2# diskutil repairDisk /dev/disk6
Nonexistent, unknown, or damaged partition map scheme
If you are sure this disk contains a (damaged) APM, MBR, or GPT partition map,
you can hereby try to repair it enough to be recognized as a map; another
"diskutil repairDisk /dev/disk6" might then be necessary for further repairs
Proceed? (y/N) y
Partition map repair complete; you might now want to repeat the
verifyDisk or repairDisk verbs to perform further checks and repairs

Repeating this makes no change.

DiskUtil reports as follows:

bash-3.2# diskutil list /dev/disk6 /dev/disk6    #:                   
TYPE NAME                    SIZE       IDENTIFIER    0:    *3.0 TB     disk6

I figured that it might be a bad PMBR. From all accounts, this is just an MBR with a non-bootable partition in it. I created an HFS disk on a USB stick, and copied the MBR (dd if=/dev/disk7 count=1 of=/dev/disk6) to the ailing disk.

I used R-Studio to scan the disk. R-Studio finds files and directories and such.

Ran TestDisk (separate command line disk utility) It's numbers agreed with GPT's.

I then used dd to make a backup of the first 34 blocks of the disk, and used gpt to destroy and recreate the partition table.

  604  gpt destroy /dev/disk6
  605  gpt create /dev/disk6
  606  gpt show /dev/disk6
  ...
  610  gpt add -b 40 -s 409600 -i 1 -t efi /dev/disk6
  611  gpt add -b 409640 -s 2930266584 -i 2 -t hfs /dev/disk6
  612  gpt add -b 2930938368  -s 2929332616 -i 3 -t hfs /dev/disk6
  613  gpt show /dev/disk6

No joy. I'm missing something here.

Best Answer

The problem turned out to be the PMBR. My first attempt was to copy sector 0 off a GPT formatted memory stick.

Examined that with fdisk and it had partition of type EE, but start and end cylinders were the same.

I edited partition 1 and accepted defaults.

fdisk on mac will report "can't get exclusive access to write sector back, reboot required" It lies. You don't have to reboot.

After doing this diskutil was able to see both partitions.

I was unable to repair the first partition, used for time machine, and ended up reformatting it. (Even after it was a recognizable partition, diskutil would start on it, and give up in a few seconds.) (I didn't try very hard. The really important stuff is stored on drop box, on a mirrored disk on another machine.)

@Klanomath deserves credit for GPT disk. I had found this, but missed the fact that it provided Mac binaries. I'm not used to binaries on Source forge. GPT disk appears to be a useful tool for dealing with this sort of situation. It would have been a better way to go.

Related Question