5

I have two drives inside my MBP, an SSD for the OS and the original HDD for large Data. The HDD has 3 Partitions:

  1. My Data (Core Storage volume)
  2. 20Gb for Linux
  3. 4Gb for Linux Swap

Recently I ran repair disk on the drive, as Disk Utility thought it was damaged. The repair aborted with the request to format and restore the whole drive, but I could use it like before (so maybe unrelated). Last night, everything was normal, but when I woke up, my data partition looked like this:

enter image description here

It used to be named Macintosh HD (like the drive) and now it has lost its name and the partition type turned into FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF. diskutil info /dev/disk1s2 reports

   Device Identifier:        disk1s2
   Device Node:              /dev/disk1s2
   Part of Whole:            disk1
   Device / Media Name:      Macintosh HD

   Volume Name:              Not applicable (no file system)

   Mounted:                  Not applicable (no file system)

   File System:              None

   Partition Type:           FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF
   OS Can Be Installed:      No
   Media Type:               Generic
   Protocol:                 SATA
   SMART Status:             Verified
   Disk / Partition UUID:    00002980-188B-0000-A938-00003F710000

   Total Size:               475.0 GB (474999996416 Bytes) (exactly 927734368 512-Byte-Units)
   Volume Free Space:        Not applicable (no file system)
   Device Block Size:        512 Bytes

   Read-Only Media:          No
   Read-Only Volume:         Not applicable (no file system)
   Ejectable:                No

   Whole:                    No
   Internal:                 Yes
   Solid State:              No

Also a partition named Boot OS X seems to be constantly mounted, even after restart, which has not been the case before. Now, I have most of the data backed up, but can I somehow get my partition back without all the hassle?

Edit:

$ sudo gpt -r show /dev/disk1
gpt show: /dev/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  927734368      2  GPT part - FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF
  928144008     262144      3  GPT part - 48465300-0000-11AA-AA11-00306543ECAC
  928406152     615800
  929021952   39294976      4  GPT part - EBD0A0A2-B9E5-4433-87C0-68B6B72699C7
  968316928       2048
  968318976    8388608      5  GPT part - 0657FD6D-A4AB-43C4-84E5-0933C84B4F4F
  976707584      65551
  976773135         32         Sec GPT table
  976773167          1         Sec GPT header


$ sudo fdisk /dev/disk1
Disk: /dev/disk1    geometry: 60801/255/63 [976773168 sectors]
Signature: 0xAA55
         Starting       Ending
 #: id  cyl  hd sec -  cyl  hd sec [     start -       size]
------------------------------------------------------------------------
 1: EE 1023 254  63 - 1023 254  63 [         1 -     409639] <Unknown ID>
*2: DA 1023 254  63 - 1023 254  63 [    409640 -  927734368] <Unknown ID>
 3: AF 1023 254  63 - 1023 254  63 [ 928144008 -     262144] HFS+
 4: 83 1023 254  63 - 1023 254  63 [ 929021952 -   39294976] Linux files*

Since I know that it was an OSX Journaled file system in a Core Storage Volume, can I somehow convince OSX of this fact and fix the partition? Do I maybe need to edit the partition table?

As suggested, I removed partitions 2 and 3 with

sudo gpt remove -i 3 /dev/disk1
diskutil umountDisk /dev/disk1
sudo gpt remove -i 2 /dev/disk1

Now the partition table is

$ sudo gpt -r show /dev/disk1
gpt show: /dev/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  927734368      2  MBR part 218
  928144008     262144      3  MBR part 175
  928406152     615800
  929021952   39294976      4  GPT part - EBD0A0A2-B9E5-4433-87C0-68B6B72699C7
  968316928       2048
  968318976    8388608      5  GPT part - 0657FD6D-A4AB-43C4-84E5-0933C84B4F4F
  976707584      65551
  976773135         32         Sec GPT table
  976773167          1         Sec GPT header
4
  • I'm not the right guy to answer, but curious, what did you originally use to create the Linux partitions? Did you make a Linux partition in Disk Utility originally and then you formatted and split that partition using Linux?
    – kal-al
    May 27, 2016 at 6:55
  • I think I made a partition in disk utility and then split that during the install process, I'm not quite sure. Maybe I made both beforehand.
    – oarfish
    May 27, 2016 at 6:56
  • Edit your post and add the output from the commands sudo gpt -r show /dev/disk1 and sudo fdisk /dev/disk1. May 27, 2016 at 7:06
  • @DavidAnderson Yes, sir.
    – oarfish
    May 27, 2016 at 7:10

1 Answer 1

5

You have to edit the partition table and modify the type of disk1s2 (and correct the type of disk1s3) to get your main data partition back and make Boot OS X invisible:

  1. Log-in as admin
  2. Open Terminal and enter

    sudo gpt -r show /dev/disk1
    

    to get an overview

  3. Unmount disk1:

    diskutil umountDisk /dev/disk1
    
  4. Remove partition 2 and 3:

    sudo gpt remove -i 3 /dev/disk1
    diskutil umountDisk /dev/disk1
    sudo gpt remove -i 2 /dev/disk1
    
  5. Re-add the partition 2 and 3

    diskutil umountDisk /dev/disk1
    sudo gpt add -b 928144008 -i 3 -s 262144 -t 426F6F74-0000-11AA-AA11-00306543ECAC /dev/disk1
    diskutil umountDisk /dev/disk1
    sudo gpt add -b 409640 -i 2 -s 927734368 -t 53746F72-6167-11AA-AA11-00306543ECAC /dev/disk1
    

The correct partition type of a Boot OS X partition is 426F6F74-0000-11AA-AA11-00306543ECAC (like a Recovery HD partition) and 53746F72-6167-11AA-AA11-00306543ECAC for a CoreStorage partition.


Update: gpt behaves strange because the partition table contains an MBR instead of an PMBR - the MBR has to be replaced by a PMBR:

  • Reboot your Mac
  • Open Terminal and enter

    sudo gpt -r show /dev/disk1
    

    to get an overview and all partition sizes/types

  • rebuilding the GUID partition table and destroying the bogus MBR

    diskutil umountDisk /dev/disk1
    sudo gpt destroy /dev/disk1
    diskutil umountDisk /dev/disk1
    sudo gpt create -f /dev/disk1
    sudo gpt add -b 40 -i 1 -s 409600 -t C12A7328-F81F-11D2-BA4B-00A0C93EC93B /dev/disk1
    sudo gpt add -b 409640 -i 2 -s 927734368 -t 53746F72-6167-11AA-AA11-00306543ECAC /dev/disk1       
    diskutil umountDisk /dev/disk2 
    diskutil umountDisk /dev/disk1
    sudo gpt add -b 928144008 -i 3 -s 262144 -t 426F6F74-0000-11AA-AA11-00306543ECAC /dev/disk1
    diskutil umountDisk /dev/disk2
    diskutil umountDisk /dev/disk1
    sudo gpt add -b 929021952 -i 4 -s 39294976 -t EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 /dev/disk1
    diskutil umountDisk /dev/disk2
    diskutil umountDisk /dev/disk1
    sudo gpt add -b 968318976 -i 5 -s 8388608 -t 0657FD6D-A4AB-43C4-84E5-0933C84B4F4F /dev/disk1
    
13
  • What do these strings mean? 426F6F74-0000-11AA-AA11-00306543ECAC
    – oarfish
    May 27, 2016 at 9:04
  • Does this take into account the fact that the partition is encrypted?
    – oarfish
    May 27, 2016 at 9:07
  • But /dev/disk1s2 is the encrypted partition, maybe I'm misunderstanding something. But comparing the gpt output for /dev/disk0, my main drive with the OS, the partition has the same 53746F72-6167-11AA-AA11-00306543ECAC identifier, as you suggest. So I guess it's alright.
    – oarfish
    May 27, 2016 at 9:13
  • Your first gpt add command yields gpt add: /dev/disk1: Suspicious MBR at sector 0 and gpt add: /dev/disk1: error: no space available on device
    – oarfish
    May 27, 2016 at 9:18
  • @oarfish After removing partition 2 and 3 enter sudo gpt -r show /dev/disk1 and check if the two slices are really removed. You then may add the second partition first - usually the order (3/2 or 2/3) of adding partitions is irrelevant.
    – klanomath
    May 27, 2016 at 9:30

You must log in to answer this question.

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