Missing Mac partitions - unrecognized file system Apparently, I installed Windows 7 via bootcamp and created a new partition in Windows (which probably affected the partition table).

After restart, I can't see Macintosh HD in startup disk (it only shows Windows, which bluescreens when booted)

So I ran cmd+R to boot to Internet Recovery Mode, select Disk Utility and tried to repair the disk, but it said 'Unrecognized file system' (I forgot to take a screenshot) but it looks like this:



In my case, Macintosh HD become disk0s2. I tried to repair the disk but failed.

Try to run diskutil cs list from Terminal and didn't show any disk.

Running gpt -r show /dev/disk0 yields the following:

-bash-3.2# gpt -r show /dev/disk0
      start       size index   contents
          0          1         MBR
          1  488493055     1   MBR  part  66
  488493056  248700928     2   MBR  part  66
  737193984  239577136     3   MBR  part  66
  976771120       2048


Is there any way to recover my Mac partition so it can be booted?

I think of doing the recovery via internet (reinstall) but my data seems to be lost after reinstall.
Windows' Disk Management has overwritten the GUID partition table with an MBR partition table. This usually only effects the partition table but not the content of your disk (though it seems to be gone)! To restore a proper GUID partition table, the MBR has to be deleted and 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 or an external drive.

The answer below is NOT intended for users WITH a thumb drive or an external disk! If you have one of those devices much easier solutions exist.

Preparation:


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 ...!


Remove the MBR and modify the GUID partition table


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 output (the types may be different in your diskutil listing:

-bash-3.2# diskutil list
/dev/disk0
    #:                       TYPE NAME                    SIZE       IDENTIFIER
    0:     FDisk_partition_scheme                        *500.0 GB   disk0
    1:                       NTFS                         253.5 GB   disk0s1
    2:                       NTFS                         122.4 GB   disk0s2
    3:                       NTFS                         124.1 GB   disk0s3
/dev/disk1...~/dev/disk12 belong to the recovery system

-bash-3.2# gpt -r show /dev/disk0
      start       size index   contents
          0          1         MBR
          1  488493055     1   MBR  part  66
  488493056  248700928     2   MBR  part  66
  737193984  239577136     3   MBR  part  66
  976771120       2048

Now replace the MBR by a GUID partition table:

diskutil umountDisk /dev/disk0
dd if=/dev/random of=/dev/disk0 count=1 bs=512
gpt create /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 guess the old content of the GUID partition table or you can 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 Test Disk/wxHexEditor).



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 488083416 -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 is a new system partition, the second one a recovery partition:

gpt add -b 800000000 -i 4 -s 100000000 -t 48465300-0000-11AA-AA11-00306543ECAC /dev/disk0
gpt add -b 900000000 -i 5 -s 1269536 -t 426F6F74-0000-11AA-AA11-00306543ECAC /dev/disk0

Now you have to format the new partitions:

diskutil list
newfs_hfs -v "TempSystem" -J /dev/disk0s4 #use the proper partition found in diskutil list. It should have a size of ~50 GB
newfs_hfs -v "Recovery HD" -J /dev/disk0s5
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 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 end of your old second partition (in your case ~1000 MB/1953125 sectors less than 488493056 = 486539931)

Then enter "HFSJ" like in the picture below, search for this string two 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 string may also occur later and at the end!



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 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 800000000
diskutil umountDisk /dev/disk0 # remove the partition starting at block 900000000
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.




Estimating (guessing) the proper GUID partition table entries

Guessing the partition often works because a default "one-visible-volume" OS X install has very characteristic start blocks and sizes of all partitions:

A classical partition map of a Yosemite install without any Boot Camp partition would probably look like this on your Mac:

sudo gpt -r show 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   975093952      2  GPT part - 48465300-0000-11AA-AA11-00306543ECAC
  975503592     1269536      3  GPT part - 426F6F74-0000-11AA-AA11-00306543ECAC
  976773128           7 
  976773135          32         Sec GPT table
  976773167           1         Sec GPT header


