MacOS – (Mistakenly) Deleted all partitions except for disk0s2, can’t mount or repartition

disk-utilitymacospartition

First of all, I apologize that I cannot remember exactly what version of Mac OS I am running, but I am 99% sure it's Yosemite.

I recently tried to delete a second partition I had been using for a Ubuntu distro. While I was trying to erase the partition, the minus button was grayed out, but I found that if I clicked the minus on the other small partitions (I'm assuming retrospectively that it was the disk utility partition and something else) then I was able to delete the Ubuntu partition, so that's what I did.

So now my hard drive has one partition, disk0s2 with about 900gb and then an extra free space of 99.8gb. The free space can't be partitioned or reconfigured in any way, attempting to do so starts up a progress bar that never gets beyond 'preparing'. disk0s2 is unmounted, the mount button is blue and not grayed out, but clicking it does nothing.

Restarting and running in disk utility mode (I believe that's what it's called, CMD+R), does work, restarting holding OPT shows only the EFI boot, which takes me to GNU Grub version 2.02, which is also what happens when restarting normally. I thought that maybe inserting a USB and downloading Mac OS onto that from the disk utility start up might be a way of solving this problem, but my computer won't mount the USB (the mount button is not grayed out but clicking it does nothing) so it doesn't show up when trying to reinstall the OS.

What should I do? I have access to an external hard drive with enough space to put what was on my hard drive if that is possible, but obviously I would prefer to be able to recreate the disk utility partition (?) and remount disk0s2.

Here is the result of running diskutil in terminal:

Best Answer

You should be able to repair you existing partition so you can boot to OS X. The steps are given below. Here, I assume you were using Yosemite or some other version of OS X that installs to a "Mac OS Extended (Journaled)" formatted volume. Also, I assume encryption was not being used.

Note: The examples were made using a disk image while booted to High Sierra. So, your output may vary from what is shown.

Start up the Mac from macOS Recovery over the Internet by restarting and immediately pressing and holding the the key combination ⌘-R.
From the menu bar, select to open a Terminal application window.

Enter the following command to get the GUID Partition Table (GPT) entries.

gpt -r show /dev/disk0

An example output is shown below.

$ gpt -r show /dev/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  1757812496      2  GPT part - FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF
  1758222136   194902871         
  1953125007          32         Sec GPT table
  1953125039           1         Sec GPT header

Enter the commands given below to change the GPT.

diskutil unmountdisk /dev/disk0
gpt remove -i 2 /dev/disk0
diskutil unmountdisk /dev/disk0
gpt add -i 2 -b <start> -s <size> -t 48465300-0000-11AA-AA11-00306543ECAC /dev/disk0

Where <start> and <size> are integers taken from the row with index equal to 2 in the table shown in step 2. An example is shown below.

$ diskutil unmountdisk /dev/disk0
Unmount of all volumes on disk0 was successful
$ gpt remove -i 2 /dev/disk0
/dev/disk0s2 removed
$ diskutil unmountdisk /dev/disk0
Unmount of all volumes on disk0 was successful
$ gpt add -i 2 -b 409640 -s 1757812496 -t 48465300-0000-11AA-AA11-00306543ECAC /dev/disk0
/dev/disk0s2 added

You will need to replace 409640 and 1757812496 with the values shown in your GPT table.

Restart the Mac back to OS X.

Enter the command given below in a Terminal application window to reclaim the free space.

sudo diskutil resizevolume /dev/disk0s2 R

An example is shown below.

$ sudo diskutil resizevolume /dev/disk0s2 R
Resizing to full size (fit to fill)
Started partitioning on disk0s2 Macintosh HD
Verifying the disk
Verifying file system
Volume was successfully unmounted
Performing fsck_hfs -fn -x /dev/rdisk0s2
Checking Journaled HFS Plus volume
Checking extents overflow file
Checking catalog file
Checking multi-linked files
Checking catalog hierarchy
Checking extended attributes file
Checking volume bitmap
Checking volume information
The volume Macintosh HD appears to be OK
File system check exit code is 0
Restoring the original state found as mounted
Resizing
Modifying partition map
Growing file system
Finished partitioning on disk0s2 Macintosh HD
/dev/disk0
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *1.0 TB     disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:                  Apple_HFS Macintosh HD            999.7 GB   disk0s2

Addition Comments

Your internal recovery partition no longer exists. When you reinstall OS X or upgrade to a newer OS X or macOS, a new recovery volume will be created.
Grub still exists in your EFI partition (disk0s1). You should consider removing Grub.

Related Solutions

Can’t resize main partition even in G-Parted

As already mentioned, the free space is before the start of your partition. You can't grow a partition from the start - you can only expand it from its end.

You can try something like this:

Create a partition in the free space
Use something like Carbon Copy Cloner to copy the contents of your current partition into the new one
Boot from the new partition
Make sure everything works fine from the new partition - try all your usual programs, and make sure it's exactly the same as it always was
Delete the old partition
Expand the new partition to fill the hard disk space completely (reusing the space that was used by the old partition)

There are a few other options as well as Carbon Copy Cloner, but it has worked well for me in the past, and will make the target partition bootable.

MacOS – Hard drive no longer accessible

I suspect Windows` chkdsk or another Microsoft tool to erroneously repairing the partition table of your device containing the EXFAT volume.

The result of sudo gpt -r -vv show /dev/disk2 of my 4 TB device created in a VM and formatted with Disk Utility in comparison looks like this:

gpt -r -vv show /dev/disk2
gpt show: /dev/disk2: mediasize=4000655081472; sectorsize=512; blocks=7813779456
gpt show: /dev/disk2: PMBR at sector 0
gpt show: /dev/disk2: Pri GPT at sector 1
gpt show: /dev/disk2: Sec GPT at sector 7813779455
       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        2008         
      411648  7813365760      2  GPT part - EBD0A0A2-B9E5-4433-87C0-68B6B72699C7
  7813777408        2015         
  7813779423          32         Sec GPT table
  7813779455           1         Sec GPT header

(Please consider that the mediasize, the blocks and some other values are different to yours, because i use a slightly smaller example disk here.)

The differences to your finding are obvious: the first partition of your disk isn't aligned properly to the 4096 byte sector size and is smaller. The second partition starts too early and is probably too big.

You probably have to fix both partition. This will only work if you partitioned the drive with Disk Utility in Mac OS X.

Preparation:

Backup your Mac and then detach all external drives.
Download and install wxHexEditor. Enable the root user and log-in as root.

Hint: While working with wxHexEditor don't use copy and paste. Enter everything manually! You might accidentally write directly to your disk.

Where does the EXFAT partition start and end?

First you have to determine the starting block of your EXFAT volume:

Open Terminal and enter diskutil list. Get the Identifier of the disk to repair.
Open Calculator. Open wxHexEditor. Check that you work in read-only mode ("Options" -> "File mode" -> "Read only"). In the menubar go to "Devices" -> "Open disk device" -> choose the appropriate diskNumber.
Hit the search button (marked with the red circle in the picture below) and enter EXFAT (exactly like in the picture). Please try to arrange the wxHexEditor window like in the examples below with straight red lines.
My EXFAT entry (see picture below) is at offset 210763776. Now you can calculate the start block of the volume with: OffsetBytes/512 = NewStartBlockEXFAT. The start block in my example is 411648.

If you get a significantly smaller starting block (=<409639) stop here, because you probably didn't partition your disk with Disk Utility previously.
The ending block of the EXFAT volume can't be determined easily; we have to guess it (somehow). The problem is the variable gap between partition 2 and the second GPT table. In your case it has 1679 blocks, in my example it has 2015 blocks.
- Method 1 (maximal size in the "unallocated space" between the block containing the EXFAT string and the second GPT table):
  The maximal volume size is StartBlock2ndGPT-NewStartBlockEXFAT. The size has to be dividable through 8. Reduce the size until you get a size dividable through 8. Example: In my case the maximal size would be 7813779423 (StartBlock2ndGPT) - 411648 (StartBlockEXFAT) = 7813367775 (which isn't dividable through 8). The biggest size dividable through 8 is 7813367768.
- Method 2 (minimum size containing all occupied blocks between the block containing the EXFAT string and the second GPT table):
  You might jump to sector 7814037135 (the first block of your secondary GPT table) with the arrow button (the second button left of the search button) and search backwards and match case disabled with "Find some bytes" to get the last occupied sector. This may take a while. Make a note of your finding (if you have one in a reasonable timeframe). Divide the offset through 512 to get the sector number. The sector number should be smaller than 7814037135. Now calculate the provisional minimal size of your volume: StartBlockEXFAT+1-LastOccupiedSector. The result must be dividable through 8. To get size add blocks until the size is dividable through 8.
  You may stop the process after 5 minutes without result because then the last occupied block number is probably smaller than 7807917625 assuming the process searches 10 MByte/s (the last ~3 GB of your disk). Use Method 1 then.
Both results probably lead to a wrong size of the EXFAT volume, but this should be repairable. It's more important to get the proper start block. Additionally method 2 may deliver incorrect results if the disk has been completely filled with data previously using a different partition layout and hasn't been zero-filled afterwards.

Restoring the "old" GPT

Here i assume the identifier of the disk containing the EXFAT volume is disk0.

First you have to unmount the disk
```
diskutil umountDisk disk0
```

Check the partition layout, then remove the two partitions:

gpt -r -vv show /dev/disk0

gpt remove -i 2 disk0
gpt remove -i 1 disk0

Since the (Apple-)EFI usually has a fixed size we can easily add it with:

gpt add -b 40 -i 1 -s 409600 -t C12A7328-F81F-11D2-BA4B-00A0C93EC93B disk0

With the start block of the EXFAT partition and Size (the volume size found with Method 1 or 2 above) we can also add it:
```
gpt add -b NewStartBlockEXFAT -i 2 -s Size -t EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 disk0
```
Remount disk0 with:
```
diskutil mountDisk disk0
```
Quit Terminal, Calculator and wxHexEdit and open Disk Utility.
Check your EXFAT volume for errors.

If you run into problems (e.g you can't find the proper EXFAT volume size), have doubts or questions immediately stop and contact me with a comment @klanomath!

Best Answer

Addition Comments

Related Solutions

Can’t resize main partition even in G-Parted

MacOS – Hard drive no longer accessible

Related Question