Carbon Copy Cloner
Knowledge Base > Carbon Copy Cloner 4

What makes a volume bootable?

Section

This documentation is for an older version of CCC. This article has been retired, so it does not exist in the knowledge base for the newest version.
Last updated on September 13, 2016

Bootability comes down to a few simple rules:

  1. The hard drive enclosure must support booting a Macintosh (applies to external hard drives only).
  2. The computer must support booting from the interface used to attach the hard drive (e.g. USB, Firewire, Thunderbolt).
  3. The computer must support booting from the hard drive's partition format (e.g. GPT vs MBR).
  4. The cloned filesystem must have all the required components of macOS.
  5. The cloned operating system must be properly "blessed".

When you buy a hard drive enclosure that you intend to use to boot your Mac, caveat emptor — not all enclosures will boot a Mac (or any machine for that matter). Be sure to check that the manufacturer or vendor supports booting a Mac with the enclosure.

The interface that is used to connect the hard drive enclosure to your Mac also has an effect on bootability. Macs that did not ship with native support for USB 3.0, for example, may have difficulty booting from a USB 3.0 device. Some Macs can only boot from a particular USB 3.0 enclosure if it is connected to the Mac via a USB 2.0 cable. Some enclosures offer both Firewire (or Thunderbolt) and USB connectivity, but only one of the interfaces works for booting a Mac.

Once you have your new hard drive (in an enclosure or installed into your computer), you need to a) apply a partitioning scheme to the disk and b) format one or more volumes on the disk. Even if you do not plan to "partition" the disk, that is, slice the disk into smaller volumes, you still need to apply the correct partitioning scheme to the disk. Every disk has a partitioning scheme, even if it only has a single volume.

Rules #1, #2 and #3 are external to the functionality of CCC. CCC will not apply a partition scheme to your disk, nor will it affect or modify your partition scheme during an ordinary backup procedure (modifications are made to partitioning when creating a Recovery HD, but this is a manual task within CCC). Also, if a hard drive enclosure won't boot macOS, there's no software solution that will resolve that problem. Once you're sure you have those rules in hand, we can look at rule #4.

Rule #4 is pretty intuitive — if you want the operating system to boot, it must be whole. If you've cleared rules #2 and #3, CCC will tell you whether your destination will have all the necessary components to boot macOS. CCC's analysis is not exhaustive — CCC will verify that the following items are present on the source and will be copied in their entirety to the destination volume:

/Library
/System
/bin
/etc
/mach_kernel
/private
/sbin
/tmp
/usr
/var

So, if you choose to exclude /Applications or /Users for example, the cloned volume would still very likely boot. Likewise, if the source volume's OS is not whole and, as a result, not bootable, CCC doesn't do an extensive analysis of the OS to confirm that it will boot. The bottom line, though, is that CCC will give a pretty good indication about whether your destination volume will have the right OS components to actually boot.

Rule #5 is perhaps the least understood (and most technical), so I'll do my best to explain it here. When a Macintosh boots, the following sequence of events occur:

  1. The computer performs a Power On Self Test. When that test succeeds, you hear the characteristic Macintosh startup chime.
  2. The computer's pre-boot firmware (software that is embedded in a chip on the computer's motherboard) takes account of the hardware that is present, builds a device tree, and determines which hardware device to boot from (more on this in a bit). For the sake of simplicity, let's suppose a machine is configured to boot from particular volume on a particular hard drive.
  3. The firmware of the computer accesses the filesystem of that volume and determines the location of the file, or folder containing the file, that is "blessed" to initiate the operating system.
  4. That file is executed by the firmware and control of the hardware is handed over from firmware to the booter.
  5. The booter executes the kernel of the operating system and pre-loads a kernel extensions cache (or in later OSes, the booter loads a pre-linked kernel cache file).
  6. The kernel initiates the rest of the boot process (primarily by executing launchd).

The gist of all of this is that every bootable volume must indicate the location of the system folder. The path of the folder turns out to be irrelevant, because the HFS+ filesystem simply stores the "inode" of this particular folder. The inode is basically like a street address for the file, it indicates where on the disc platter the folder is located. This information is stored in the HFS+ Volume Header, but you can easily see the current state of this information using the "bless" command in the Terminal application. For example:

bash-3.2# bless --info "/Volumes/Backup"
finderinfo[0]: 116 => Blessed System Folder is /Volumes/Backup/System/Library/CoreServices
finderinfo[1]: 546345 => Blessed System File is /Volumes/Backup/System/Library/CoreServices/boot.efi
finderinfo[2]: 0 => Open-folder linked list empty
finderinfo[3]: 0 => No OS 9 + X blessed 9 folder
finderinfo[4]: 0 => Unused field unset
finderinfo[5]: 116 => OS X blessed folder is /Volumes/Backup/System/Library/CoreServices

The relevant information in this case is that the blessed system folder is at inode 116, and that path (for the human reader) is /System/Library/CoreServices. The "Blessed System File" information indicates where the secondary boot loarder ("booter") resides. In this case, that is the file at inode 546345 and (again, for the human reader), that file is located at /System/Library/CoreServices/boot.efi.

If you ever need to bless a volume manually (for example, if CCC indicated that it was unable to bless the volume), you could run this command in the Terminal application:

sudo bless --folder "/Volumes/Backup/System/Library/CoreServices"

It is important to note that blessing a volume is different than specifying a boot device. Blessing a volume simply updates the information in the HFS Volume Header that indicates where the blessed system folder and file are located. When you specify a particular volume as the startup disk, on the other hand, the computer stores a reference to that volume in the "Non volatile RAM" — basically a small section of RAM whose contents are not lost when the machine loses power or is shutdown. The importance of this disctinction, and all five of these rules for that matter, is that simply setting a volume as the startup disk may not be sufficient to actually boot from that volume.