Recovering OS X partition: wrong boundaries calculated, can't mount disk0s2
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