Apple - Problem cloning the startup disk of a MacBook Pro running OS X 10.11.6 El Capitan
The system partition type of SSDs defaulted to CoreStorage in 10.11 (El Capitan).
The CoreStorage partition (usually disk0s2) is a container which can store one or more volumes. Only the innermost objects (logical volumes) export to additional device nodes. Further reading: CoreStorage.
If you asr --source ...
a CS partition (in your case disk0s2) to a target partition, you will not get a proper bootable file system (e.g. a bootable HFS+ volume). The simple reason: a CS partition has no traditional file system and a different internal structure compared to an HFS+ boot volume.
Solution:
Instead of asr --sourcing a disk slice simply use the exported logical volume.
There is no easy way to get the device node of the mounted logical volume of the SSD automatically (i.e. to use it in a shell script).
diskutil list
ordiskutil cs list
list it, but it's difficult to extract the device node with tools available in Recovery Mode (with e.g.awk ...
orsed ...
) - at least for me with limited shell scripting capability. The best I have found isbless --getBoot
. The default boot volume has to be the internal SSD before booting to Recovery Mode (with the option key or cmd-R) - compellingly! You can also set the start volume to the internal SSD in Recovery Mode.On the command line (in Recovery Mode) the asr command would look like this then:
CSB=$(bless --getBoot); asr restore --source $CSB --target target_device_node --erase
If you get the error
Source volume is read-write and cannot be unmounted
after executing theasr ...
command, try to unmount $CSB after defining the variable CSB:diskutil umount $CSB
.You will get a bootable HFS+ volume on a type HFS+ partition on the target disk finally.
If method 1 fails you can also use the mountpoint of the SSD's system volume (e.g. Macintosh HD):
asr restore --source /Volumes/Macintosh\ HD --target target_device_node --erase
I tried to asr blockcopy the CoreStorage source partition (disk0s2) to a target partition with the same size using different methods but all fail with a checksum error. These methods require to modify the partition type of the target partition with gpt afterwards.
Here I just put a re-worked version of the Basic Procedure section in the original question. Following the path sketched below solved my issue. You may regard this as a kind of preliminary exercise for a script-based solution. Fame on @klanomath if its useful for you, shame on me if it sounds like gibberish to you.
Basic Procedure
Terminology
source_disk_id
disk identifier of the Macintosh HD
partition
source_device_node
device node corresponding to the Macintosh HD
partition
target_disk_id
disk identifier of the target partition on the external HD
target_device_node
device node corresponding to the target partition
target_partition_size
size of the target partition
Note: Used on invocation of a command, take care to use an appropriate size specifier.
Processing Steps
Create the target partition that is to contain the bootable clone.
- Determine the size of the
Macintosh HD
partition via
diskutil info source_disk_id
. - Determine the size of the
Recovery HD
the same way running diskutil info; usually yet another 650 MB. - We estimate the target partition's size so that the target partition can hold the contents of the
Recovery HD
as well as that of theMacintosh HD
, including free space. This is more or less a precaution to preventasr restore
, later on used, from complaining about missing space.
When the cloning operation will be accomplished, the target partition's size may be reduced runningdiskutil resizeVolume
. - Now we are ready to create the target partition:
diskutil resizeVolume target_disk_id target_partition_size JHFS+ FreePartition 0
Note: This works for me because the target disk is maintained such that there is a "remainder partition" with respect to on-disk order. Running thediskutil resizeVolume
command then simply cuts off a chunk of disk space from the remainder partition's upper end that shall now be used as the target partition.
- Determine the size of the
Switch to Recovery Mode
Determine the source_device_node
When we have a look at the CoreStorage Logical Volume Group to which theMacintosh HD
belongs, we have to select the disk identifier of the associated Logical Volume - in contrast to the Physical Volume.
Note: The partition type of the Physical Volume isApple_CoreStorage
while partition type of the Logical Volume isApple_HFS
, equipped with a JHFS+ file system.CoreStorage logical volume groups (1 found) | +-- Logical Volume Group 9344A028-DD9F-454C-89C0-8E2866E5FBB6 - --------------------------------------------------------- Name: Macintosh HD Status: Online Size: 250140434432 B (250.1 GB) Free Space: 8921088 B (8.9 MB) | +-< Physical Volume EC0BB005-738C-4F32-8B27-BA8801EBC34D | ---------------------------------------------------- | Index: 0 | Disk: disk0s2 | Status: Online | Size: 250140434432 B (250.1 GB) | +-> Logical Volume Family A20BC6DA-C477-44B4-82C9-C88B2CB41658 ---------------------------------------------------------- Encryption Type: None | +-> Logical Volume 73C52081-F8CF-4C86-93F9-4BBA68602854 --------------------------------------------------- Disk: disk2 Status: Online Size (Total): 249779191808 B (249.8 GB) Revertible: Yes (no decryption required) LV Name: Macintosh HD Volume Name: Macintosh HD Content Hint: Apple_HFS
A somewhat more direct way to determine the boot volume`s device node is just to invoke
bless --getBoot
, provided it works in your environment.- Now run
asr restore --source source_device_node --target target_device_node --erase
Invoked this way,
asr restore
will restore(clone) and verify both partitions,Macintosh HD
as well asRecovery HD
.
Back in Normal Mode, run
diskutil rename
to assign more meaningful names to the two partitions just "made" byasr restore
, something like "my_mbp2015_macintosh_hd_osx10.11.6_yymmdd" and "my_mbp2015_recovery_hd_osx10.11.6_yymmdd" resp.