2

I have a Macbook Pro running MacOS X Catalina with a 500G SSD drive.

I installed Bootcamp on it, and in an effort to expand the bootcamp partition, I shrunk the main MacOS partition by 64G. then booted into Windows to expand the bootcamp partition using MiniTool Partition Wizard.

Instead of deleting just the newly created partition of 64G, I also mistakenly deleted the main OSX partition (by using partition manager, and then right clicking on the main MacOS partition, and selecting delete).

My HD used to look like this:

1 2 3 4
EFI Mac OS partition Unallocated space (64G) BOOTCAMP (64G)

but now it's like the following

1 2 3
EFI Unallocated space BOOTCAMP (64G)

I can no longer boot in MacOS mode. but I'm able to boot into Windows 10.

When I startup in Recovery mode this is the output I get from running the following commands:

# diskutil list
/dev/disk0 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        +2.1 GB     disk0
   1:                 Apple_HFS OS X Base System⁩         2.0 GB     disk0s1

/dev/disk1 (internal, physical):
   #:                       TYPE NAME                    SIZE         IDENTIFIER
   0:      GUID_partition_scheme                        *500.3 GB     disk1
   1:                        EFI ⁨EFI⁩                     209.7 MB     disk1s1
   2:       Microsoft Basic Data BOOTCAMP                64.1 GB      disk1s2

and

# gpt -r show disk1
    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  851564504
851974144  125130752      2  GPT part - EBD0A0A2-B9E5-4433-87C0-68B6B72699C7
977104896        131
977105027         32         Sec GPT table
977105059          1         Sec GPT header

As you can see from the last command, the partition is still there but not recognised...

I am sure all the data is still there, as I didn't write to the disk. Is there anyway to restore my deleted MacOS partition without loosing any data? is it possible using the recovery mode or even Windows 10 that's installed on the bootcamp partition?

Any help is very much appreciated.

EDIT: As per @David Anderson's comment:

# export LC_CTYPE="ASCII";dd if=/dev/disk1 count=1 bs=16 skip=13108482 | vis -cw;echo
1+0 records in
1+0 records out
16 bytes transferred in 0.001788 secs(8948 bytes/sec)
NXSB\0\^P\0\0\M-S\M-Oi\^E\0\0\0\0

Using macOS, the above output can be converted to hexadecimal by the following command.

echo -n "NXSB\0\^P\0\0\M-S\M-Oi\^E\0\0\0\0" | unvis | hexdump -Cv

Doing so produces the following output.

00000000  4e 58 53 42 00 10 00 00  d3 cf 69 05 00 00 00 00  |NXSB......i.....|
00000010

According to klanomath's answer to this question, the following can be determined

  • 4e 58 53 42: magic string of an APFS container
  • 00 10 00 00: APFS block size: 4096
  • d3 cf 69 05 00 00 00 00 APFS container size in APFS blocks: 90820563 (=726564504 512-blocks)
2
  • Boot to the same Recovery Mode used in your question. Enter diskutil unmountdisk disk1 followed by export LC_CTYPE="ASCII";dd if=/dev/disk1 count=1 bs=16 skip=13108482 | vis -cw;echo. Edit your question and add the output from the commands. Oct 13 at 15:13
  • @DavidAnderson, please see updates
    – Riki Lyng
    Oct 13 at 15:41
1

Original Answer

Boot to the same Recovery Mode used in your question. Enter the following.

diskutil unmountdisk disk1
gpt remove -i 2 disk1
diskutil unmountdisk disk1
gpt add -b 851974144 -i 3 -s 125130752 -t EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 disk1
diskutil unmountdisk disk1
gpt add -b 409640 -i 2 -s 726564504 -t 7C3457EF-0000-11AA-AA11-00306543ECAC disk1

This places the partitions in ascending order in the GPT.

Note: Since macOS can attempt to mount volumes after a command completes, the above commands includes a diskutil unmountdisk disk1 command before each gpt command.

Alternate Answer

Note: This alternate answer was inspired by Jean_JD's answer.

