HFS+ invalid number of allocation blocks
https://apple.stackexchange.com/questions/176777
-
07-10-2020 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianQuestion
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
Solution
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!
