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
   #:                       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?

  • Welcome to Ask Different. Could you edit this to link to the relevant discussion or steps you are following? Also be sure to add a specific (and hopefully narrow) question or description of what you hope to accomplish and what you see as your roadblock to success.
    – bmike
    Mar 9 '16 at 20:03
  • thank you for organizing the text! I was just figuring out how. Do you think you can help me? Do you need any more information?
    – Coen Bosch
    Mar 9 '16 at 21:25
  • What do you want? To wipe all and start over? to remove one partition? Be sure to edit that into the post so everyone can see what you're looking for
    – bmike
    Mar 9 '16 at 21:39
  • @CoenBosch Usually there is no empty space between disk0s2 and disk0s3. Your partition table shows an unallocated disk space of 495815873-495406233=409640 blocks. Additionally start block and size of a normal partition are dividable by 8. The start blocks of partition 2 and 3 are wrong and the size of partition 2 is also wrong. You probably chose the wrong HFSJ occurrence.
    – klanomath
    Mar 10 '16 at 4:05
  • @klanomath I am the one in Peru and just got out of bed but it should be about 1 pm in Berlin, isn't it? I installed team viewer (v11) and you can start a session with 623 374 526 psw 1458. It would be awesome if you could repair it. The empty space was always there. Don't know what created it. Thanks for trying...
    – Coen Bosch
    Mar 10 '16 at 12:22

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

My partition is recovered thanks to @klanomath. It was quit difficult to get the right boundaries following the standard procedure and without knowing the characteristics of a disk with old windows and osx partitions. @klanomath did a great job looking for the Recovery-HD and from there determining the lost partition. Learned a lot. Thanks again! Saludos de Cusco.

You must log in to answer this question.

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