What makes an external disk bootable?

Once upon a time, I’m sure all you needed to make a disk bootable was a System file and the ‘blessing’ of that disk. Then Apple decided we had to have System Folders, and OS X made it even more complicated. This article tries to outline what an external disk now needs for it to be bootable using a modern Mac.


Making a disk bootable is something we normally leave a macOS installer to fix for us. If you use a utility like Carbon Copy Cloner or SuperDuper! to clone an existing bootable volume group to a disk, that too should spare you the hassle. But when either goes wrong and you discover that Startup Disk won’t let your Mac start up from that volume group, it’s important to discover what might have gone wrong.

To understand this, consider how an Intel Mac boots from macOS Mojave or earlier, and where that can fail. That’s summarised for older Intel Macs and those with T2 chips in the following diagram.


One fundamental requirement is that the hardware, the Mac’s interface, cable and drive enclosure, all must support booting that Mac. Some older enclosures offer connections that can’t be used for booting, in which case you’re onto a loser from the start. For T2 Macs, it also requires that booting from an external disk has been enabled using Startup Security Utility in Recovery mode. Although you’ll see some claim that’s also necessary for Apple silicon Macs, it isn’t, and their Startup Security Utility doesn’t offer it as an option, because it’s always possible to boot an Apple silicon Mac from an external disk when everything else is right.

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.


Starting partially in Catalina, and in full from Big Sur onwards, the required container and volume structure on an external bootable disk is essentially the same as that on the internal storage of an Intel Mac, as shown in the diagram below.


There’s the traditional hidden EFI partition, even for Apple silicon Macs that don’t do EFI at all, and an APFS container with the bootable system, consisting of five volumes:

  • the SSV, a mounted snapshot of the unmounted read-only System volume named by default Macintosh HD, which forms the root of the boot file system. The snapshot is named com.apple.os-update- followed by its UUID, and the volume (hence its snapshot) is typically about 15 GB in size;
  • the writable Data volume, by default named Macintosh HD – Data, which is normally hidden from view at /System/Volumes and accessed via firmlinks;
  • Preboot, a small volume;
  • Recovery, the paired Recovery Volume;
  • VM, containing virtual memory caches.

Note that the Seal on the unmounted read-only System volume is normally broken, but it’s the snapshot that’s important: that should be sealed, unless you have broken its seal intentionally.

On Apple silicon Macs running Big Sur, but not Monterey or later, the paired Recovery volume isn’t used, but Recovery mode always boots from its hidden container on the internal SSD.

Apple silicon Macs

Unlike Intel Macs, M-series Macs always start their boot process from their internal SSD, even when they’re going to complete it from an external bootable disk. This is to ensure that their boot process is secure throughout, using a verified chain of trust through each step in the process.

This starts with the Boot ROM, which validates the Low Level Bootloader (LLB), stage 1 of the boot process. The LLB in turn validates other firmware to be used in Stage 2, the LocalPolicy to be applied to the external startup disk, and iBoot (Stage 2) itself, in accordance with the requirements of the applicable LocalPolicy.

The user controls LocalPolicy through Startup Security Utility, which is only accessible in Recovery Mode, and requires user authentication. There is no LocalPolicy which applies to all users and all disks, though: each LocalPolicy is specific to a System Volume Group and authorised user. For example, these can allow:

  • a single bootable external disk to be used to start up two or more Macs;
  • one Mac to be started up from any of several System Volume Groups, which can be running older versions of macOS, or load third-party kernel extensions.

Default LocalPolicy created for each bootable external disk provides Full Security, which among other things blocks the loading of third-party kernel extensions and requires SIP to be fully enabled. iBoot (Stage 2) validates kernel collections, signed System volumes, and other components to ensure their integrity, and that the kernel, extensions and macOS to be loaded have an acceptable version number.

LocalPolicy is created when installing macOS to an external disk, when the boot volume group on that disk is assigned its Owner. It can also be created when selecting the boot volume group on a bootable external disk to be the startup disk, in the Startup Disk pane (or in Settings), if it doesn’t already have a valid LocalPolicy, for example when you want to boot from an external disk previously created using another Mac.

LocalPolicy can be changed, in particular changing Secure Boot settings using Startup Security Utility, by first booting from that boot volume group, shutting down, and starting up in Recovery mode. That sequence is essential to ensure that the Mac boots into the Recovery volume paired with the System volume whose security settings are to be changed (Monterey and later).

The current startup disk setting is stored in NVRAM, which on Apple silicon Macs can’t readily be reset by the user. In the event that disk can’t be used to boot that Mac, it will normally fall back to starting up from the internal SSD.

This is a more convoluted process in the event that the expected startup disk can’t be found at all: in that case, there will be a long delay in startup, during which the power light will remain on but the display will be black. Eventually, when all hope of finding the missing boot disk is abandoned, the Mac will boot from the hidden Recovery container on the internal SSD, normally used as Fallback Recovery, enabling the user to choose another startup disk and restart from that.


There’s a great deal more required for an external disk to be bootable than just having a valid macOS installed.

Intel Macs without T2 chips are simplest, but even they now require a complete boot volume group and EFI container/partition. T2 models also require their boot security changed using Startup Security Utility, to allow them to boot from external disks.

Apple silicon Macs are the most complex, in requiring LocalPolicy with an Owner. If that isn’t configured correctly, they will be unable to boot from that external disk. However, they don’t require to have their Secure Boot settings changed: unlike T2 models, by default they can boot from external disks in Full Security.