I'm attempting to rebuild a Mac partition for an external 3TB Hitachi hdd that recently failed to mount. Apart from an unexpected GPT table size which I'll show later, this drive issue seems similar to How to fix Mac hard drive partition showing as Fdisk_partition_scheme.

Here is some background and info. on the drive I've gathered:

Since the drive's enclosure appeared to have a loose connection, it was given a new enclosure. As a precaution and to have a working copy, dd was used to create an image of the entire 3TB drive. For any steps that require a device as input, I attach the image using hdiutil attach -nomount path/to/file.dmg.

The drive was originally formatted with a single partition using Mac OS X Snow Leopard. I found the HFS+ partition type GUID while scanning through the data in the hex editor, Hex Fiend: 53746F72-6167-11AA-AA11-00306543ECAC (Apple Core Storage Container HFS+ FileVault volume container). This was followed by the 1st EFI part entry is at offset 4096: HFS GUID, EFI part

The 1st EFI system partition is at offset 8192: EFI/GPT

I attempted to extract the GPT/EFI and HFS partition information from the above image:

06 00 00 00 00 00 00 00 = 6 (start of EFI).

05 C8 00 00 00 00 00 00 = 51205 (end of EFI).

06 C8 00 00 00 00 00 00 = 51206 (start of HFS).

6F 94 A9 2B 00 00 00 00 = 732533871 (end of HFS).

The secondary EFI system partition at offset 3000592957440 appeared to contain the same start and end values, and the secondary EFI part entry was at offset 3000592973824.

The 1st HFSJ entry was found at offset 209740800: HFSJ

The total # bytes given by diskutil info is 3000592982016: diskutil info

If the HFS main volume size is 732533871 - 51205 = 732482666 blocks, then the logical block size should be 4096 (which gives total # blocks on disk = 732566646). Although a 512 byte block size was given by diskutil info (above image).

Unfortunately gdisk couldn't read the GPT data:

GPT fdisk (gdisk) version 1.0.4 
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: not present

This is what I used as an attempt to start to rebuild the GPT partition table (following How to fix Mac hard drive partition showing as Fdisk_partition_scheme):

sudo dd if=/dev/zero of=/dev/disk2 bs=512 count=40
sudo gpt create /dev/disk2

Then I ran sudo gpt -r show /dev/disk2, which gave an unexpected GPT table size:

  start   size  index  contents
  0      1         PMBR
  1      1         Pri GPT header
  2     18         Pri GPT table
 20      1
 21     18         Sec GPT table
 39      1         Sec GPT header

After the above GPT utility results, I wasn't sure which logical block size to use to rebuild the EFI and HFS partition tables.

Thanks for any help!

1/31/2020 Update

I finished using rsync to make another 3TB disk image copy (I've been keeping the original disk image that was created via dd as a backup).

I think I located the 3rd partition at offset 3000458738688 bytes (it was the 1st data string following the end of the HFS main volume). It appears to end either at offset 3000582143352 or 3000582143360 (any input on this is appreciated): Mac boot partition

Unlike EFI/GPT and HFS, there didn't appear to be start or end addresses in any headers that I could extract for this 3rd boot partition. Note that I added larger partition images to show this. So I'll try using the above estimated byte offsets (converting to sectors/blocks) as input for the 3rd gpt add step.

Thanks again for any feedback!

  • Are you sure you executed the commands sudo dd if=/dev/zero of=/dev/disk2 bs=512 count=40 and sudo gpt create /dev/disk2? I ask because to recreate the results you posted, I would have to execute the commands sudo dd if=/dev/zero of=path/to/file.dmg bs=512 count=40 and sudo gpt create path/to/file.dmg. Commented Jan 26, 2020 at 21:36
  • @DavidAnderson, Thank you for your answer. I will try it as soon as I re-create the full disk image file (it should take a couple of days to make another copy of my original to work with). You are correct that I actually ran those commands on the image rather than the device. I'll be sure to run them on the device next time following your instructions. Would 'gpt destroy disk2' still work as intended if the GPT utility can't detect the GPT headers (when I ran 'gpt recover', it gave 'no primary or secondary GPT headers, can't recover')?
    – Leslie
    Commented Jan 28, 2020 at 0:34
  • When I was testing the steps you posted in your question, the command sudo dd if=/dev/zero of=/dev/disk2 bs=512 count=40 was not sufficient enough to be able to execute sudo gpt create /dev/disk2. I assume the reason for this was there still existed a secondary GPT at the end of the drive. The sudo gpt destroy /dev/disk2 command was required. Using gpt destroy before gpt create may not alway be necessary, but entering the command should do no harm. Commented Jan 29, 2020 at 0:27
  • @DavidAnderson- Unfortunately the step gpt destroy /dev/disk2 gave this message: gpt destroy: /dev/disk2: error: device doesn't contain a GPT . So I may have to try using the dd option. I realized in my initial attempt I neglected to include conv=notrunc , which I'm guessing is what truncated the image. To use dd to overwrite the primary and secondary GPT, how much of the end of the disk image would you recommend I overwrite with zeros (just the secondary GPT or everything after the HFS main volume)?
    – Leslie
    Commented Feb 4, 2020 at 2:54
  • You should have ignored the error message and proceeded to enter the gpt create /dev/disk2 command. I tried to indicate the gpt destroy /dev/disk2 command may not be necessary. Commented Feb 4, 2020 at 4:45

1 Answer 1


Based on the latest information posted in the question, here is what to enter. The assumption is the values posted are correct. The drive used a 4096 sector size. Since image files are fixed at a 512 byte sector size, all the values need to be multiplied by 8.

Note: You may get an error message when entering the command to destroy the GPT. You should ignore this message.

sudo chown $USER:staff path/to/file.dmg
hdiutil attach -nomount path/to/file.dmg
gpt destroy disk2
gpt create disk2
gpt add -i 1 -b $((6*8)) -s $(((51205-6+1)*8)) -t efi disk2
gpt add -i 2 -b $((51206*8)) -s $(((732533871-51206+1)*8)) -t hfs disk2
diskutil mount disk3

The GPT you posed has a partition type GUID for Core Storage, but the header you posted for this partition indicates the partition type GUID should be for a Hierarchical File System Plus (HFS+) partition. My answer assumed the header is correct.


The 16,384 byte size requirement for the GPT Partition Entry Array is defined in section 5.3.1 "GPT overview" on page 117 of the Unified Extensible Firmware Interface (UEFI) Specification version 2.8, March 2019.

Technical Note TN1150: HFS Plus Volume Format

GUID Partition Table


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .