Repair a damaged partition after a (partitionDisk) action in Recovery Mode, macOS?

Question

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

Answer 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 because disk0s2 already existed. This is done so a gpt (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