Repair a damaged partition after a (partitionDisk) action in Recovery Mode, macOS?
Solution 1:
Basically, you were doomed after entering the first command. Below is an explanation of what happened.
The first common you entered is repeated below.
diskutil partitionDisk /dev/disk0 GPT free Linux 100G
This command erased the contents of EFI partition (disk0s1
) and created a new EFI partition. Next, the command created a 100 GB partition of free space. This free space is created destructively. This means that at least the beginning of the free space is zeroed out. Unfortunately, this happened to be where the header of the APFS container for your macOS resided. At this point, recovery becomes somewhere between extremely difficult to impossible.
Note: The
diskutil
command was destructive becausedisk0s2
already existed. This is done so agpt
(or other command) could not create a partition containing a volume which could be corrupted and/or potentially overlap another existing partition.
The next command you entered is given below.
gpt remove -i 2 disk0
This command did nothing. Basically, the command replaced the GUID type value of the second entry in the GPT with zeros, but the type was already zero.
The third command is shown below.
gpt -r show disk0
This command shows you just have the EFI partition (disk0s1
).
The next command is shown below.
gpt add -i 2 -b 409640 -s 195311549 -t 7C3457EF-0000-11AA-AA11-00306543ECAC disk0
This command did create a new partition (disk0s2
) of type APFS. However, the header of the original APFS partition was replaced with zeros when you entered the first command.
The next command you entered is shown below.
diskutil verifyVolume disk0s2
Even if you had a valid APFS container, there would have been some sort of error message. This is because you have booted to a version of macOS recovery that has no knowledge of the APFS.
The final command is given below.
diskutil list
The output does not show Apple_APFS
for disk0s2
. Instead what is shown is 7C3457EF-0000-11AA-AA11-00306543ECAC
, which is the GUID type for a APFS container partition. This happed because the version of macOS recovery you booted to predates the introduction of APFS.
What you should have entered.
diskutil apfs resizecontainer disk0s2 899.8G free none 0
The value of 899.8G
is computed below.
1000.0 G Bytes = Drive size
0.2 G Bytes = EFI partition size
100.0 G Bytes = Desired free space for Linux
--------
899.8 G Bytes