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.


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.


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

  • If anyone knows where the light in al of this is, and knows of a means that I can still recover from this, without a time machine, do tell. – Artorius Castus Feb 29 at 23:17
  • gpt add -i 2 -b 409640 -s 195311549 ... is wrong somehow: this creates a ~100 GB APFS partition. – klanomath Feb 29 at 23:19
  • A proper command would have been gpt add -i 2 -b 409640 -s 1953115488 -t 7C3457EF-0000-11AA-AA11-00306543ECAC disk0 (without the earlier diskutil partitionDisk ... command). – klanomath Feb 29 at 23:21
  • ah, that makes sense, I can only hope now that my mistake is not one which I cannot recover from. :V – Artorius Castus Feb 29 at 23:29
  • The output of the diskutil list command (a 1000 GB APFS partition) indicates that you issued another gpt command than written in your question. – klanomath Feb 29 at 23:34

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


| improve this answer | |
  • So, @David Anderson, what you are saying is that I'm going to need a fresh install of MacOS because I blew it? I do not have a time machine, I know (facepalm), is there no hope for recovering my data, files, and such? – Artorius Castus Feb 29 at 22:44
  • Have I no hope for recovery of my files @DavidAnderson – Artorius Castus Feb 29 at 23:15
  • I'm sure I've accepted your answers before @DavidAnderson , like the one where you introduced Gdisk and the gpt methods I actually used here. It usually ends up being either your answer or Klanomath's, since that's what works – Artorius Castus Feb 29 at 23:19
  • @DavidAnderson Do you know how many blocks are zeroed out issuing the diskutil partitionDisk /dev/disk0 GPT free .. command? – klanomath Feb 29 at 23:27
  • @klanomath: I do not have an exact answer. When testing I was able to verify that over 1024 sectors (at 512 bytes/sector) were zeroed out. Normally, the free space would not be zeroed out. However, because the partition already existed, the command did zero out at least the beginning. – David Anderson Mar 1 at 0:37

You must log in to answer this question.

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