It seems such a simple question: what in macOS makes a volume bootable, and how can you make any given volume or ‘disk’ bootable? Go back to the heyday of Classic Mac OS, and all it required was a System file, but now with Apple silicon Macs even proven command tools seem to draw a blank.

Before the advent of System Integrity Protection (SIP), this was all handled by one complex command tool, bless, which could:

• prepare a volume so that it could be made bootable, by copying boot.efi to the right place on it;
• 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 given bootable volume the next startup disk;
• configure the Mac to boot not from a local volume but from a server, using NetBoot.

In those days, bootability was mainly determined by information stored in the volume header in HFS+, boot.efi being in /System/Library/CoreServices/ on that volume, and the current boot volume was controlled in two variables in the NVRAM. Using bless --info returned 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]

Unfortunately, one of the side-effects of SIP when it was introduced in macOS 10.11 was that bless stopped working as it had in the past, and advanced users had to switch to using the systemsetup command instead. This was quickly finished off when Apple started putting T2 chips in Macs, adding Secure Boot, which effectively defeated simple command-line solutions.

A further set of complications came with Catalina, which replaced the earlier single boot volume with a pair forming a boot volume group. Even Macs without a T2 chip then expected to find boot.efi in [UUID]/System/Library/CoreServices/ in the special Preboot volume within the container holding any bootable volume group.

Finally came Big Sur, which came close to blowing away the whole concept of a boot volume, in mounting a snapshot of a specially crafted System volume in a boot volume group, with a Merkel tree of cryptographic hashes forming a seal. For those still hanging onto the old ideas of bless, this brings total frustration. The one ‘safe’ option to use, bless --info, then returned something like
Volume for path /dev/disk5s5 is not available
where disk5s5 is the original System volume. Even bless --getBoot returned the frustrating
/dev/disk5s5
when the mounted System was actually in the snapshot at disk5s5s1. Resorting to sudo systemsetup -liststartupdisks brought the unhelpful
/System/Library/CoreServices
which is almost a tautology.

Change architecture to an Apple silicon Mac, and all the above goes out of the window in favour of a signed LocalPolicy for that bootable volume group, named by its UUID. Without one of those, a volume group is unbootable however well-formed it might be. Try listing currently available startup disks using sudo systemsetup -liststartupdisks and you get an empty result. The only way that I know to discover which LocalPolicies exist is to use sudo bputil -d, then match the UUIDs with those for available bootable volume groups.

Apple silicon Macs also change the meaning of the word bootable in this context. The only volume groups that are truly bootable in an Apple silicon Mac are those in the internal SSD. It’s simple if messy to verify that by completely erasing the internal SSD and trying to boot from an external disk, because without starting the boot process from an internal bootable volume group that invariably fails, as intended. So too using an ‘external bootable macOS installer’, which curiously is still formatted in HFS+, isn’t really booting from that, but it’s a convenient illusion.

Given the long and complex list of requirements to make a volume group bootable, perhaps it’s a minor miracle that any of them work at all, so trying to perform the tasks once available in bless is wildly over-optimistic and doomed to failure. I have to admit that I don’t know exactly what does make a volume group in an Apple silicon Mac bootable, but it looks like most of the above. And maybe a bit more.