I've seen a couple of posts on here addressing similar issues. Since I don't have in-depth understanding of what went wrong I have to describe what happened in my case and hope you'll help me. Thanks.
MBP 15", Retina, mid 2012. Mojave.
- I shrank (removed 64Gb) osx space through Disk Utility, installed rEFInd and then Ubuntu 18.04. That worked great. I could boot whatever I chose.
- Then I decided to shrink osx space a bit more and format the resulting empty space (another 64Gb) to FAT through Disk Utility. After that I booted through a USB drive and tried to install Windows 10 Pro on that new partition.
During the second step, Windows Installer did't like that FAT partition so I erased it (cleaned). It still didn't like it. I deleted it. And re-created the new one from the resulting empty space. It still didn't like it. I decided to quit and leave until tomorrow. Rebooted my machine. Fail. macOS no longer boots and the process gets straight to Ubuntu, from which I'm writing now. I will update this message as soon as I get the required commands outputs.
-bash-3.2# diskutil list
/dev/disk0
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *500.3 GB disk0
1: EFI 209.7 MB disk0s1
2: Apple_CoreStorage 371.5 GB disk0s2
3: DE94BBA4-06D1-4D40-A16A-BFD50179D6AC 523.2 MB disk0s3
4: EFI 104.9 MB disk0s4
5: Microsoft Reserved 16.8 MB disk0s5
6: Microsoft Basic Data 63.9 GB disk0s6
7: Linux Swap 4.0 GB disk0s7
8: 0FC63DAF-8483-4772-8E79-3D69D8477DE4 60.0 GB disk0s8
/dev/disk1
#: TYPE NAME SIZE IDENTIFIER
0: Apple_partition_scheme *1.2 GB disk1
1: Apple_partition_map 30.7 KB disk1s1
2: Apple_HFS Mac OS X Base System 1.2 GB disk1s2
/dev/disk2
#: TYPE NAME SIZE IDENTIFIER
0: untitled *524.3 KB disk2
/dev/disk3
#: TYPE NAME SIZE IDENTIFIER
0: untitled *524.3 KB disk3
/dev/disk4
#: TYPE NAME SIZE IDENTIFIER
0: untitled *524.3 KB disk4
/dev/disk5
#: TYPE NAME SIZE IDENTIFIER
0: untitled *524.3 KB disk5
/dev/disk6
#: TYPE NAME SIZE IDENTIFIER
0: untitled *524.3 KB disk6
/dev/disk7
#: TYPE NAME SIZE IDENTIFIER
0: untitled *6.3 MB disk7
/dev/disk8
#: TYPE NAME SIZE IDENTIFIER
0: untitled *2.1 MB disk8
/dev/disk9
#: TYPE NAME SIZE IDENTIFIER
0: untitled *1.0 MB disk9
/dev/disk10
#: TYPE NAME SIZE IDENTIFIER
0: untitled *524.3 KB disk10
/dev/disk11
#: TYPE NAME SIZE IDENTIFIER
0: untitled *524.3 KB disk11
/dev/disk12
#: TYPE NAME SIZE IDENTIFIER
0: untitled *1.0 MB disk12
-bash-3.2# gpt -r show disk0
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 725609832 2 GPT part - 53746F72-6167-11AA-AA11-00306543ECAC
726019472 624
726020096 1021952 3 GPT part - DE94BBA4-06D1-4D40-A16A-BFD50179D6AC
727042048 204800 4 GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B
727246848 32768 5 GPT part - E3C9E316-0B5C-4DB8-817D-F92DF00215AE
727279616 124825600 6 GPT part - EBD0A0A2-B9E5-4433-87C0-68B6B72699C7
852105216 7813120 7 GPT part - 0657FD6D-A4AB-43C4-84E5-0933C84B4F4F
859918336 117186560 8 GPT part - 0FC63DAF-8483-4772-8E79-3D69D8477DE4
977104896 131
977105027 32 Sec GPT table
977105059 1 Sec GPT header
-bash-3.2# dd if=/dev/disk0 bs=512 skip=409640 count=1
rY
+?,C??)?NXSB??g??蝳C??T?"[?L9?
9?),lߌ???W9?-d?s?s1+0 records in 1+0 records out 512 bytes transferred in 0.006626 secs (77273 bytes/sec) -
bash-3.2#
Sorry for the last command output, hexdump
is not available in my machine's recovery mode. I'm working from crippled terminal.
EDIT #1: Stil cannot find hexdump
or od
in recovery mode. However, I've been able to do this:
-bash-3.2# fsck_apfs /dev/disk0s2
Cannot run fsck repair in install environment, degrading fsck_apfs to run with [-n]
** Checking the container superblock.
** Checking the EFI jumpstart record.
** Checking the space manager.
** Checking the space manager free queue trees.
** Checking the object map.
** Checking volume.
** Checking the APFS volume superblock.
** The volume Macintosh HD was formatted by hfs_convert (748.1.46) and last modified by apfs_kext (945.220.38).
** Checking the object map.
** Checking the snapshot metadata tree.
** Checking the snapshot metadata.
** Checking the extent ref tree.
** Checking the fsroot tree.
error: btn: invalid btn_btree.bt_key_count (expected 12785968, actual 12786023)
Fix btree: bt_key_count (12786023)? NO
fsroot tree is invalid.
** The volume /dev/disk0s2 could not be verified completely.
Best Answer
If you suspect
disk0s2
is is actually a APFS container, then you change the partition type in the GUID Partition Table (GPT) to APFS. Normally one would first hex dump the beginning ofdisk0s2
to see if the content matches what is expected for a APFS container. Apparently, the is difficult from Recovery mode. A last resort would be to see if the APFS magic number would be the charactersNXSB
. This can done by entering the commands given below.If the partition is a APFS container, then the following be output.
However, if you look at the
dd
output already posted to your question, you can see theNXSB
characters.If you can boot Ubuntu, then you could hex dump the first sector of the APFS container partition by entering the command given below.
Changing the partition type from Core Storage to APFS
The easiest way to change a partition type is to use the third party
gdisk
command. This command can be run from Ubuntu already installed on your Mac.You can make the partition type change form Ubuntu by using the
gdisk
command. You will need version 1.0.4 ofgdisk
. If you have an older version then download and install the updated version from the SourceForge GPT fdisk website. The command to enter is given below.Below is an example of the proper interaction with
gdisk
.You can also change the partition type from macOS. The different ways to boot are as follows.
disk0
. You will need to rundiskutil list
to determine the correct identifier.The commands to enter are shown below.