Windows' Disk Management has overwritten the GUID partition table with something unknown. This usually only effects the partition table but not the content of your disk (though it seems to be gone)! A proper GUID partition table has to be restored.
The particular obstacle here is: the OP neither has a thumb drive nor a second Mac.
Preparation:
- Backup the whole SSD to an external drive using a Linux Live DVD with
dd if=/dev/sda of=/path/to/file. The resulting file's size should be 121.3 GB or 113 GiB!
Restart to Internet Recovery Mode by pressing alt cmd R at startup.
The prerequisites are the latest firmware update installed, either ethernet or WLAN (WPA/WPA2) and a router with DHCP activated.
On a 50 Mbps-line it takes about 4 min (presenting a small animated globe) to boot into a recovery netboot image which usually is loaded from an Apple/Akamai server.
I recommend ethernet because it's more reliable. If you are restricted to WIFI and the boot process fails, just restart your Mac until you succeed booting.
Alternatively you may start from a bootable installer thumb drive (preferably Yosemite or El Capitan) or a thumb drive containing a full system (preferably Yosemite or El Capitan). If you boot to a full system and login as admin you have to prepend sudo to execute some commands like gpt ... or newfs_hfs ...!
Modify the GUID partition table
Open Utilities->Terminal in the menubar, enter diskutil list and gpt -r show /dev/diskX (with diskX: the disk identifier of your internal disk (probably disk0)) to get an overview. In the commands below I assume the disk identifier is disk0.
You should get the following listings:
gpt -r show /dev/disk0
start size index contents
0 1 PMBR
1 1 Pri GPT header
2 32 Pri GPT table
34 30666498
30666532 138412290 1 GPT part - 48465300-0000-11AA-AA11-00306543ECAC
169078822 67899321
236978143 32 Sec GPT table
236978175 1 Sec GPT header
diskutil list
/dev/disk0
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *121.3 GB disk0
1: Apple_HFS 70.9 GB disk0s1
# disk1-disk13 are volatile disks belonging to Internet Recovery Mode
Now remove the bogus HFS+ partition:
gpt remove -i 1 /dev/disk0
Add the EFI partition in the partition table:
gpt add -b 40 -i 1 -s 409600 -t C12A7328-F81F-11D2-BA4B-00A0C93EC93B /dev/disk0
Now you can either install OS X to a new partiton - without overwriting your old OS X partitions - and try to detect the sizes of the old partitions with appropriate tools (like wxHexEditor) or you can guess the old content of the GUID partition table (with the help of the TestDisk result - not recommended)
Installing a new OS X
This will destroy the content of the Windows partition(s).
Add a new partition in the (old) OS X part of your disk to protect it.
gpt add -b 409640 -i 2 -s 179590360 -t FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF /dev/disk0
This might be superfluous.
Add new partitions in the (old) Windows part of your disk. The first one (i=4) is a new system partition, the second one (i=5) a recovery partition. The new OS X partition starts at ~91 GB and has a size of ~26 GB - which shouldn't affect the old (hidden, "lost") OS X partition:
gpt add -b 180000000 -i 4 -s 50000000 -t 48465300-0000-11AA-AA11-00306543ECAC /dev/disk0
gpt add -b 230000000 -i 5 -s 1269536 -t 426F6F74-0000-11AA-AA11-00306543ECAC /dev/disk0
Now you have to format the new 26 GB partition:
diskutil list
newfs_hfs -v "TempSystem" -J /dev/disk0s4 #use the proper partition found in diskutil list. It should have a size of ~26 GB
newfs_hfs -v "Recovery HD" -J /dev/disk0s5 #use the proper partition found in diskutil list. It should have a size of ~650 MB
diskutil mount /dev/disk0s4
- Exit Terminal by entering
exit and quit it.
- Open Restore OS X and install OS X to the partition TempSystem.
- Configure the new system and enable internet access. Don't initialize any "unknown" volumes if asked.
- Enable the root user
- Log-out as admin and log-in as root
- Download and install wxHexEditor
Detect the start block and type of your old OS X volume and the start block of your old Recovery HD with wxHexEditor:
The approach is similar as in my answer here: HFS+ invalid number of allocation blocks
Since the start block of a main partition and the size of a recovery partition have fixed sizes/boundaries you can usually calculate the proper GUID partition entries of your old partition(s).
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 to 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+ partition look like this:
If you get a fundamentally different picture stop here.
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 beginning of your new main partition (in your case to sector 179999900)
Then enter "HFSJ" like in the picture below, search for this string several times and make readable! hand-written notes of the different offsets. To restore your old OS X you have to boot to Internet Recovery Mode later and all on-screen findings in the current temporary OS X will be lost!
The reason to search for the string "HFSJ" is that all HFSJ+ volumes contain this string in the third sector of its partition. The magic string may occur up to 40 times cluttered over ~10000 sectors! Sometimes it's really difficult to find the proper sector. A second indicator for the beginning of the Recovery HD is at least one block of 0xFF in the tenth sector (or block(MagicString)+7) of the partition.
You may have two really different results depending on the partition type:
Calculate the sector number of the second last finding. In my example (see picture above) it's 68069452800/512=132948150. Continue searching and calculate the sector of the last finding somewhere in the middle of the disk and surrounded by empty sectors. 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 these results you should be able to restore your GPT properly. Quit wxHexEditor. If you are asked to save changes don't save them!
- Boot back to Internet Recovery Mode and open Terminal
- Enter
diskutil listand gpt -r show /dev/disk0
Remove the second partition (the protective FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF type partition):
diskutil umountDisk /dev/disk0
gpt remove -i 2 /dev/disk0
Since the EFI and the Recovery HD usually have fixed sizes you can calculate the start and end block of your main volume.
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:
diskutil umountDisk /dev/disk0
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:
diskutil umountDisk /dev/disk0
gpt add -b 409640 -i 2 -s StartBlockOfRecoveryHD-409640 -t 53746F72-6167-11AA-AA11-00306543ECAC disk0
To rebuild the Recovery HD enter:
diskutil umountDisk /dev/disk0
gpt add -b StartBlockOfRecoveryHD -i 3 -s 1269536 -t 426F6F74-0000-11AA-AA11-00306543ECAC disk0
Now you may try to mount and verify your old OS X volume:
diskutil mount /dev/disk0s2
diskutil verifyVolume /dev/disk0s2
If you get an error mounting or verifying the volume its boundaries might be wrong. Stop here and consult me.
- If the verification was successful you may either boot to your old OS X volume and check if it works and delete TempSystem and the new Recovery HD later or delete both immediately. The downside of booting to your old OS X volume first is that you have to boot to Internet Recovery Mode once more to delete TempSystem and the new Recovery HD.
To delete both dispensable partitions booted to Internet Recovery Mode enter:
diskutil list
gpt -r show /dev/disk0
diskutil umountDisk /dev/disk0
gpt remove -i 4 /dev/disk0 # remove the partition starting at block 180000000
diskutil umountDisk /dev/disk0 # remove the partition starting at block 230000000
gpt remove -i 5 /dev/disk0
- Depending on the partition type (HFSJ+ or CoreStorage) you may either use
diskutil resizeVolume ... or diskutil cs resizeStack ... to expand your recovered OS X volume.
After accessing the remote Mac and inspecting the disk the final probable solution seems to be:
Remove the blocking partition
diskutil umountDisk /dev/disk0
gpt remove -i 2 /dev/disk0
Restore the old OS X partition table entry
diskutil umountDisk /dev/disk0
gpt add -b 409640 -i 2 -s 157173736 -t 53746F72-6167-11AA-AA11-00306543ECAC /dev/disk0
Restore the old recovery HD:
diskutil umountDisk /dev/disk0
gpt add -b 157583376 -i 5 -s 1269536 -t 426F6F74-0000-11AA-AA11-00306543ECAC /dev/disk0
The volume (encrypted with FileVault) had a proper volume structure, the superior disk structure was corrupted though. After backing up the volume externally the disk was repartitioned to one partition and the backup was restored.
