-2

I tried to delete a Linux partition on my hard drive. My hard drive was no longer bootable and the type turned into FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF. I tried to follow some of the other instructions on here to resolve the issue but have not had any success. Running diskutil list returns the following:

enter image description here

Would really appericiate any help. Thanks in advance.

EDIT

I performed gpt -r show /dev/disk0

And got the following:

enter image description here

And dd if=/dev/disk0s2 count=3 | vis -c

Returned

enter image description here

EDIT 2

After running diskutil verifyDisk disk0

I got the following errrors

enter image description here

Rahul Ravisankar
  • 9
  • Please search before posting - https://apple.stackexchange.com/search?q=FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF – Tetsujin Nov 16 '17 at 12:06
  • @Tetsujin hi I did search, and followed the instructions but still haven’t managed to figure it out. I’m posting because I’m desperate at the moment – Rahul Ravisankar Nov 16 '17 at 12:09
  • You must have formatted the Mac partition by mistake – Sayan Nov 16 '17 at 13:01
  • @klanomath thank you, just wondering what my partition type is I included vis -c results in my edited question. – Rahul Ravisankar Nov 16 '17 at 13:39
  • @klanomath gpt destroy disk0 returns: suspicious MBR at sector 0. Should I proceed to the next step? – Rahul Ravisankar Nov 16 '17 at 13:57
  • @RahulRavisankar Destroy it! Sometimes you even have to zero it the hard way (dd if=/dev/zero of=/dev/disk0 bs=512 count=1). – klanomath Nov 16 '17 at 14:00
  • @klanomath I ran diskutil verifyDisk disk0 and got some errors. I have added them to the question. Sorry I’m a noob at this. – Rahul Ravisankar Nov 16 '17 at 14:22
  • @RahulRavisankar Noobs, non-noobs & l33t experts all should do backups especially before experimenting with Linux or doing obscure re-partitioning attempts. You probably hosed your partition table with some earlier repair attempts. E.g. the "corestorage" partition in your first screenshot is in fact a corestorage partition and a Recovery HD partition! Asking a question here should also mention/include any previous step executed/taken to solve a problem. – klanomath Nov 16 '17 at 14:34
  • @klanomath Yea lesson learnt. I tried to do a few things following the instructions on other threads in panic mode. But did not document it. Is there any hope for me? – Rahul Ravisankar Nov 16 '17 at 14:42
  • @RahulRavisankar A plausible assumption is: disk0s2 is in fact disk0s2 and disk0s3 (< the Recovery HD). So you can try to delete partition2 and re-add it slightly smaller. Then add a third partition as recovery HD. I added a P.S in my question. – klanomath Nov 16 '17 at 14:53
  • @klanomath thank you for all your help. But I’m still not having any luck. Is there any method that can be used to determine the right size ? – Rahul Ravisankar Nov 16 '17 at 15:31
  • @RahulRavisankar Sure, it requires some deeper knowledge of special file system and partition meta-data and a full-fledged 2nd system as well as some apps though. I have written several answers how to do this: example answer – klanomath Nov 16 '17 at 15:39
  • @klanomath The hard drive was less that 2/3 full. Would it be possible to use a smaller size to get the drive working and recover as much data as I can ? – Rahul Ravisankar Nov 16 '17 at 15:40

1 Answers1

1

A bootable OS X partition (except the Recovery HD) either has the GUID 48465300-0000-11AA-AA11-00306543ECAC for a standard OS X partition, the GUID 53746F72-6167-11AA-AA11-00306543ECAC for a CoreStorage partition or the GUID 7C3457EF-0000-11AA-AA11-00306543ECAC for an APFS volume. The FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF is an unknown partition type (but not no partition like the 000000-0000-0000.... one).

Your dd if=/dev/disk0s2 count=3 | vis -c output shows that it is a CoreStorage partition because it contains the string ...\0CS\^A... near the middle of the second line.

The GUID partition table can be modified with gpt. You can only add, delete and modify GUID partition tables with gpt when all related disks are unmounted. To reconfigure your partitions boot to a third party drive (e.g. Internet Recovery or a OS X installer thumb drive).

Additionally your GUID partition table contains an MBR which has to be deleted

  • Boot to Internet Recovery Mode (or a third party 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 (SSD) (replace it with the one you have found in your environment).

    gpt -r show disk0
  • Unmount disk0 with diskutil umountDisk disk0

  • Then reset the GUID partition table and re-add the first and the second partition with the same size but proper type.

    gpt destroy disk0
gpt create -f disk0
gpt add -i 1 -b 40 -s 409600 -t C12A7328-F81F-11D2-BA4B-00A0C93EC93B disk0
gpt add -i 2 -b 409640 -s 194016208 -t 53746F72-6167-11AA-AA11-00306543ECAC disk0

  • Verify disk and volume:

    diskutil verifyDisk disk0
diskutil verifyVolume disk0s2

If you want to extend your current macOS partition resize it with the diskutil cs resizeStack lvUUID size command.

It's recommended to add a working Recovery HD partition which is missing on your disk at the moment.

If you did some undocumented repair attempts you may have forgotten the Recovery HD and added only one all-embracing partition accidentally which will result in diskutil verifyDisk errors.

You can then try to delete the current partition disk0s2 and re-add it slightly smaller and add an additional recovery partition:

diskutil umountDisk disk0
gpt remove -i 2 disk0
gpt add -i 3 -b 193156312 -s 1269536 -t 426F6F74-0000-11AA-AA11-00306543ECAC disk0
gpt add -i 2 -b 409640 -s 192746672 -t 53746F72-6167-11AA-AA11-00306543ECAC disk0
diskutil verifyDisk disk0
diskutil verifyVolume disk0s2

This is only a shot in the dark, because previous repair attempts might have changed partition sizes and file system types.

By booting to a full-fledged system on a second independent drive you may determine proper partition boundaries:

  1. Prohibitory sign on boot after Sierra update, can't mount disk anymore
  2. HFS+ invalid number of allocation blocks
  3. ASE search string
klanomath
  • 66,391
  • 9
  • 130
  • 201
  • That should be the accepted answer. There are so many answers on other questions and forums from people that are either misleading or incomplete. This one is very well written and comprehensive. It helped me to fix my GUID after dual boot with Linux messed it up. I used the APFS GUID instead of the one shown in the example code. – mowienay May 23 '21 at 04:56