Mac GPT partition table recovery

UPDATE (Jan 12th 2012): see end of post for a much quicker restore method.

UPDATE (written 19th March 2015, don't recall release date): Samsung now has a firmware updater that works on Mac, and the update fixes this issue.

For reasons yet unknown, my Mac system disk lost its partition table (GPT) yesterday. This is how I recovered:


I booted an old copy of my OS X install from USB and downloaded testdisk. I then used it to scan for any partitions it would recognise. Results (warning: copied by hand from photo):

Disk /dev/disk0 - 512 GB / 476 GiB - CHS 1000215216 1 1
     Partition        Start        End    Size in sectors
 P DOS_FAT_32            40     409639     409600 [EFI]
 P HFS            998945640 1000215175    1269536

The DOS_FAT_32 partition contains EFI data; the HFS partition contains OS X Lion Recovery data. Obviously, testdisk did not recognise my FileVault partition. However, it is quite likely our data partition is right in between these two!


As testdisk does not support writing Mac/GPT partition tables, I took a phone camera photo of the results above and booted into the gparted liveCD (easier than building or finding parted/gdisk binaries for OS X, I think). With both my troubled drive and my old install connected on USB, it should be easy to compare details and get everything right.

As it turns out, gparted (the GNOME GUI for parted) is extremely limited. I could not even find how to define sector boundaries for partitions, and the partition type list is quite short. The CLI version is slightly better – it allows sector specifications but is unaware of most Apple-related GPT GUIDs.

This is how I, inefficiently, set my partition table straight:

  1. Use gparted to make a new GPT table.
  2. Use parted to make 3 partitions, using the numbers from testdisk and squeezing partition 2 right in between (starting one sector after end of partition 1, ending one sector before start of partition 3). I verified the snug fit with my old install.
  3. Try to set types and names right using parted, and failing.
  4. Trying the same thing with gdisk (which is on the gparted live CD) and succeeding. See below for correct settings.

After this (I actually tried to boot after step 3, did not work), my OS X is booting without trouble again. Pfew.

If you’re doing this, I recommend going with gdisk straight away.

Partition map

This is how the partition map looked on my old drive, how it looks now (after this recovery) on my current drive, and how I believe the partition map on most OS X installs (at least, when using Lion with FileVault) should look:

  1. sector 40-409639 (409600 sectors, 200.0 MiB): partition type EFI, label ‘EFI System Partition’
  2. sector 409640-? (? sectors, ? GiB): partition type Apple Core Storage, label whatever
  3. sector ?-? (1269536 sectors, 619.9 MiB): partition type Apple boot, label ‘Recovery HD’

In my case, the disk extended slightly beyond the end of partition 3. For best results, use testdisk to find the question marks for partition 3. I believe both partitions 1 and 3 should be marked bootable.

For non-FileVault users, I expect the type of partition 2 is HFS+ and the label does matter (cosmetically).

Wikipedia has a very useful list of partition type GUIDs. gdisk knows about all these numbers, though.

Update, Jan 12th 2012: it happened again. This time, I went straight for gdisk instead of bothering with (g)parted. gdisk immediately offered to restore my ‘backup MBR’ but did mention something about a broken checksum. I said ‘yes’, pushed ‘w’ for write. All done.

It turns out this is a firmware issue with my Samsung 830 SSD. Of course, the firmware updater does not work on a Mac.