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 M1 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;
• 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 done, and advanced users had to change to the systemsetup command instead. This was quickly finished off when Apple started putting T2 chips in Macs, adding Secure Boot, which effectively defeats simple command-line solutions.

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

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

Change architectures to an M1 Mac, and everything 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, the volume is unbootable. 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 those UUIDs with those for available bootable volume groups.

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. So I have to finally admit that I don’t know exactly what does make a volume in an M1 Mac bootable, but it looks like most of the above. And maybe a bit more.