MacOS – Problem cloning the startup disk of a MacBook Pro running OS X 10.11.6 El Capitan

command linemacbook promacospartitionstartup

Before putting my question in detail, see Problem section below, I'd like to sketch the context in which it appears.

Hardware-Software-Environment

MacBook Pro Early 2015 running OS X 10.11.6 El Capitan.
The internal HD is actually a 250 GB SSD comprising partitions EFI, Macintosh HD and Recovery HD.
External 2 TB HD connected via USB 3.0 Bus; later on called target disk.

Task

Create a bootable clone of the startup partition and, in addition, of the associated recovery partition. Provide a robust and simple command line based procedure.

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.
1. Determine the size of the Macintosh HD partition via
  diskutil info source_disk_id.
2. Determine the size of the Recovery HD the same way running diskutil info; usually yet another 650 MB.
3. 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 the Macintosh HD, including free space. This is more or less a precaution to prevent asr restore, later on used, from complaining about missing space.
  When the cloning operation will be accomplished, the target partition's size may be reduced running diskutil resizeVolume.
4. 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 the diskutil 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.
Switch to recovery mode and 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 as Recovery HD.
Back in normal mode, run diskutil rename to assign more meaningful names to the two partitions just "made" by asr restore, something like "my_mbp2015_macintosh_hd_osx10.11.6_yymmdd" and "my_mbp2015_recovery_hd_osx10.11.6_yymmdd" resp.

Problem

With the external HD connected, invoke the Startup Manager holding down the ⌥ Option key on starting or restarting the machine.

The Startup Manager brings up the volume icons of those partitions on the HD it considers bootable. Select the icon corresponding to the newly created startup partition and initiate the boot process by double-click.

Now, without any word of consolation, the system boots from the internal Macintosh HD. Obviously the system does not recognize the newly created startup partition as bootable.

Question: What is wrong with the above procedure trying to create a bootable clone? Any advices and suggestions are welcome.

Test and Fixing Attempts

Check and Repair Partitions
When checking the new startup partition diskutil verifyvolume reported:
```
Checking volume information
Invalid volume free block count
(It should be 25379769 instead of 23010379)
Volume header needs minor repair
The volume my_mbp2015_macintosh_hd_osx10.11.6_200106 was found corrupt and needs to be repaired
File system check exit code is 8
Error: -69845: File system verify or repair failed
Underlying error: 8: POSIX reports: Exec format error
```
The associated recovery partition, however, is considered OK.

Subsequent "repair" of the startup partition via diskutil repairVolume appears to be successful, at least in the sense that diskutil verifyVolume does not complain any longer.

Unfortunately this repair attempt finally was not successful because the system still does not recognize the "repaired" startup partition as bootable.
Disk Utility Restore
When we employ the "Restore" feature of the GUI Disk Utility with processing step #2 above instead of asr restore, the startup partition and the associated recovery partition appear to be cloned correctly, at least diskutil verifyvolume does not complain and on subsequent start or restart, the system boots from the newly created startup partition if told to do so.

I'm pretty sure that with Disk Utility "Restore" the command asr restore will be invoked under the hood to do the job. The question then is what else may happen. I guess some additional attribute might be set using the somewhat opaque "adjust" option documented like this:
asr adjust --target <partition> [--settype <partType>]
External HD
The external target HD itself is not considered suspicious because there reside several bootable partitions on the disk from which the system boots without problems.
Start from "logical" Macintosh HD Volume
As we learned from @klanomath, see below, in our case where the Macintosh HD is a CoreStorage volume, we should take the corresponding logical volume as argument for asr restore --source.

So we run in Recovery Mode:
```
asr restore --source /dev/disk2 --target /dev/disk16s6 --erase
    Validating target...done
    Validating source...done
    Erase contents of /dev/disk16s6 
(/Volumes/my_mbp2015_macintosh_hd_osx10.11.6_200106)? [ny]: y

Source volume is read-write and cannot be unmounted, so it can't be block copied.
```
In such cases, some other process may keep the volume Macintosh HD volume busy. Try to address the problem, unmount the volume running diskutil unmount and rerun asr restore with the same parameter settings as before.

