2

I know this has been asked on here before, and similarly to the others I have not backed up my data... I found this duplicate and got lost in the answer and didn't want to mess too much with the tables without finding out if that is even the right fix for my issue.

The drive is my internal drive from my old Macbook Pro (early 2011 model, was dying from the video card issue after having the logic board replaced about a year ago) which was dual booted with Windows 10, but my computer got stuck while trying to boot and had to be force shut down. Took the drive out and plugged it in to another Macbook and it didn't mount the MacOS partition. 

sudo diskutil list

yields: 

/dev/disk0
#:                       TYPE NAME                    SIZE       IDENTIFIER
0:      GUID_partition_scheme                        *500.1 GB   disk0
1:                        EFI EFI                     209.7 MB   disk0s1
2:                  Apple_HFS Macintosh HD            394.0 GB   disk0s2
3:                 Apple_Boot Recovery HD             650.0 MB   disk0s3
4:       Microsoft Basic Data BOOTCAMP                105.2 GB   disk0s4
/dev/disk1
#:                       TYPE NAME                    SIZE       IDENTIFIER
0:      GUID_partition_scheme                        *500.1 GB   disk1
1:                        EFI EFI                     209.7 MB   disk1s1
2: FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF               419.9 GB   disk1s2
3:       Microsoft Basic Data BOOTCAMP                80.0 GB    disk1s3

As well as

sudo gpt -r show disk1

yields:

gpt show: disk1: Suspicious MBR at sector 0
      start       size  index  contents
          0          1         MBR
          1          1         Pri GPT header
          2         32         Pri GPT table
         34          6         
         40     409600      1  GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B
     409640  820115416      2  GPT part - FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF
  820525056  156248064      3  GPT part - EBD0A0A2-B9E5-4433-87C0-68B6B72699C7
  976773120         15         
  976773135         32         Sec GPT table
  976773167          1         Sec GPT header

Thanks so much for any help that can be given!

Improve this question
6
  • Got an error when trying gpt add so I'll send you an email shortly thank you so much!
    – Dillon Esponda
    Commented Dec 31, 2017 at 20:49
  • If you still have have problems (e.g. booting) just send me another mail!
    – klanomath
    Commented Dec 31, 2017 at 21:14
  • @klanomath Was the fix the same as your other answer? Just wondering if I should close this as a duplicate or not and, if so, for which of the other answers?
    – Monomeeth ♦
    Commented Dec 31, 2017 at 21:33
  • @klanomath Ok, I'll be guided by you then. :) If you think this should have its own answer because of the Windows issue / having to destroy the whole partition table, I'll leave it. Were you going to add an answer to this?
    – Monomeeth ♦
    Commented Dec 31, 2017 at 21:38
  • @klanomath No worries, thanks! Oh, and a happy New Year to you! :)
    – Monomeeth ♦
    Commented Dec 31, 2017 at 21:41

1 Answer 1

Reset to default
3

The issue was fixed based on this answer: OS volume shows as type 'FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF'

It's unclear why the partition type was changed. On the original boot drive (disk0) Yosemite is installed. On the second "broken" drive (diisk1) an APFS partition was detected with the sudo dd if=/dev/disk1s2 count=3 | hexdump method from the linked answer.

After removing the second partition on drive1 with sudo gpt remove -i 2 disk1 the MBR blocked adding the partition with the proper type. So the gpt had to be destroyed:

sudo gpt -r show disk1 #get the details
sudo gpt destroy disk1
sudo gpt create -f disk1 #create a new partition table

Adding all previous partitions with the proper types:

sudo gpt add -i 1 -b 40 -s 409600 -t C12A7328-F81F-11D2-BA4B-00A0C93EC93B disk1
sudo gpt add -i 2 -b 409640 -s 820115416 -t 7C3457EF-0000-11AA-AA11-00306543ECAC disk1
sudo gpt add -i 3 -b 820525056 -s 156248064 -t EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 disk1

Verify the disk:

diskutil verifyDisk disk1

Since the version of the boot system is 10.10.5 (Yosemite) which can't deal with APFS volumes, it wasn't possible to verify the volume.

Further similar questions (and solutions) on this site suggest that the problem is related to the SIP protected MBR. Yosemite doesn't recognize SIP protected items but newer systems do. Here it was possible to kill the MBR, but on newer systems SIP has to be disabled.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .