2

While installing Ubuntu on my MacBook Pro 2015, which already has Windows and macOS installed, I made a huge mistake by selecting the "install alongside Windows" option. As a result, I can no longer boot into macOS or Windows.

With the successfully installed Ubuntu, I can still see and edit my files from the Windows partition, but not the Mac partition (in fact, it now shows as a "110 GB volume", see the image below) which contains the most important files for me.

Since I stupidly did not make any backups, rebooting into macOS or somehow extract the files in this particular partition is now my top priority.

Disk Utility screenshot.

Here are what I have tried.

First, upon inputing the command diskutil list in terminal under internet recovery mode, I discovered that the partition type for my disk0s1 had turned into FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF.

Then I followed @klanomath's instructions on Data Not Backed Up, Partition Type: FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF to cope with the problem, but wasn't successful.

here is what was returned after inputing dd if=/dev/disk0s2 count=3 | vis -c:

3+0 records in
3+0 records out
1536 bytes transferred in 0.000877 secs (1751142 bytes/sec)
l\M-Cr\M-;O
L\^U\^A\0\0\0\0\0\0\0006\M-_N\0\0...

so I thought this should be from a standard OS X partition, and edited the parition type of disk0s2 accordingly. Meanwhile, I also fixed the MBR problem according to @klanomath's instructions from How to fix broken GPT, GUID and unmountable, no type volumes?.

After all these, the command diskutil list returns:

/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *251.0 GB   disk0
   1:                       EFI EFI                      209.7 MB   disk0s1
   2:                 Apple_HFS                          110.0 GB   disk0s2
   3:       Microsoft Basic Data BOOTCAMP                123.9 GB   disk0s3
   4:           Windows Recovery                         841.0 MB   disk0s4
   5:           Linux Filesystem                         16.0 GB    disk0s5
/dev/disk1 (disk image):
   #:                       TYPE NAME                   SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        +2.1 GB     disk1
   1:                  Apple_HFS OS X Base System        2.0 GB     disk1s1
...

And the command gpt -r show /dev/disk0 returns:

      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  214860792      2  GPT part - 48465300-0000-11AA-AA11-00306543ECAC
  215270432        992
  215271424   31254528      5  GPT part - 0FC63DAF-8483-4772-8E79-3D69D8477DE4
  246525952  242062900      3  GPT part - EBD0A0A2-B9E5-4433-87C0-68B6B72699C7
  488588852        460
  488589312    1642496      4  GPT part - DE94BBA4-06D1-4D40-A16A-BFD50179D6AC
  490231808       2911
  490234719         32        Sec GPT table
  490234751          1        Sec GPT header

At this point, there still seems to be a problem with disk0s2, as its type name is "Apple_HFS". This was further supported by what was return after inouting diskutil verifyDisk disk0:

Started partition map verification on disk0
Checking prerequisites
Checking the partition list
Checking for an EFI system partition
Checking the EFI system partition's size
Checking the EFI system partiton'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 problemwith the EFI system partition's file system
Underlying error: 8: POSIX reports: Exec format error

Also, an error was raised for diskutil verifyVolume disk0s1:

Started file system verification on disk0s1 EFI
Verifying file system
** /dev/rdisk0s1
** Phase 1 - Preoaring FAT
** Phase 2 - Checking Directorues
** Phase 3 - Checking for Orphan Clusters
Found orphan clusters
206 files, 144089KiB free (288179 clusters)
File system check exit code is 8
Error: -69845: File system verify or repair failed
Underlying error: 8: POSIX reports: Exec format error

And diskutil verifyVolume disk0s2 returns:

Started file system verification on disk0s2
Verifying file system
File system check exit code is 8
Error: -69845: File system verify or repair failed
Underlying error: 8: POSIX reports: Exec format error

Update:

I had been using macOS Catalina.

Below is what was returned for export LC_CTYPE="ASCII"; dd if=/dev/disk0s2 count=1 | vis -cfw:

1+0 records in
1+0 records out
512 byte transferred in 0.001240 secs (412898 bytes/sec)
l\M-Cr\M-;O\nL\^U\^A\0\0\0\0\0\0\0006\M-_N\0\0\0\0\0\^A\0\0\^M@\0\0\0\0NXSB\0\
\^P\0\0\^?\M-P\M^Y\^A\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\
\M-`"\^X\M^X\M^U\M^QA\M-o\M^X\M-L\^A\M-1:<\t\^_\M-4\M-}.\0\0\0\0\0007\M-_N\0\0\
\0\0\0\^X\^A\0\0\^Xl\0\0\^j\M^O\0\0\0\0\0\0T\^Y\0\0\0\0\0\0\^Z\0\0\0\M-o\^T\0\
\0\^X\0\0\0\^B\0\0\0\M-\\^T\0\0\^S\0\0\0\M-H\M-{.\0\0\0\0\0Ug\^F\0\0\0\0\0\^A\
\^D\0\0\0\0\0\0\0\0\0\0d\0\0\0\^C\^D\0\0\0\0\0\0\M-%7\^A\0\0\0\0\0\M-'7\^A\0\0\
\0\0\0\M-9\M-V\^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\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\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\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\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\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\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\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\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\

Conclusion:

The problem is now solved. A huge thank you to @David Anderson: Thank you so much for your patient and knowledgable guidance! Also thanks to @grg, who revised this post to make it more clear, and @mbike, who suggested potential alternative solutions to my problem.

Below are what was done to finally solve the problem:

First, I used the following command to correct the type of disk0s2 to 7C3457EF-0000-11AA-AA11-00306543ECAC:

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

Meanwhile, since my macOS Recovery is an old 10.11.6 version, diskutil did not recognize APFS. Thus, the type name of disk0s2 under diskutil list shows 7C3457EF-0000-11AA-AA11-00306543ECAC instead.

After shutting done my MacBook and start up again while holding Option-Command-R, a newer version of macOS recovery (10.14) was downloaded. Then, I can see my see the "Macintosh HD" option again, and am able to boot into it.

9
  • Unless you are still using Sierra, your Mac would have been upgraded to APFS. The first answer you have referenced was posted before High Sierra was released. High Sierra was the first version of macOS to use APFS. Therefore, the referenced answer may be to old and may not apply to your problem. I do not know for certain, since your question does not include the version of macOS you are using. The output you posted from dd if=/dev/disk0s2 count=3 | vis -c was not long enough to be useful. Also, you probably should have used export LC_CTYPE="ASCII";dd if=/dev/disk0s2 count=3 | vis -cfw. Commented Mar 21, 2021 at 14:02
  • You could update your question to include the version of macOS you are using. Also, add the output from export LC_CTYPE="ASCII";dd if=/dev/disk0s2 count=1 | vis -cfw. You might also consider using gdisk to sort the GPT entries in ascending order. Commented Mar 21, 2021 at 14:44
  • The type for the partition with index of 2 should be 7C3457EF-0000-11AA-AA11-00306543ECAC. You currently have 48465300-0000-11AA-AA11-00306543ECAC. I assume you know how to fix this? If not, post a comment. Commented Mar 21, 2021 at 18:17
  • Thanks for your help! I have updated my version of macOS and the output from export LC_CTYPE="ASCII";dd if=/dev/disk0s2 count=1 | vis -cfw.
    – Richard Y.
    Commented Mar 21, 2021 at 19:08
  • Richard: Did you read my comment above your last comment? Commented Mar 21, 2021 at 19:10

1 Answer 1

1

Your Mac should do two things - support an external USB drive to boot an entirely new OS + support internet recovery.

This is a very safe procedure and well documented here and at Apple if you don’t want to risk trying to rewrite the partition maps or you don’t have the exact block offsets needed to recreate the layout you had before it was damaged or failed.

Do the erase install from Internet Recovery, but erase the external drive and not the internal one.

This method lets you try recovery software tailored to the data you wish to recover without having to make the system bootable. If you need macOS files restored, start with Data Rescue from ProSoft Engineering. Hopefully your attempts to repair the file systems hasn’t allowed any OS to overwrite the data. I would stop trying to fix the internal drive or even write any data to it until you’ve decided if you pay a firm to perform recovery or DIY it.

2
  • Thanks for your suggestion! However, I don't have a USB drive with enough space available right now. I will definitely try this when I do get one and update my progress.
    – Richard Y.
    Commented Mar 21, 2021 at 19:11
  • Sounds good @RichardY. a $10 SanDisk Cruzer 2.0 is sufficient for this test if time is more freely available than funds.
    – bmike
    Commented Mar 21, 2021 at 19:45

You must log in to answer this question.

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