Apple - Data Not Backed Up, Partition Type: FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF
To add an answer exactly fitting to your case I slightly modified my answer in the linked "duplicate" and posted it here again.
The second as well as the third partition of your internal disk got the wrong partition type, your data probably won't be lost.
A bootable OS X partition (except the Recovery HD) either has the GUID 48465300-0000-11AA-AA11-00306543ECAC for a standard OS X partition or the GUID 53746F72-6167-11AA-AA11-00306543ECAC for a CoreStorage partition. The FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF is an unknown partition type (but not no partition like the 000000-0000-0000.... one).
The first block of a standard OS X partition doesn't contain non-zeros, the first block of a CoreStorage partition contains some non-zeros. To get the first 3 blocks of a partition you have to use a substitute for hexdump/xxd (both aren't available in Recovery Mode/OS X Installer boot drive). The best I have found is
dd if=/dev/diskXsY count=3 | vis -c.
The GUID partition table can be modified with
gpt. gpt only writes to the first 34 and the last 33 blocks of a disk(512) or the first 6 and and last 5 blocks of a 4k disk. Modifying the partition table (even falsely) doesn't alter the content of any volume on your disk, if you don't initialize or repair a volume/disk by request. You may verify it though.
- Boot to Internet Recovery Mode or an OS X Installer boot drive
- Open Terminal in the menubar Utilities > Terminal
- Get an overview with
Get an overview of your internal disk with the disk identifier found in the previous command. Below I assume the disk identifier of your internal disk is disk0 (replace it with the one you have found in your environment)
gpt -r show disk0
- Unmount disk0 with
diskutil umountDisk disk0
vis the first 3 blocks of the FFFF... partition:
dd if=/dev/disk0s2 count=3 | vis -c
If you had a standard partition previously the first 1024 Bytes only contain non-printable (zeros): \0\0... At ~Byte 1030 you will see the following sequence: \0HFSJ\0
If you had a CoreStorage partition some non-zeros in the first 512 Bytes and the string CS (
...\0CS\^A...) are shown:
Now remove the third, the fourth and the second partition:
diskutil umountDisk disk0 gpt remove -i 3 disk0 diskutil umountDisk disk0 gpt remove -i 4 disk0 gpt remove -i 2 disk0
If you get an error message like "resource busy" just unmount the disk again or unmount stubborn volumes with
diskutil umount disk0sX.
Re-add the recovery partition with the proper type but the same index number, start block and size it had previously:
gpt add -i 3 -b 227212504 -s 1269536 -t 426F6F74-0000-11AA-AA11-00306543ECAC disk0
Re-add the main partition with the proper type but the same index number, start block and size it had previously:
Either a normal OS X partition (if you have found the typical traces of a normal partition in the
dd ... visstep):
gpt add -i 2 -b 409640 -s 226802864 -t 48465300-0000-11AA-AA11-00306543ECAC disk0
or (if you have found the typical traces of a CoreStorage partition):
gpt add -i 2 -b 409640 -s 226802864 -t 53746F72-6167-11AA-AA11-00306543ECAC disk0
Your disk should finally look like this if you have found a standard OS X partition:
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 226802864 2 GPT part - 48465300-0000-11AA-AA11-00306543ECAC 227212504 1269536 3 GPT part - 426F6F74-0000-11AA-AA11-00306543ECAC 228482040 8496103 236978143 32 Sec GPT table 236978175 1 Sec GPT header
or this, if you have found a CoreStorage volume:
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 226802864 2 GPT part - 53746F72-6167-11AA-AA11-00306543ECAC 227212504 1269536 3 GPT part - 426F6F74-0000-11AA-AA11-00306543ECAC 228482040 8496103 236978143 32 Sec GPT table 236978175 1 Sec GPT header
Finally verify/repair the disk with
diskutil verifyDisk disk0and/or
diskutil verifyVolume disk0s2. If a repair is needed use repair (instead of verify) as prefix in the above commands but contact me before repairing it and send me the error message.
Further investigations via TeamViewer sessions revealed that the EFI partition and the Recovery HD partition are corrupted. The main volume is encrypted.
The Recovery HD contains a special intermediate FileVault key then. If the key is missing the main system won't boot. It was possible to unlock the drive though with
diskutil cs unlockVolume ....
After installing a full macOS to a thumb drive and booting to it, the EFI partition and the Recovery HD of another non-FileVault drive (actually those of a Sierra VM) were dd'ed to the broken drive. Still booted from the thumb drive, the FileVault volume was reverted to a standard volume by right-clicking on the volume in the Finder, choosing "Decrypt volume" and entering a valid user password. This has to be the password of an eligible user account on the FileVault volume. Other methods to decrypt the volume like
diskutil cs revert lvUUID or
diskutil cs decryptVolume lvUUID - tested in a virtual machine only - didn't seem to work. This might be a restriction of VMs though.
To expand the main partition (disk0s2) to the full size, use Disk Utility or the
diskutil resizeVolume ... command.
The volume initially didn't appear in System Preferences > Startup Disk, but alt-booting the Mac unveiled the main volume. This probably re-blessed the volume's boot.efi properly. The (now standard) volume appears in Startup Disk again.