All start blocks and sizes of partitions are aligned to 4096 bytes blocks - they are all dividable through 8 (e.g. 975093952:8=121886744)!

After installing Windows with Boot Camp Assistant the main OS X partition is shrunk and the Recovery HD is moved:

sudo gpt -r show 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   486813880      2  GPT part - 48465300-0000-11AA-AA11-00306543ECAC
  487223520     1269536      3  GPT part - 426F6F74-0000-11AA-AA11-00306543ECAC
  488493056   488280072      4  GPT part - EBD0A0A2-B9E5-4433-87C0-68B6B72699C7
  976773128           7 
  976773135          32         Sec GPT table
  976773167           1         Sec GPT header


The fourth partition is the NTFS partition. Some Windows installs add a second EFI partition:

  488493056   488280072      4  GPT part - EBD0A0A2-B9E5-4433-87C0-68B6B72699C7


->

  488493056      204800      4  GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B
  488697856   488075272      5  GPT part - EBD0A0A2-B9E5-4433-87C0-68B6B72699C7


After partitioning the Windows partition from within Windows the partition map was overwritten and replaced by a MBR partition map:

gpt -r show /dev/disk0
      start       size index   contents
          0          1         MBR
          1  488493055     1   MBR  part  66
  488493056  248700928     2   MBR  part  66
  737193984  239577136     3   MBR  part  66
  976771120       2048


Now one may assume that the first 488493056 blocks (block 0 - block 488493055) are untouched (except the MBT of course) and still represent the former OS X part. Since you already replaced the MBR by a GUID partition table and recovered the EFI partition in a previous step you only have to restore the main OS X partition and the Recovery HD. 

Here the assumption is: the last block of the first MBR partition is the last block of the Recovery HD. By counting backwards you can now restore the Recovery HD and the old OS X volume:

Fixed size of the Recovery HD: 1269536
Start block of the second partition: 488493056 - 1269536 = 487223520 (the start block of the Recovery partition) 

The fixed last block of the EFI partition and the start block of the Recovery partition determine the start block and the size of the OS X volume:

Size: 487223520 - 409640 = 486813880
Fixed start block: 409640

Now derive the proper commands to restore the GUID partition table:

gpt add -b 487223520 -i 3 -s 1269536 -t 426F6F74-0000-11AA-AA11-00306543ECAC disk0 # add the recovery partition
gpt add -b 409640 -i 2 -s 486813880 -t 48465300-0000-11AA-AA11-00306543ECAC disk0 # add the main OS X partition


Verify the main volume with:

diskutil verifyVolume /dev/disk0s2


This approach might fail because sometimes unallocated disk space (usually 2048, 102400 or 204800 blocks) is added by disk partitioning tools. The unallocated disk space might be added at the end of a MBR partition



After accessing the remote Mac and inspecting the disk the final probable solution - following the wxHexEditor part of the answer - seems to be:

gpt add -b 487222344 -i 3 -s 1269536 -t 426F6F74-0000-11AA-AA11-00306543ECAC /dev/disk0
gpt add -b 409640 -i 2 -s 486812704 -t 48465300-0000-11AA-AA11-00306543ECAC /dev/disk0


Since some mounted volumes exist on disk0 and the protective partition (i=2) has to be removed before the original old partitions can be restored the complete command queue looks like this: 

diskutil umountDisk /dev/disk0
gpt remove -i 2 /dev/disk0
diskutil umountDisk /dev/disk0
gpt add -b 487222344 -i 3 -s 1269536 -t 426F6F74-0000-11AA-AA11-00306543ECAC /dev/disk0
diskutil umountDisk /dev/disk0
gpt add -b 409640 -i 2 -s 486812704 -t 48465300-0000-11AA-AA11-00306543ECAC /dev/disk0