EFI system partition repair
I'm having a problem with the internal SSD on one of my Macs running 10.10. It was working fine when I was browsing the web one day and then suddenly froze with the spinning beachball; I couldn't force quit (it was truly hung) so I forced a restart and now the computer won't boot at all. I've tried the following with no success:
- Booting into the recovery partition and repairing the disk with Disk Utility.
- Booting on an external USB 10.10 installer and repairing the disk with Disk Utility.
- Booting in target disk mode and repairing the disk with Disk Utility.
- Booting in target disk mode and trying everything I can think of with
diskutil
in Terminal.
At this point I've given up on Disk Utility and have been looking for the right combination of diskutil
, fsck
, and gpt
to get things working. I have some data that will be lost so reformatting is not an option.
Here is some of the relevant info:
$ diskutil list
:
/dev/disk1 (external):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme 251.0 GB disk1
1: EFI EFI 209.7 MB disk1s1
2: Apple_CoreStorage Macintosh HD 250.1 GB disk1s2
3: Apple_Boot Recovery HD 650.0 MB disk1s3
$ diskutil info disk1
:
Device Identifier: disk1
Device Node: /dev/disk1
Whole: Yes
Part of Whole: disk1
Device / Media Name: APPLE SSD SD256E
Volume Name: Not applicable (no file system)
Mounted: Not applicable (no file system)
File System: None
Content (IOContent): GUID_partition_scheme
OS Can Be Installed: No
Media Type: Generic
Protocol: Thunderbolt
SMART Status: Verified
Total Size: 251.0 GB (251000193024 Bytes) (exactly 490234752 512-Byte-Units)
Volume Free Space: Not applicable (no file system)
Device Block Size: 512 Bytes
Read-Only Media: Yes
Read-Only Volume: Not applicable (no file system)
Device Location: External
Removable Media: No
OS 9 Drivers: No
Low Level Format: Not supported
$ diskutil verifyDisk disk1
:
Started partition map verification on disk1
Checking prerequisites
Checking the partition list
Checking the partition map size
Checking for an EFI system partition
Checking the EFI system partition's size
Checking the EFI system partition's file system
Problems were found with the partition map which might prevent booting
Error: -69766: The partition map needs to be repaired because there's a problem with the EFI system partition's file system
Underlying error: 8: POSIX reports: Exec format error
$ sudo diskutil repairDisk disk1
:
Unable to repair this whole disk: A writable disk is required (-69772)
$ sudo gpt -r show /dev/disk1
:
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 488555536 2 GPT part - 53746F72-6167-11AA-AA11-00306543ECAC
488965176 1269536 3 GPT part - 426F6F74-0000-11AA-AA11-00306543ECAC
490234712 7
490234719 32 Sec GPT table
490234751 1 Sec GPT header
$ diskutil cs list
:
CoreStorage logical volume groups (1 found)
|
+-- Logical Volume Group xxxxxxxx-xxxx-xxxx-xxxx-22CC7A9CEE24
=========================================================
Name: Macintosh HD
Status: Offline
Size: 250140434432 B (250.1 GB)
Free Space: 249788108800 B (249.8 GB)
|
+-< Physical Volume xxxxxxxx-xxxx-xxxx-xxxx-907CB441E882
----------------------------------------------------
Index: 0
Disk: disk1s2
Status: Online
Size: 250140434432 B (250.1 GB)
I had a similar issue with a MacBook pPo A 1278. HDD as internal device does not boot.
Connected as external USB drive -> HDD boot. Problem solved by replacing the internal SATA cable for (currently) $16.
See ifixit com (only) for the replacement instructions of the SATA cable.
The EFI can be recovered easily. The real issue is the missing Logical Volume Family and the Logical Volume in the CoreStorage Logical Volume Group. The LVF is the container for the actual encrypted Logical Volume.
There is no known tool to restore a deleted LVF/LV. Simply adding a LV with diskutil cs createVolume lvgUUID filesystem size
will overwrite parts of the previous LV.
There is small chance to manually manipulate the superior LVG container and recover the FileVault volume. This is subject of further research/investigation.
Recover the EFI:
Create a new EFI on an external disk and dd
the result to the broken EFI. It might be sufficient to just use an arbitrary EFI of another system disk – I don't know it!
- Create a Yosemite bootable thumb drive installer
- Attach the thumb drive and a spare external hard drive (16 GB) or an empty second thumb drive (at least 16 GB) to the "broken" Mac.
- Install Yosemite to the external drive/thumb drive
- Configure Yosemite
- Enable FileVault (use the same passwords/passphrase as previously on the broken system) and if asked reboot.
-
Backup the current EFI of the SSD:
dd if=/dev/disk0s1 of=~/Desktop/EFISSD.raw bs=1m
- Reboot to one of the Recovery HDs by pressing cmdR
- Booted to Internet Recovery Mode open Utilities → Terminal in the menubar and enter:
diskutil list
to get the disk identifiers. -
Now use
dd
to replace the broken EFI by the new EFI (assuming that the external disk has the disk identifier disk2 – check the sizes of the various disk to determine the correct one):dd if=/dev/disk2s1 of=/dev/disk0s1 bs=1m
Work in progress - This is subject of further research/investigation
Recover a deleted/vanished FileVault Logical Volume Family/Logical Volume
One possibility may be the following procedure:
- Boot to an external system
-
dd
the relevant parts of the SSD (the encrypted part is easily detectable) to a file on a separate disk:dd if=/dev/disk0 of=/Volumes/ExternalDisk/encrypted.raw skip=x count=y bs=512
with x: the number of the first blocks on the disk which are not encrypted (~420000) and y: number of encrypted blocks
-
dd
the Recovery HD partition to a RecoverHD.raw file because it contains at least one important key. - Reinstall OS X on the SSD with the same usernames and passwords as previously
- enabling FileVault
- Boot to an external disk
-
dd
the file back and replacing the actual content of the Logical Volume Family/Logical Volume:dd if=/Volumes/ExternalDisk/encrypted.raw of=/dev/disk0 seek=z bs=512b
with z: the number of the first blocks on the disk which are not encrypted
-
dd
the RecoveryHD.raw file back and replacing the actual content of the new Recovery HD.
This might fail due to varying keys, different salts (if salts are used at all) or other reasons.