How to fix/restore a deleted MacOS partition?
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)
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 eachgpt
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.
-
Boot to the same Recovery Mode used in your question.
-
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
-
Enter the following commands. When entering the commands, use the output from the previously entered
diskutil list internal
command to replacediskXsV
with the identifier for theAPFS Volume
containing macOS and replacediskYsC
with the identifier for theApple_APFS Container
listed as thePhysical Store
for theAPFS 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 theAPFS Volume
containing macOS, then reboot to the same Recovery Mode used in your question. -
Enter the following commands. When entering the commands, use the output from the previously entered
diskutil info diskXsV | grep "Disk Size"
command to replaceSizeInBlocks
with the disk size in512-Byte-Units
for theAPFS Volume
containing macOS. (For the OP, the value is already known to be726564504
.)Note: If you booted to macOS in step 3, the use the
diskutil list internal
command to verifydisk1
is still the Mac's internal, physical drive. If not, then make the appropriate substitutions fordisk1
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
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)
-
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