HFS+ invalid number of allocation blocks Okay so a few days ago I wanted to install Ubuntu GNOME over regular Ubuntu and it gave me the option to automatically overwrite my Ubuntu installation (that I had on a separate partition from my OS X Yosemite). After I installed GNOME this way though, it appeared that the installer also removed my OS X partition. 

Since then I've tried various things to recover my Mac partition, I've used TestDisk to find the sectors and gdisk to recreate the partition table (and partitions). The problem is that I can't mount these new partitions. I've tried fsck.hfsplus to repair the partition but it gives me the following error (booted from GNOME trial USB):

ubuntu-gnome@ubuntu-gnome:~$ sudo fsck.hfsplus /dev/sda2
** /dev/sda2
** Checking HFS Plus volume.
   Invalid number of allocation blocks
(4294967295, 0)
** Volume check failed.


Here are my testdisk results:


Here are the partitions I made in gdisk:

Number  Start (sector)    End (sector)  Size       Code  Name
   1              34          409633   200.0 MiB   EF00  EFI System Partition
   2          411648      1164570455   555.1 GiB   AF00  Apple HFS/HFS+
   3      1165256704      1166528119   620.8 MiB   AF00  Apple HFS/HFS+
   4      1166528512      1182543855   7.6 GiB     8200  Linux swap
   5      1182543872      1465147391   134.8 GiB   8300  Linux filesystem


Here are the different outputs after booting to Internet Recovery Mode:

diskutil list:

-bash-3.2# diskutil list /dev/disk0
   #:                        TYPE NAME                    SIZE        IDENTIFIER
   0:       GUID_partition_scheme                         *750.2 GB   disk0
   1:                         EFI                          209.7 MB   disk0s1
   2:                   Apple_HFS                          596.0 GB   disk0s2
   3:                   Apple_HFS                          651.0 MB   disk0s3
   4:                  Linux Swap                          8.2 GB     disk0s4
   5: 0FC63DAF-8483-4772-8E79-3D69D8477DE4                 144.7 GB   disk0s5
/dev/disk1
   #:                        TYPE NAME                    SIZE        IDENTIFIER
   0:      Apple_partition_scheme                         *1.2 GB     disk1
   1:         Apple_partition_map                          30.7 KB    disk1s1
   2:                   Apple_HFS Mac OS X Base System     1.2 GB     disk1s2

/dev/disk2-disk12 are part of the recovery system and irrelevant here


diskutil cs list:

No CoreStorage logical volume groups found


gpt -r -vv show /dev/disk0:

-bash-3.2# gpt -r -vv show /dev/disk0
gpt show: /dev/disk0: mediasize=750156374016; sectorsize=512; blocks=1465149168
gpt show: /dev/disk0: PMBR at sector 0
gpt show: /dev/disk0: Pri GPT at sector 1
gpt show: /dev/disk0: Sec GPT at sector 1465149167
       start        size index contents
           0           1       PMBR
           1           1       Pri GPT header
           2          32       Pri GPT table
          34      409600     1 GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B
      409634        2014                                                     
      411648  1164158808     2 GPT part - 48465300-0000-11AA-AA11-00306543ECAC
  1164570456      686248
  1165256704     1271416     3 GPT part - 48465300-0000-11AA-AA11-00306543ECAC
  1166528120         392
  1166528512    16015344     4 GPT part - 0657FD6D-A4AB-43C4-84E5-0933C84B4F4F
  1182543856          16
  1182543872   282603520     5 GPT part - 0FC63DAF-8483-4772-8E79-3D69D8477DE4
  1465147392        1743
  1465149135          32       Sec GPT table
  1465149167           1       Sec GPT header
In my opinion "TestDisk" hosed your GPT.

Please compare the TestDisk result with my disks. The disks in my example are equally sized, disk0 contains a CoreStorage partition and disk2 an old-style JHFS+ partition. I'm using two separate disks because it's unknown (at least to me) which formatting type (CS or JHFS+) was used originally.

The PMBR/GPT and the first three partitions (EFI/Macintosh HD/Recovery HD) should look like this, if you had a CoreStorage partition previously:

    root# gpt -r -vv show disk0
gpt show: disk0: mediasize=68719476736; sectorsize=512; blocks=134217728
gpt show: disk0: PMBR at sector 0
gpt show: disk0: Pri GPT at sector 1
gpt show: disk0: Sec GPT at sector 134217727
      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  132538512      2  GPT part - 53746F72-6167-11AA-AA11-00306543ECAC
  132948152    1269536      3  GPT part - 426F6F74-0000-11AA-AA11-00306543ECAC


or like this, if you had a classical JHFS+ volume previously:

root# gpt -r -vv show disk2
gpt show: disk2: mediasize=68719476736; sectorsize=512; blocks=134217728
gpt show: disk2: PMBR at sector 0
gpt show: disk2: Pri GPT at sector 1
gpt show: disk2: Sec GPT at sector 134217727
      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  132538512      2  GPT part - 48465300-0000-11AA-AA11-00306543ECAC
  132948152    1269536      3  GPT part - 426F6F74-0000-11AA-AA11-00306543ECAC


