Like the two other containers, it can have designated ‘booter’ and ‘recovery’ volumes, indicated in the above diagram by an asterisk 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.

The three containers on an M1 Mac’s internal storage have distinct functions. 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. Many of its features, notably its Startup Security Utility which you can use to change the security policy, are only available in 1TR.

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. 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. But that’s very different from the structure and contents of that M1 Mac’s internal storage. 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. 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. Make yourself an external bootable disk for an Intel Mac and what you get is essentially the same as on its internal storage.

Mac os disk utility cannot resize