Before putting my question in detail, see Problem section below, I'd like to sketch the context in which it appears.
MacBook Pro Early 2015 running OS X 10.11.6 El Capitan.
The internal HD is actually a 250 GB SSD comprising partitions
Macintosh HD and
External 2 TB HD connected via USB 3.0 Bus; later on called target disk.
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.
disk identifier of the
Macintosh HD partition
device node corresponding to the
Macintosh HD partition
disk identifier of the target partition on the external HD
device node corresponding to the target partition
size of the target partition
Note: Used on invocation of a command, take care to use an appropriate size specifier.
Create the target partition that is to contain the bootable clone.
- Determine the size of the
Macintosh HDpartition via
diskutil info source_disk_id.
- Determine the size of the
Recovery HDthe 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 HDas 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
- 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 resizeVolumecommand 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 and run
asr restore --source source_device_node --target target_device_node --erase
Invoked this way,
asr restorewill restore(clone) and verify both partitions,
Macintosh HDas well as
Back in normal mode, run
diskutil renameto 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.
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
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 repairVolumeappears to be successful, at least in the sense that
diskutil verifyVolumedoes 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 verifyvolumedoes 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 restorewill 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>]
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"
As we learned from @klanomath, see below, in our case where the
Macintosh HDis 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 HDvolume busy. Try to address the problem, unmount the volume running
diskutil unmountand rerun
asr restorewith 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
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 listoutput:
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\ HDrecorded:
finderinfo: 1430821 => Blessed System Folder is /System/Library/CoreServices finderinfo: 2587775 => Blessed System File is /System/Library/CoreServices/boot.efi finderinfo: 0 => Open-folder linked list empty finderinfo: 0 => No alternate OS blessed file/folder finderinfo: 0 => Unused field unset finderinfo: 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.
Reveals that there is a hidden documentation for the
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
Apple Core Storage
Educational text on Apple Core Storage.