My original answer required the use of macOS to execute the unvis and hexdump commands. This alternate answer does not require these commands. The steps are given below.

  1. Boot to the same Recovery Mode used in your question.

  2. Enter the commands given below.

    diskutil unmountdisk disk1
    gpt remove -i 2 disk1
    diskutil unmountdisk disk1
    gpt add -b 851974144 -i 3 -s 125130752 -t EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 disk1
    diskutil unmountdisk disk1
    gpt add -b 409640 -i 2 -t 7C3457EF-0000-11AA-AA11-00306543ECAC disk1
    diskutil list internal
    

    If the above commands execute successfully, then the name of the APFS volume containing macOS will appear in the output from the command diskutil list internal. If not, then boot to macOS and enter the command below in a Terminal application window.

    diskutil list internal
    
  3. Enter the following commands. When entering the commands, use the output from the previously entered diskutil list internal command to replace diskXsV with the identifier for the APFS Volume containing macOS and replace diskYsC with the identifier for the Apple_APFS Container listed as the Physical Store for the APFS Volume.

    diskutil info diskXsV | grep "Disk Size"
    diskutil info diskYsC | grep "Disk Size"
    

    If the output from both commands match, then you are done. (For the OP, the output will not match.) Otherwise, proceed. If booted to macOS, first record the disk size in 512-Byte-Units for the APFS Volume containing macOS, then reboot to the same Recovery Mode used in your question.

  4. Enter the following commands. When entering the commands, use the output from the previously entered diskutil info diskXsV | grep "Disk Size" command to replace SizeInBlocks with the disk size in 512-Byte-Units for the APFS Volume containing macOS. (For the OP, the value is already known to be 726564504.)

    Note: If you booted to macOS in step 3, the use the diskutil list internal command to verify disk1 is still the Mac's internal, physical drive. If not, then make the appropriate substitutions for disk1 when entering the following commands.

    diskutil unmountdisk disk1
    gpt remove -i 2 disk1
    diskutil unmountdisk disk1
    gpt add -i 2 -b 409640 -s SizeInBlocks -t apfs disk1
    

 

1
  • Thank you so much @David Anderson, it worked a treat.
    – Riki Lyng
    Oct 13 at 21:28
2

I suppose your Catalina was on an APFS Container.

From the terminal Recovery mode, you can try recreate the APFS Container :

diskutil umountdisk disk1

Then

gpt add -b 409640 -i 3 -s 851564504 -t 7C3457EF-0000-11AA-AA11-00306543ECAC disk1

Then you give the results of :

gpt -r show disk1

and

diskutil list internal

If you have a 64 Go of free space after the Container, may be the value of its size could be 726433752 (851564504 - 125130752) instead of 851564504.

But you can try with the above command.

Edit 2 :

With your new informations the good command is :

gpt add -b 409640 -i 3 -s 726564504 -t 7C3457EF-0000-11AA-AA11-00306543ECAC

However, I did a test by deleting an APFS container, and 2 JHFS + partitions that followed it.

I then recreated via gpt the APFS container and allocating it all of the freed space and giving it a partition number # of the one it had. This container contains a bootable CCC Big Sur Clone.

I tried to boot on it and it works.

The only problem is an inconsistency between the size of the disk container (100 GB) and that of the logical container (80 GB). But this is not very important and can be fixed afterwards with a clone.

Here is the Pastebin link of my terminal operations : https://pastebin.com/zQjyfcKq

In my case, sudo was necessary because I was not in Recovery Mode (root mode).

Edit 3 :

I've find how resize the "recreated" Container at its maximum size (100g)

  1. Resize the Container by shrink at 80g creating a jhfs temporary partition

     diskutil ap resizecontainer diskx 80g jhfs+ ToKill 0b
    

Then suppress this partition :

diskutil erasevolume free space diskxsy

And resize the Container growing it

diskutil ap resizecontainer diskx 0b
8
  • @David. I think the first thing with my command, it's easy to dismiss the changes if not right. Simply suppress the container added.
    – Jean_JD
    Oct 13 at 13:50
  • Jean_JD and @DavidAnderson, thanks for your comments. I believe there's a way to determine the size of the partition using hexdump according to this post: apple.stackexchange.com/questions/318082/… unfortunately hexdump is not installed by default in recovery mode! could this be done from the windows partition? years ago I used to use Norton Disk Doctor. do you know if anything like that exists?
    – Riki Lyng
    Oct 13 at 15:01
  • Also, I don't think the partition is an APFS Container. Mac OS was upgraded from El Capitan to Catalina!
    – Riki Lyng
    Oct 13 at 15:03
  • Riki: Since hexdump is not available, I posted the equivalent to your question. Oct 13 at 15:15
  • 1
    Riki: I have seen posts where users were able to install the newer versions of macOS without using APFS containers. However, normally Catalina would be installed in an APFS container. This would be true even when upgrading from El Capitan. In other words, when upgrading to Catalina any existing non‑APFS partitions containing the previous macOS are automatically converted to APFS without lost of data. Oct 13 at 15:41

You must log in to answer this question.

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