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

Question

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.

---

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!

Answer 1

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.

Answer 2

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.