MacOS – Recovering OS X partition: wrong boundaries calculated, can’t mount disk0s2

bootmacospartition

I followed the strategy of Klanomath (see link) in order to recover my lost OSX (el Capitan) partition (MBR overwritten by bootcamp Windows). In this procedure you have to find the right boundaries of your partition. But when I got my boundaries and created my partition, disk0s2 did not want to mount. This means the boundaries are not good.

This is my situation at the moment:

CJs-MacBook-Pro:~ root# gpt -r show /dev/disk0
      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  495406233      2  GPT part - 53746F72-6167-11AA-AA11-00306543ECAC
  495815873    1269536      3  GPT part - 426F6F74-0000-11AA-AA11-00306543ECAC
  497085409  302914591         
  800000000  100000000      4  GPT part - 48465300-0000-11AA-AA11-00306543ECAC
  900000000    1269536      5  GPT part - 426F6F74-0000-11AA-AA11-00306543ECAC
  901269536   75503599         
  976773135         32         Sec GPT table
  976773167          1         Sec GPT header
CJs-MacBook-Pro:~ root# diskutil list
/dev/disk0
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *500.1 GB   disk0
   1:                        EFI                         209.7 MB   disk0s1
   2:          Apple_CoreStorage                         253.6 GB   disk0s2
   3:                 Apple_Boot                         650.0 MB   disk0s3
   4:                  Apple_HFS TempSystem              51.2 GB    disk0s4
   5:                 Apple_Boot Recovery HD             650.0 MB   disk0s5
CJs-MacBook-Pro:~ root# 

The borders I found:

  • 1st HFSJ: 249128179712/512 = block 486578476
  • 2nd HFSJ: 253857728000/512 = block 495815875

Do you have any suggestions?

Best Answer

The solution here is more or less the same as outlined in the answer to this question. The solution there is a stopgap solution because the asking person neither had a thumb drive nor an external disk or a second Mac. You have to have a system drive with a full OS X to install additional apps like wxHexEditor to inspect the raw data on the drive. So the only practicable way there was an OS X install on the corrupted drive with the risk to overwrite the old "lost" partitions.


If you have a second boot device like an external disk or a thumb drive install a newer full OS X (not just a bootable installer thumb drive!). Additionally install wxHexEditor. Enable the root user, log in as root.

Now open wxHexEditor and determine the boundaries of the "lost" Recovery HD. Overwriting the original GUID partition table and replacing it by an MBR with Windows' Disk Management usually doesn't touch the content of your disk. The old data structures are still on the disk and can be found by searching for special strings and files' content.

The asking person gave the following information: the Windows partition had a size of 100 GB. This facilitates the search because the first ~390 GB (of the 500 GB disk) can be skipped since the Windows partition is created at the end of a disk.

The Recovery HD partition has the following content:

  0-1. block:        0x00s
    2. block:        the string "HFSJ" in the first 16 Bytes
    8. block:        0xFFs (probably an allocation file)
11-13. block:        0xFFs (probably a second allocation file)

If you have found these blocks you can easily determine the start block of the Recovery HD as described in the linked answer. Since all other partitions (EFI and the main OS X volume - assuming that only one main volume exists) are determined by the first block of the Recovery HD the math can be done.


The final solution was:

gpt add -b 409640 -i 2 -s 779781456 -t 53746F72-6167-11AA-AA11-00306543ECAC /dev/disk0
gpt add -b 780191096 -i 3 -s 1269536 -t 426F6F74-0000-11AA-AA11-00306543ECAC /dev/disk0

After verifying the volumes with:

diskutil verifyVolume disk0s2
diskutil verifyVolume disk0s3

and removing temporary partitions the main volume was finally expanded to span the whole disk with:

diskutil cs resizeStack lvUUID 0g