I was doing some work on my ESX and setting up the Mac OS server that I started work on months ago. In the process of setting it up as a LAN software update server the disk ran out of space and needed increasing.
After increasing the volume size in ESX MacOS didn’t detect the change so I had to reboot. After the reboot I loaded disk utility to increase the size and got “Partition failed with the error: MediaKit reports partition (map) too small” which stopped me in my tracks.
A quick Google returned that this was because the GPT partition map was the disk’s original size (120GB). In essence this meant even though the disk now reported a larger amount of space the partition table didn’t know what to do with it.
The solution was a scary one but worth a try as I didn’t fancy reinstalling everything from scratch – blowing the partition table in full and re-creating it.
Just incase this failed my first step was to power off the VM and take a snapshot with ESX.
Once the snapshot was taken I attached the ISO of my MacOS installation media and edited the VM properties. I selected “Options” and checked the Force EFI setup option. This ensures that the EFI boot menu is entered prior to starting MacOS – the only way I manage to actually select boot media on my VM since the “Option” key press seems to get missed somewhere between my Mac desktop and ESX vSphere Client running in a Windows VM.
Once OKing out of everything and the VMWare showing as successfully reconfigured I rebooted the server and chose to boot from my VMWare CD in the EFI. You need to do this as you cannot edit the disk when it is mounted and I was editing the primary boot drive. If you are editing a secondary disk you could do all the remaining steps whilst the server was booted.
Once the installation media loaded I selected to run the terminal.
The first step is to unmount your disk. In the case of your primary disk this is /dev/disk1 – but if you’re operating on another disk you can do this by running the mount command and seeing where your disk as below.
For each partition on the disk you’re going to change you need to unmount it or the partition management tool will complain. Do this with:
Where diskXSY is the partition name shown in the output from mount. I had a weird issue where it kept occasionally remounting my primary partition automatically. I just kept re-running my unmount commands if I got an error that the disk was in-use then continuing. This may be more annoying with more than one partition.
The next step is to see your existing partition table. I highly suggest taking a screenshot of this. Run the gpt command against your drive (for all remaining purposes I’m assuming you just have /dev/disk1 as I did):
got show /dev/disk1
The output will be similar to below. The strange part was that I saw 3 partitions whereas I was only aware of 1. Each of the partitions show as “GPT Part” and have an index next to them representing /dev/disk1s1, /dev/disk1s2 and /dev/disk1s3. The GUID after GPT Part indicates the type of file system. In my case slice 1 was EFI, slice 2 MacOS and slice 3 was the Apple Boot Partition.
I didn’t realise this at first and just tried to re-create everything. This somehow booted with EFI labelled as HFS and the recovery partition deleted. In my case I just re-did the partition table again to create slice 1 correctly and didn’t bother with the recovery partition as I can do an internet recovery if needed. Currently the only known method I can find in Yosemite requires a reinstall and I couldn’t be bothered to use the snapshot for this. The below commands assume I knew what I was doing first time.
# Destroy existing GPT gpt destroy /dev/disk1 # Create a new and empty GPT gpt create -f /dev/disk1 # Re-create slice 1 (EFI) gpt add -b 40 -s 409600 -t C12A7328-F81F-11D2-BA4B-00A0C93EC93B /dev/disk1 # Re-create slice 2 (MacOS) gpt add -b 409640 -s 249979024 -t 48465300-0000-11AA-AA11-00306543ECAC /dev/disk1 # Re-create slice 3 (Recovery Partition - Oops!) got add -b 250388664 -s 1269536 -t 426F6F74-0000-11AA-AA11-00306543ECAC /dev/disk1
At this point you should be told /dev/disk1s1, /dev/disk1s2 and /dev/disk1s3 have been created. If you get disk is in use errors then unmount any re-mounted partitions. I made a typo and accidentally created /dev/disk1 at 10x the size it was supposed to be. If you do that just start again with a get destroy and carry on.
Performing another gpt show will hopefully detail exactly the same as you started with for your GPT slices.
Now you’re done here you can quit the terminal, start Disk Utility and resize your partition as normal. Hey presto – no more errors and you can resize your virtual drive. The same method applies to any version of OS X and you don’t even need to boot off an OS X install CD for your current version – I used a Mountain Lion ISO with Yosemite.