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
DOS_FAT_32 partition contains EFI data; the
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!
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:
gpartedto make a new GPT table.
partedto 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.
- Try to set types and names right using
parted, and failing.
- 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.
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:
- sector 40-409639 (409600 sectors, 200.0 MiB): partition type EFI, label ‘EFI System Partition’
- sector 409640-? (? sectors, ? GiB): partition type Apple Core Storage, label whatever
- 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.
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.