Attempted to fix macOS startup volume after failed dual-boot Linux install, but failed and now original partition unknown

Question

Attempted to install Linux on my MacBook Pro 15" 2015 one day for school, but then the install failed and I had a GRUB issue similar to this: How do I recover/fix my OS X partition?.

Weirdest part was that before this I was able to boot into macOS Catalina just fine, and then after taking a look at Disk Utility (noticed swap partition exists, but not ext4) and shutting down (and then rebooting), the drive disappears.

Being shocked, I thought that deleting the Linux partition would solve my problems. WRONG (don't ask why plz). I formatted it to FAT32, then realized that did nothing. The linux partition(s) should be around 115 GB (since I allocated 40 GB for swap and 75 GB for Linux - tho I could be wrong). So, then I combined those two partitions and had a ~110 GB FAT32 partition.

I went into recovery ALT+CMD+R, and the drives couldn't be repaired.

I followed these directions: MacOS Disk Partition FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF

However, I realized that I typed in the incorrect start and size for all of my partitions and I don't remember the size of original partitions. Now I'm just stuck wondering how I could recover the data off my drive.

My main issue is after running gpt destroy ..., how would I know the original contents and can I still recover my files?

In Disk Utility, I wiped the FAT32 partition and replaced it with APFS, but the mac partition will not mount.

I'm also quite bad with terminal commands, but I'm willing to type whatever is necessary to get the data from my computer, since there's a lot of schoolwork on it.

I'm using an OWC Aura Pro 2 TB SSD, and I'm wondering if this could also be a factor.

Output of diskutil list and gpt -r show disk1:

---

Edit: scratch that, I only see disk1s1 now, and that the other two partitions are gone completely:

---

Edit2: heres the output from running commands from klanomath (thank you!)

-bash-3.2# export LC_CTYPE="ASCII"
-bash-3.2# dd if=/dev/disk1s2 bs=512 count=1 2>/dev/null | vis -wc; 
'\M^Q9\r\M-/\^X\s\M^E\^A\0\0\0\0\0\0\0\M-7q\a\0\0\0\0\0\^A\0\0\M^@\0\0\0\0NXSB\0\^P\0\0\M-3\M-mA\^Z\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\^B\0\0\0\0\0\0\0T\M-6\^\\M-C\M-k\M-\Kk\M-(bL\M-"\M^D?\M-^Z\M-d\M-4\a\0\0\0\0\0\M-8q\a\0\0\0\0\0\^X\^A\0\0\M^\l\0\0\^Z\M^M\^B\0\0\0\0\0~\s\^B\0\0\0\0\0\M-L\0\0\0\^R\^_\0\0\M-J\0\0\0\^B\0\0\0\M-~\^^\0\0\^T\0\0\0z\M-.\a\0\0\0\0\0\M-xA\s\0\0\0\0\0\^A\^D\0\0\0\0\0\0\0\0\0\0d\0\0\0\^B\^D\0\0\0\0\0\0\^F\^D\0\0\0\0\0\0\b\^D\0\0\0\0\0\0\n\^D\0\0\0\0\0\0\f\^D\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0-bash-3.2# dd if=/dev/disk1s2 bs=512 count=1 2>/dev/
-bash-3.2# 
-bash-3.2# 

Answer 1

The main partition of the SSD (disk1s2) and the APFS container have different sizes.

To fix this the partition disk1s2 has to removed and added again with the proper size - the size of the APFS container:

1. The size of the partition disk1s2 is 3151589464 blocks (512 Bytes) (according to the gpt listing in screeenshot 2

2. The size of the APFS container is stored in the superblock (1st block of disk1s2)

   To get the content of the superblock one can either use hexdump or in Recovery Mode vis:

   -bash-3.2# export LC_CTYPE="ASCII"
   -bash-3.2# dd if=/dev/disk1s2 bs=512 count=1 2>/dev/null | vis -wc; echo
   

   Result (relevant parts of the output only starting with NXSB):

   -bash-3.2# NXSB\0\^P\0\0\M-3\M-mA\^Z\0\0\0\0  
   

   which translates to

   -bash-3.2# echo -n 'NXSB\0\^P\0\0\M-3\M-mA\^Z\0\0\0\0' | unvis | hexdump -Cv
   00000000  4e 58 53 42 00 10 00 00  b3 ed 41 1a 00 00 00 00  |NXSB......A.....|
   00000010
   

   here another working Mac is needed to execute hexdump.

   NXSB is the magic string of an APFS container. 0x00100000 reversed is the allocation block size (4096 Bytes) and 0xb3ed411a00000000 reversed (0x1a41edb3) is the number of allocation blocks (440528307). The size of the container in 512 Byte blocks is the number of allocation blocks * 8 = 3524226456.

3. To adjust the partition size to the container size one has to remove it and add it in a second step slightly larger:

   gpt remove -i 2 /dev/disk1
   gpt add -i 2 -b 409640 -s 3524226456 -t 7C3457EF-0000-11AA-AA11-00306543ECAC /dev/disk1
   

4. Verify disk and APFS container scheme: diskutil verifyDisk disk1 and diskutil verifyVolume diskX with diskX=the device identifier of the synthesized APFS container scheme.

Answer 2

I am sorry to hear that you are having this issue. Can you access macOS Recovery? If you can, that's great news!

If you can access macOS Recovery, then the first step would be to run First Aid on APPLE SSD/HDD, the Container Disk, and Macintosh HD. If the process fails, then that means that the data might not be recoverable. If you do manage to mount the disk, then that's good news!

If the OS drive mounts, then go to Disk Utility and type cd /Volumes/Macintosh\ HD then type ls. This will allow you to see if your data is still there.

If you can boot up on the macOS Drive again, then that's good and your repair process is complete! If not, then try reinstalling macOS from macOS Recovery. This will not delete your data. Then try booting up on it.

If none of these work, then the last thing that you can do is erase the APFS container, and reinstall macOS on Macintosh HD.

Good luck!