(Please consider that the mediasize, the blocks, the sector of the secondary GPT, the size of the 2nd volume and the start block of the 3rd volume are different to yours, because i use smaller example disks here.)

Your problem should be solved by rewriting the GPT once more.

Preparation:

Install a full vanilla system (Mavericks or Yosemite should work) on a thumb drive (or an external drive). A recovery system will not work. Boot to the thumb drive, download and install wxHexEditor. Enable the root user and log-in as root.

Hint: While working with wxHexEditor don't use copy and paste. Enter everything manually! You might accidentally write directly to your disk.

JHFS+ or CoreStorage partition?

First you have to determine, if you had a JHFS+ or CoreStorage partition at index number 2.

Open the Calculator. Open wxHexEditor. Check that you work in read-only mode ("Options" -> "File mode" -> "Read only"). In the menubar go to "Devices" -> "Open disk device" -> choose the appropriate diskNumber. Probably it's disk0. The disk should have further partitions (disk0s1 - disk0s5). Please try to arrange the wxHexEditor window like in the examples below with straight red lines.

Then hit the "Go to offset"-button (marked with the green circle) and enter 409640 exactly like in the picture below. Sometimes you have do that twice to jump to the correct sector. Re-check the correct sector by entering the offset (marked red) in the Calculator and divide it through 512.

The first 3 sectors of a CoreStorage partition look like this:



The first 3 sectors of a JHFS+ look like this:



If you get a fundamentally different picture stop here.

Where does the EFI partition start?

Hit the "Go to offset"-button and enter 40 exactly like in the picture below:



If you see the same entries like in the picture above (XEBSD  4.4...EFI...FAT32) this is the start sector of your EFI-Partition. If there are only zeros this could be valid too.

Where does the Recovery HD partition start?

That's probably the most difficult part because you have to find a string which is not very specific.
Jump almost to the end of your 2nd partition (in your case ~400 MB/781250 sectors less than 1164570456 = 1163789206)

Then enter "HFSJ" like in the picture below, search for this string two times and make notes of the different offsets:



You may have two really different results depending on the partition type:


Calculate the sector number of the first finding. In my example (see picture above) it's 68069452800/512=132948150.
Continue searching and calculate the sector of the second finding. In my case it was 68069454848/512=132948154 (no picture).
The difference between the two finding is 4 blocks (=2 KB).

This is typical for the boundary between a JHFS+ partition and the Recovery HD.
The Recovery HD starts then at the sector of the second finding - 2 (in my example 132948154-2=132948152).
Calculate the sector number of the first finding. In my example it was 67733904384/512=132292782 (no picture).
Continue searching and calculate the sector of the second finding. In my case it was 68069454848/512=132948154 (no picture).
The difference between the two findings is 655372 (~336 MB)

This is typical for the boundary between a CoreStorage partition and the Recovery HD.
The Recovery HD starts then at the sector of the second finding - 2 (in my example 132948154-2=132948152).


With those results you should be able to restore your GPT properly. Quit wxHexEditor. If you are asked to save changes don't save them!.

Rebuild a proper GPT

Here i assume the identifier of your main disk is disk0.
First you have to unmount your main disk:

diskutil umountDisk disk0


Check the partition layout then remove the first three partitions:

gpt -r -vv show /dev/disk0

gpt remove -i 3 disk0
gpt remove -i 2 disk0
gpt remove -i 1 disk0


Since the EFI and the Recovery HD usually have fixed sizes we can calculate the start and end block of your main volume.

First we rebuild the EFI with:

gpt add -b 40 -i 1 -s 409600 -t C12A7328-F81F-11D2-BA4B-00A0C93EC93B disk0


Then we calculate the size of the main volume: the start block is 409640.
The end block has been found in the section "Where does the Recovery HD partition start?": 1 less than the start block of the Recovery HD.
The size is then StartBlockOfRecoveryHD-409640.

If you've found a classical JHFS+ earlier the following command should fix partition 2:

gpt add -b 409640 -i 2 -s StartBlockOfRecoveryHD-409640 -t 48465300-0000-11AA-AA11-00306543ECAC disk0


If you've found a CoreStorage partition earlier the following command should fix partition 2:

gpt add -b 409640 -i 2 -s StartBlockOfRecoveryHD-409640 -t 53746F72-6167-11AA-AA11-00306543ECAC disk0


To rebuild the Recovery HD enter:

gpt add -b StartBlockOfRecoveryHD -i 3 -s 1269536 -t 426F6F74-0000-11AA-AA11-00306543ECAC disk0


Remount disk0 with:

diskutil mountDisk disk0


Quit Terminal, start Disk Utility and check your main volume (probably Macintosh HD) for errors and try to repair them if necessary.
If you've found a CoreStorage partition earlier, you might have to reboot to your thumb drive before repairing the volumes with Disk Utility, because the CoreStorage logical volume might not be recognized/mounted properly. In your setup - 1 main disk and the thumb drive - the logical volume should be disk2.

I hope this solves your problems.

If you run into problems (e.g you can't find the proper starting sector of your Recovery HD), have doubts or questions immediately stop and contact me with a comment @klanomath!