The last piece in the puzzle that is the booting of a Mac is understanding how any given volume is made bootable, and how it can be made the next startup volume.

This used to be simple, before the advent of SIP, APFS, and Secure Boot in the T2, and came down to a single very complex command bless. That could:

• write the information to the volume header which declared that volume as being bootable;
• set the two NVRAM variables efi-boot-device and efi-boot-device-data to make any bootable volume the next startup disk;
• prepare a volume so that it could be made bootable, by copying boot.efi to the right place;
• configure the Mac to boot not from a local volume but from a server, using NetBoot;

and more. You can see why bless is complex to use.

Now, the only use of bless which you should be happy with, unless you really know what you’re doing, is
bless --info
which returns information about the current boot settings, such as
finderinfo[0]: 325985023 => Blessed System Folder is /System/Library/CoreServices
finderinfo[1]: 342576416 => 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]: 325985023 => OS X blessed folder is /System/Library/CoreServices
64-bit VSDB volume id: 0x[omitted]
The numbers given for each of the lines in the boot settings are the file system inode numbers, which are more persistent than the conventional paths which they resolve to. macOS here uses inode numbers instead of paths; you can use my free utility Precize to explore inodes and their relatives.

Try this command on a Mac booted from an APFS volume, and you’ll be disappointed: you either have to run it with privileges as
sudo bless --info
or after mounting the preboot volume, which rather defeats its purpose, perhaps. You’ll then be given the inodes and paths to the Blessed System File and Folder on that preboot volume, and the Blessed Volume for the container should be given as the root path, /.

If you use any of its other options, there is always the risk that you will render that Mac unbootable (at least temporarily), so you should be extremely cautious.

Making a volume bootable is a task which the user very seldom has to do. When you install macOS on a volume, the installer should do that for you as part of the service. If you use a tool such as Carbon Copy Cloner or SuperDuper to clone an existing bootable volume, one of its options should be to make that cloned disk bootable by blessing it. Only if that fails, or if you are trying to perform this task by hand, should you ever need to use the bless command in anger. When you do, study its man page very carefully and make sure that you get the command right.

The first blow to bless came in macOS 10.11: one of the side-effects of SIP is that it shouldn’t be used to try to set the startup disk. Its replacement is systemsetup -setstartupdisk if you need to do this at the command line. Only that doesn’t work in T-2 equipped iMac Pro models, which apparently require you to enter Recovery mode and disable SIP before you can use the command. Secure Boot is another issue which can limit what you can do with bless, an issue which is still being explored, as far as I can tell.

Additionally, bless is currently suffering from a bug which makes it incompatible with APFS containers on Apple RAID arrays: it is unable to find the Preboot volume in that case, and cannot set the container up as being blessed.

Before you try blessing any volume, you should ensure that it has what it takes to be a boot volume too. Normally, on a non-T2 Mac booting from an HFS+ disk, it needs a boot loader at /System/Library/CoreServices/boot.efi. A helper partition is normally used when a disk is encrypted using HFS+ FileVault 2, or the storage device requires additional drivers, such as an external RAID array.

On a non-T2 Mac booting from an APFS disk, the boot loader should be in the path [UUID]/System/Library/CoreServices/boot.efi on the special Preboot volume /dev/disk1s2.

One final requirement which is sometimes forgotten, but which can stop any of this from happening, is that the hardware – the Mac’s interface and the drive enclosure (for external disks) – must support booting that Mac. Some drive cases offer connections such as USB 3 or Thunderbolt which cannot be used to boot through, even though many other external drives use the same connection very successfully. This affected some who tried to install early betas of macOS Mojave on external drives, for example, although in most cases the installation failed. Changing the interface used and the connection can often work around these quirks.