Make yourself an external bootable disk for an Intel Mac and what you get is essentially the same as on its internal storage. It has two partitions, one the traditional EFI in FAT32 format, the other an APFS container within which are the boot Volume Group and the Recovery volume, as shown in the lightly revised diagram below.

The same is true for an external bootable disk for an M1 Mac, which comes complete with its EFI partition and the single container with its boot Volume Group and a volume named Recovery too. But that’s very different from the structure and contents of that M1 Mac’s internal storage. Thanks to some deeper exploration by Hector Martin of the Asahi Linux project, and some spade work with diskutil, we can now make a bit more sense of what’s on that internal storage, and why it’s so different from what we’ve come to expect.

When you boot an M1 Mac into its new Recovery Mode, it isn’t using the Recovery volume from the standard boot container at all, but what Apple calls 1 True Recovery (1TR) from the Apple_APFS_Recovery container, something which doesn’t exist on an external bootable disk. Many of its features, notably its Startup Security Utility which you can use to change the security policy, are only available in 1TR. As that can’t exist on an external bootable disk, and its command line equivalent bputil is largely limited to 1TR, it’s the internal storage which really controls that Mac, even when it’s booted from an external disk.

The three containers on an M1 Mac’s internal storage have distinct functions.

The first, Apple_APFS_ISC, is the iBoot System Container (iSC), and supports the iBoot firmware in the early boot process, as well as providing trusted storage for the Secure Enclave within the M1 SoC. Like the two other containers, it can have designated ‘booter’ and ‘recovery’ volumes, indicated in the above diagram by an asterisk • next to the volume name. Here, the iSCPreboot volume is the designated booter, and the empty Recovery volume is for recovery. The xART (volume name) or xarts (volume mountpoint) volume provides trusted storage, while the Hardware volume contains hardware-related files such as logs and activation data.

The Apple_APFS_Recovery container is dedicated to providing 1TR, which is stored on its Recovery volume. This includes a second part of iBoot and all that’s necessary for the M1’s full Recovery Mode. That Recovery volume is designated for recovery, but this container doesn’t have a separate booter volume.

The normal boot container Apple_APFS isn’t quite the same as that on an Intel Mac either: one subtle but significant difference is that the Data volume isn’t named Macintosh HD – Data, but simply Data. If you use code which relies on finding the Data volume by name, you’ll need to check whether that still works. Although this container still has a Recovery volume, this is more limited and can’t access security policy, for example.

If you’re unfortunate enough to completely wipe your M1 Mac’s internal storage, the only way to recover it is to restore the whole firmware and software image in DFU mode with Configurator 2. When that’s done, as far as your Mac and Apple are concerned, it’s effectively a new Mac and has to undergo full setup from scratch.

When you start up an M1 Mac from an external disk, the first part of the boot process still runs from internal storage and the iBoot System Container, so that it establishes saved security policy. However, a separate policy is saved for each system install. This makes it possible to engage a different policy when booting from an external disk from that for the internal SSD, and for alternative systems installed on the internal storage too.

For those wanting to dual boot an M1 Mac, it changes the process markedly. The iSC and 1TR containers on internal storage provide boot support and recovery for older versions of macOS which are installed. This is much cleaner than on Intel Macs, where each version has its own Recovery volume, which can lead to confusion and error. On the other hand, it’s reliant on the iSC and 1TR remaining backward-compatible with older versions of macOS, a problem which might become apparent with macOS 12 later this year.

This ingenious new boot process does have consequences, though. Failure of internal storage means failure of the whole Mac, which can’t then boot from an external disk, which lacks the essential iSC and can’t provide 1TR either. I think this is already true for Macs with T2 chips, with their single security policy, rather than one for each bootable operating system as in the M1. I suspect it’s also, in part at least, responsible for the lack of an Internet Recovery Mode in M1 Macs.

This explains the differences in what you see ‘mounted’ in the /System/Volumes folder on Intel and M1 Macs: what are real volumes in separate containers on the M1 Mac’s internal storage are only shadowed folders to an Intel model.

As alternative operating systems, like Asahi Linux, start arriving for M1 Macs, we’ll start seeing them use the potential of these new features.

Postscript:

I can see the consequences of iSC and 1TR only existing on internal storage are causing some conceptual problems. Perhaps the simplest way to consider this is that they are effectively part of the M1 Mac’s firmware: to boot, either from any disk or to 1 True Recovery, the M1 Mac has to load from iSC, or iSC+1TR. Just as you can’t copy/clone/backup firmware to another disk, so you can’t with iSC or 1TR.