Side Trip: Figuring out the Logical Startup Volume
A reliable, while not „scriptable“, way: Immediately after logging in to an account start the GUI Disk Utilitiy. You will find the startup volume highlighted. Enter ⌘I to see the same volume information as otherwise displayed by the diskutil info command.

In this particular case where the startup volume is actually a (mounted) CoreStorage partition, we can determine the corresponding logical volume from the diskutil coreStorage list output:

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:                  disk1
        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

Surprisingly, the most obvious method failed: bless --getBoot --verbose (–verbose option just added to have somewhat more information)

EFI found at IODeviceTree:/efi
Current EFI boot device string is: '<array><dict><key>IOMatch</key><dict><key>IOProviderClass</key><string>IOMedia</string><key>IOPropertyMatch</key><dict><key>UUID</key><string>56173D2D-142D-4425-AA07-DC6762337E8C</string></dict></dict><key>BLLastBSDName</key><string>disk10s3</string></dict></array>'
Boot option is 8BE4DF61-93CA-11D2-AA0D-00E098032B8C:Boot0080
Processing boot option 'Mac OS X'
Boot device path incorrect
Boot option does not match XML representation
XML representation doesn't match true boot preference

Resetting the NVRAM fixed the problem. Reset method used: Hold down ⌥ Option ⌘ Command P R keys on starting the machine. Now the blesscommand returned the boot volumes's device node as expected:

bless --getBoot
/dev/disk1

For the sake of completeness, bless --info /Volumes/Macintosh\ HD recorded:

finderinfo[0]: 1430821 => Blessed System Folder is /System/Library/CoreServices
finderinfo[1]: 2587775 => Blessed System File is /System/Library/CoreServices/boot.efi
finderinfo[2]:      0 => Open-folder linked list empty
finderinfo[3]:      0 => No alternate OS blessed file/folder
finderinfo[4]:      0 => Unused field unset
finderinfo[5]: 1430821 => OS X blessed folder is /System/Library/CoreServices
64-bit VSDB volume id:  0x839BA1DBB460E54F

Sources and Footnotes

Disk image of OS + Recovery partition?
Contains reference to the asr utility: Will restore both the system partition and the associated recovery partition as well.

https://derflounder.wordpress.com/2013/04/30/asrs-hidden-documentation/
Reveals that there is a hidden documentation for the asr utility.

https://bombich.com/kb/ccc4/help-my-clone-wont-boot
Very instructive cheat sheet from Bombich Software dealing with bootability problems. Although this text refers to their CCC product, it contains a lot of generally useful hints.

What makes a volume bootable?
Another useful text from the Bombich Software knowledge base dealing with a Mac's boot process and on how to "bless" a bootable volume.

Resetting and setting NVRAM
Some words on the nvramcommand.

Apple Core Storage
Educational text on Apple Core Storage.

Best Answer

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 or diskutil cs list list it, but it's difficult to extract the device node with tools available in Recovery Mode (with e.g. awk ... or sed ...) - at least for me with limited shell scripting capability. The best I have found is bless --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 the asr ... 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.

Related Solutions

The ‘Mac OS X Base System’ disk image on the 2011 MacBook AIr

It's rather complicated, and actually a lot of the complexity is to avoid wasting space; I don't think you can "reclaim" anything without breaking it.

Let me start at the beginning: your hard drive (/dev/disk0) has two relevant partitions: Macintosh HD (your regular startup volume), and Recovery HD.

