Missing Mac partitions - unrecognized file system
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
sudoto execute some commands likegpt ...ornewfs_hfs ...!
Remove the MBR and modify the GUID partition table
-
Enter
diskutil listandgpt -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/disk0This 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
exitand 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 listandgpt -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/disk0s2If 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 ...ordiskutil 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