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

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

1. 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.

2. 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.

3. 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

1. 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.

2. 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>]

3. 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.

4. 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.

5. 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.

Solution 1:

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:

1. 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.

2. 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.

Solution 2:

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

1. 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.

2. Switch to Recovery Mode

   1. Determine the source_device_node
      When we have a look at the CoreStorage Logical Volume Group to which the Macintosh HDbelongs, 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 is Apple_CoreStorage while partition type of the Logical Volume is Apple_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.

      2. 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 as Recovery HD.

3. 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.