MacOS – Data Not Backed Up, Partition Type: FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF

dual-bootfilevaultmacospartitionunix

I was trying to install Linux on my MacBook for class when I bricked my computer, which now in an unbootable state.

I made my partition too small, so I was going to delete and create a larger one. However, Disk Utility did not allow me to delete the small partition. I followed the instructions from https://apple.stackexchange.com/a/238088/236252

However, not only was I still unable to delete it, but upon restarting I realized my primary partition (located on the same disk) changed into FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF, and I had no options to boot.
(I am sure I performed the command on the correct disk and partition)

I saw some similar threads, but my main bootable drive is the one that got corrupt.

I don't want to lose any data. I'm not the most terminal savvy, so ANY help is appreciated, and I will kindly provide any additional information!

(Disk 0, partition 2 is my main partition, and that only one I care about)

Below are the results of
$ diskutil list and $ gpt -r show disk0.

enter image description here

enter image description here

UPDATE: :
I have followed @klanomath 's instructions. At the last step I received the following error:

Checking prerequisites
Checking the partition list
Checking for an EFI system partition
Checking the EFI system partition's size
Checking the EFI system partition's file system
Problems were found with the partition map which might prevent booting
Error: -69766: The partition map needs to be repaired because there's a problem with the EFI system partition's file system
Underlying error: 8: POSIX reports: Exec format error

FINAL UPDATE: SUCCESS!

I just wanted thank @klanomath for helping me through this entire process. He spent 11 hours TeamViewing with me until not only my files were accessible, but until I could access my computer as could before this whole debacle (and this was after 5 hours of email correspondence).

To any future reader with this problem: PLEASE don't give up, it can be fixed!

Best Answer

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 -c

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

    2. 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 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 ... vis step):

    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 disk0 and/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.

Related Question