(Update: with newer versions of macOS running from an APFS volume, there'll instead be a single APFS "container" on the disk; the volumes under it will be listed separately under a "synthesized" device, probably /dev/disk2. And in addition to Macintosh HD and Recovery, there'll probably be Preboot and VM volumes, and starting in Catalina there'll be a separate "Macintosh HD - Data" volume holding the user-modifiable parts of the main filesystem. And some other details are different, but actually not that much.)

Recovery HD is marked in the partition table with the type Apple_Boot, but is actually in the normal HFS+ format. It contains minimal booter files and kernel, and at /com.apple.recovery.boot/BaseSystem.dmg, a disk image with a stripped-down and tweaked copy of OS X. The booter mounts this volume (it attaches as /dev/disk1), and transfers to OS X running on it. This is the Mac OS X Base System.

Notice that the Recovery HD is only 650MB, but Mac OS X Base System is 1.4GB? That's because it's a compressed disk image (and I'm pretty sure that compression is the reason they bother with all this disk image trickery). Actually, BaseSystem.dmg is compressed down to only 451MB (at least in OS X v10.7.0).

Also, the volume naming is somewhat inconsistent. You've got /dev/disk1s3 named "Recovery HD", but for some reason it's mounted as "/Volumes/Image Volume" in recovery mode. BaseSystem.dmg has a volume named "Mac OS X Base System".

So that's disk0 and disk1; what about the rest? I'm not certain, but I'm pretty sure they are RAM disks to save temporary data in folders OS X modifies as it runs (remember that in recovery mode, you're running from a read-only disk image). Running the mount command in recovery mode is informative:

$ mount
/dev/disk1s3 on / (hfs, local, read-only)
devfs on /dev (devfs, local, nobrowse)
/dev/disk2 on /Volumes (hfs, local, union, nobrowse)
/dev/disk3 on /private/var/tmp (hfs, local, union, nobrowse)
/dev/disk4 on /private/var/run (hfs, local, union, nobrowse)
/dev/disk5 on /System/Installation (hfs, local, union, nobrowse)
/dev/disk6 on /private/var/db (hfs, local, union, nobrowse)
/dev/disk7 on /private/var/folders (hfs, local, union, nobrowse)
/dev/disk8 on /private/var/root/Library (hfs, local, union, nobrowse)
/dev/disk9 on /Library/ColorSync/Profiles/Displays (hfs, local, union, nobrowse)
/dev/disk10 on /Library/Preferences (hfs, local, union, nobrowse)
/dev/disk11 on /Library/Preferences/SystemConfiguration (hfs, local, union, nobrowse)
/dev/disk12 on /Library/Keychains (hfs, local, union, nobrowse)
/dev/disk0s2 on /Volumes/Macintosh HD (hfs, local, journaled)
/dev/disk0s3 on /Volumes/Image Volume (hfs, local, read-only, journaled)

Those "union" attributes mean that things in the relevant folder in the startup volume will be visible, but anything modified gets stored in what I'm pretty sure is a RAM disk.

If you want to look at this stuff yourself, you can mount the relevant volumes from the regular OS:

# Mount "Recovery HD":
$ diskutil mount /dev/disk0s3
# Mount "Mac OS X Base System":
$ hdiutil mount /Volumes/Recovery\ HD/com.apple.recovery.boot/BaseSystem.dmg -noverify

MacOS – Boot Camp failed and reduced Macintosh HD partition from 3TB to 1,46TB

The first thing I would try is to open Boot Camp Assistant and see if you can remove the partition. Whether Windows was installed or not, this should be possible.

Alternatively, since I'm guessing you haven't repartitioned your drive since you installed El Capitan, you won't be able to resize the partition unless you use a source outside of your computer. Even in recovery mode, you won't be able to repartition. You might be able to resize it in Disk Utility if you use Internet Recovery: CMD + Option + R at boot. Another option would be to boot into recovery mode, install OS X on a USB drive, then from the installation on that USB drive, you would for sure be able to resize your partition.

I have done this many times, so I understand the frustration it can cause when you have space that you can't recover and the only way to get it back involves several hours of your time.

The good news is that if you ever start with a fresh partition in El Capitan, their new partition scheme is resizable even when you're using it live so you wouldn't need to ever even touch Recovery Mode.