There's some back story to this, so bare with me for a bit.
In an attempt the create a free space partition for Ubuntu without using the disk utility applicatition I booted into recovery mode and tested
diskutil partitionDisk /dev/disk0 GPT free Linux 100G
just to see if I could create a free space partition to install Ubuntu on.
1st, I am not even all that sure if that was the proper syntax to use, although the command seemed to work, but when I tried to boot back into macos, I got the folder with a question mark picture.
I went back into recovery mode and found that the volume /dev/disk0s2
was giving an error.
so i removed the volume /dev/disk0s2.
gpt remove -i 2 disk0
then used gpt -r show disk0
I am was left with
# 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 1953115495
1953115495 32 Sec GPT table
1953115167 1 Sec GPT header
(there is no C&P in recovery mode)
then tried to add the partition back since I'm sure of whatfile system I've been using.
gpt add -i 2 -b 409640 -s 195311549 -t 7C3457EF-0000-11AA-AA11-00306543ECAC disk0
it is an Apple APFS partition.
but even with that, when I try to verify the volume
diskutil verifyVolume disk0s2
i get the error
starting file system verification for disk0s2: Unrecognized file system (-69846)
Any help in repairing my volume and the proper syntax for partitioning free space would help.
P.S.
diskutil list
/dev/disk0 (internal, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_paritition_scheme *1.0 TB disk0
1: EFI EFI 209.7 MB disk0s1
2: 7C3457EF-0000-11AA-AA11-00306543ECAC 1000.0 GB disk0s2
but I still cannot boot into macOS without seeing the question mark folder.
EDIT
After David Anderson's explanation of my blunder, and me backtracking as a result of Klanomath's reply of what the proper command should have been…
gpt -r show disk0
now shows up as follows
# 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 1953115488 2 GPT part - 7C3457EF-0000-11AA-AA11-00306543ECAC
1953525128 7
1953525135 32 Sec GPT table
1953525167 1 Sec GPT header
Best Answer
Basically, you were doomed after entering the first command. Below is an explanation of what happened.
The first common you entered is repeated below.
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.The next command you entered is given below.
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.
This command shows you just have the EFI partition (
disk0s1
).The next command is shown below.
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.
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.
The output does not show
Apple_APFS
fordisk0s2
. Instead what is shown is7C3457EF-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.
The value of
899.8G
is computed below.