MacOS – Unable to boot into Mac OSX after updating dual-boot Ubuntu, Partition Type FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF

dual-boothard drivemacosmojavepartition

On my Mac OSX Mojave machine.. I installed Ubuntu 18.04 to attempt to dual boot on the internal Apple SSD. Worked for a while, but after some updates to Ubuntu… hitting the power button boots up to a GRUB terminal, and when hitting the option key there is no 'Macintosh HD' as a startup option.

I have seen 2 similar posts on this topic, but none of them appear to exactly match as far as partitions go here and here and I am hesitant to try something that would wipe out or corrupt my OSX data that I know is still on the SSD/drive.

When booting into recovery media, I executed the following command to list disks:

I notice the partition FFFFF-FFFF…

I then do a disktuil info /dev/disk0s2 to look at the info.

I then use GPT to check…

gpt -r show /dev/disk0

What can I do to make it so that I can fix my OSX boot partition without losing any files. The disk that my OSX files are stored are on disk0s2, which is the FFFFFFF partition… how do I fix up my ability to boot into the OSX Mojave without wiping out my data or is there a way? Does APFS have anything to do with this?

At this point I don't care about the Ubuntu 18.04 partition, but I do not want to lose any data on the 900+GB partition, which is all my the Mac files are.

Best Answer

Usually when the FFFFFFFF-FFFF-FFFF-FFFFFFFFFFFF error occurs, the partition starting and ending values are still correct. I assume this is true in your case. If I am correct, then you need to enter the following commands to change FFFFFFFF-FFFF-FFFF-FFFFFFFFFFFF to 7C3457EF-0000-11AA-AA11-00306543ECAC.

diskutil unmountdisk disk0
gpt remove -i 2 disk0
diskutil unmountdisk disk0
gpt add -i 2 -b 409640 -s 1900925984 -t apfs disk0

The EFI partition (disk0s1) is used occasionally by macOS, so you need to keep this partition. However, Grub files were added to this partition when you installed Ubuntu. The commands below will remove any Grub files that may still exist on the EFI partition . You can enter these commands while booted to macOS.

sudo diskutil mount disk0s1
cd /Volumes/EFI/EFI
rm -rf BOOT
rm -rf ubuntu
cd ~
diskutil unmount disk0s1

To add the free space back to macOS, enter the command given below. You can enter this command while booted to macOS.

sudo diskutil apfs resizeContainer disk0s2 0

Related Solutions

MacOS – 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 -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:

\^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.

MacOS partition startup Volume type FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF

The proper GUID of APFS partitions is 7C3457EF-0000-11AA-AA11-00306543ECAC.

The default pMBR was replaced with an old-style MBR, probably by the Linux installation!

Your boot system (in Internet Recovery Mode) seems pretty old. Any disk or partition verification executed with diskutil may yield some bogus result. In no case try to repair anything with diskutil!

To get your APFS partition back remove partition disk0s2 and restore it with the proper type:

Open in the menubar > Utilities > Terminal

get some details:

diskutil list #below I assume the disk identifier of the internal disk is disk0
gpt -r show disk0

Unmount disk0:
```
diskutil umountDisk disk0
```

remove and restore the 2nd partition:

gpt remove -i 2 disk0
diskutil umountDisk disk0
gpt add -i 2 -b 409640 -s 372637568 -t 7C3457EF-0000-11AA-AA11-00306543ECAC disk0

verify disk and partition:

diskutil list
diskutil verifyDisk disk0       
diskutil verifyVolume disk0s2

Your Mac should be able to boot despite the MBR.

If you want (or have) to restore the pMBR because the MBR is stubborn/blocks the modification of the partition table do the following:

get all disk details:

diskutil list #below I assume the disk identifier of the internal disk is disk0
gpt -r show disk0

replace the GUID partition table:

diskutil umountDisk disk0
gpt destroy disk0
gpt create -f disk0

re-add all previous partitions visible in the last gpt -r show disk0 output:

gpt add -i 1 -b 40 -s 409600 -t C12A7328-F81F-11D2-BA4B-00A0C93EC93B disk0
gpt add -i 2 -b 409640 -s 372637568 -t 7C3457EF-0000-11AA-AA11-00306543ECAC disk0
gpt add -i 3 -b 373047208 -s 262144 -t 426F6F74-0000-11AA-AA11-00306543ECAC disk0
gpt add -i 4 ...
gpt add -i 5 ...

If you get a resource busy error after one of the steps, just unmount disk0 again with

diskutil umountDisk /dev/disk0

Finally verify disk and partitions:

diskutil list
diskutil verifyDisk disk0       
diskutil verifyVolume disk0s1
diskutil verifyVolume disk0s2
diskutil verifyVolume disk0s3
#disk0s4 & disk0s5 can't be verified with the default macOS tools because the latter is a Linux swap and the former a Linux partition, probably with ext4

Best Answer

Related Solutions

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

MacOS partition startup Volume type FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF

Related Question