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
diskutil list -
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 -cIf 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:\^U\^D\^A\M-s\M^?\M^?\M^?\M^?\^A\0\^P\0\0\0\M-W\^A\a\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\^B\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\M^Pu\M-\7\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0CS\^A\0\0\0\^D\0\0\^P\0\0\0\0@\0X\M-7}\^C\0\0\0\0X\M-;}\^C\0\0\0\0X\M-?}\^C\0\0\0\0X\M-C}\^C\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\^P\0\0\0\^B\0\0\0006j v\^R\M-+\^U\M^[\f\M^CdG\M-y\^]...
-
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 disk0If 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 disk0Re-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 disk0or (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 headeror 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/ordiskutil 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.
This issue may occur during a living APFS High Sierra session too ! I got this issue yesterday, after making changes with Disk Utility application and diskutil commands, I found this :
sh-3.2# diskutil list
/dev/disk0 (internal, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *500.3 GB disk0
1: EFI EFI 209.7 MB disk0s1
2: FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF 60.0 GB disk0s2
/dev/disk1 (synthesized):
#: TYPE NAME SIZE IDENTIFIER
0: APFS Container Scheme - +60.0 GB disk1
Physical Store disk0s2
1: APFS Volume APPLESSD 47.1 GB disk1s1
2: APFS Volume Preboot 19.4 MB disk1s2
3: APFS Volume Recovery 517.8 MB disk1s3
4: APFS Volume VM 1.1 GB disk1s4
sh-3.2# gpt -r show /dev/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 117111080 2 GPT part - FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF
117520720 859584307
977105027 32 Sec GPT table
977105059 1 Sec GPT header
I don't think it would reboot in that configuration (or maybe with GPT backup table ? No idea). Thanks the above explanation I could solve the issue during the live session, but I had to use a slightly different solution (this solution works only with SIP disabled, if it is enabled you will have to reboot, disable, and use previous solution. Anyway, this issue is maybe related to disabled SIP, so it won't occur on enabled SIP ? I don't know.)
Even with disk0 unmounted, it seems gpt won't let modify the GPT during a live session :
sh-3.2# gpt remove -i 2 disk0
gpt remove: unable to open device 'disk0': Resource busy
So instead I used a third party tool gdisk (I got it via homebrew) to modify the type of disk0s2:
sh-3.2# gdisk /dev/disk0
GPT fdisk (gdisk) version 1.0.3
Warning: Devices opened with shared lock will not have their
partition table automatically reloaded!
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present
Found valid GPT with protective MBR; using GPT.
Command (? for help): i
Partition number (1-2): 2
Partition GUID code: FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF (Unknown)
Partition unique GUID: B40FA371-D92C-4EBF-B846-B0A9FB6DCD71
First sector: 409640 (at 200.0 MiB)
Last sector: 117520719 (at 56.0 GiB)
Partition size: 117111080 sectors (55.8 GiB)
Attribute flags: 0000000000000000
Partition name: 'Apple_HFS_Untitled_2'
Command (? for help): t
Partition number (1-2): 2
Current type is 'Unknown'
Hex code or GUID (L to show codes, Enter = af00): 7C3457EF-0000-11AA-AA11-00306543ECAC
Changed type of partition to 'Unknown'
Command (? for help): i
Partition number (1-2): 2
Partition GUID code: 7C3457EF-0000-11AA-AA11-00306543ECAC (Unknown)
Partition unique GUID: B40FA371-D92C-4EBF-B846-B0A9FB6DCD71
First sector: 409640 (at 200.0 MiB)
Last sector: 117520719 (at 56.0 GiB)
Partition size: 117111080 sectors (55.8 GiB)
Attribute flags: 0000000000000000
Partition name: 'Apple_HFS_Untitled_2'
Command (? for help): w
Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
PARTITIONS!!
Do you want to proceed? (Y/N): Y
OK; writing new GUID partition table (GPT) to /dev/disk0.
Warning: Devices opened with shared lock will not have their
partition table automatically reloaded!
Warning: The kernel may continue to use old or deleted partitions.
You should reboot or remove the drive.
The operation has completed successfully.
Checking it out :
sh-3.2# gpt -r show /dev/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 117111080 2 GPT part - 7C3457EF-0000-11AA-AA11-00306543ECAC
117520720 859584307
977105027 32 Sec GPT table
977105059 1 Sec GPT header
sh-3.2# diskutil list
/dev/disk0 (internal, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *500.3 GB disk0
1: EFI EFI 209.7 MB disk0s1
2: Apple_APFS Container disk1 60.0 GB disk0s2
/dev/disk1 (synthesized):
#: TYPE NAME SIZE IDENTIFIER
0: APFS Container Scheme - +60.0 GB disk1
Physical Store disk0s2
1: APFS Volume APPLESSD 47.1 GB disk1s1
2: APFS Volume Preboot 19.4 MB disk1s2
3: APFS Volume Recovery 517.8 MB disk1s3
4: APFS Volume VM 1.1 GB disk1s4
Then last check with diskutil verifyDisk disk0 and diskutil verifyVolume disk0s2 without warning or errors. Reboot successful.