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:
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.
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!
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):
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!