Catalina and Big Sur each bring major structural changes to boot disks. Big Sur builds on Catalina’s separate System and Data volumes by sealing the System using cryptographic hashes, making a snapshot of the result, then mounting that snapshot for use as its Sealed System Volume (SSV). Does that mean that Big Sur’s new SSV is impossible to clone to another disk or container?

To understand what is required to make a cloned System volume bootable in Big Sur, it’s instructive to consider the steps which macOS Installers and updaters go through. As we’ve not seen any production versions of these yet, I here look at broad concepts as described in Apple’s article about the SSV, and my own previous outline.

In both 10.15 and 11.0, the System volume has to be mounted read-write, SIP disabled, and the system files installed in their directory tree. Both also have to ensure that the correct firmlinks are made to link the System and Data volumes in the Volume Group, and install mutable system files to the Data volume.

Big Sur also has to create the hierarchy of SHA-256 hashes which form its new sealed system. These cover every file on the System volume individually, and the file system metadata, in a hierarchical structure culminating in a single top-level hash known as the Seal. That is then verified against a value which is signed by Apple, providing a chain of trust for everything in that System volume.

When that has been completed correctly, a snapshot is made of the new System volume, which is specially designated as a System snapshot and blessed. If there is more than one previous System snapshot on that volume, the old and now expired snapshot(s) should be deleted, leaving only the previous snapshot, to which macOS can roll back if needed, and the new one.

Both 10.15 and 11.0 conclude by enabling SIP and unmounting the System volume, then restarting the Mac in normal mode again. In Catalina, the System volume is then mounted read-only for use, while in Big Sur its Seal is checked first before mounting the new system snapshot.

These are summarised in this diagram.

Making a bootable clone in Big Sur has to pass through the same basic process as that, and its pinch point is the sealing process. Currently, performing that is the preserve of two Apple tools: its system installer, and the tool asr, Apple Software Restore. Apparently at present only the first of those is working, which means that third-party software designed to work with clones can’t use asr to seal a clone, making that clone unbootable, unless the user turns off cryptographic verification of the System volume altogether.

As it happens, this isn’t as disastrous as might appear. There’s a good workaround which you can use with Big Sur until asr is fixed and Carbon Copy Cloner and SuperDuper! can clone its System volume. Instead of trying to clone the SSV, simply install a new Big Sur System volume in a container with a cloned Data volume. Ensure the installer links the new System volume with the existing Data volume by selecting the latter as the ‘disk’ on which to install macOS 11.0.

Finally, where does this leave the traditional process of repairing the System volume in Big Sur?

If any damage occurs to the files or file system of an SSV, this immediately breaks its seal, for which the only remedy is to re-install macOS 11.0. It is possible to un-seal a system to modify it, but as only the system installer and asr can seal an unsealed System volume, there isn’t a place for repair tools. Neither should there be any need, as the System volume is only mounted as a snapshot on a read-only SIP-protected volume. Any damage which it sustains isn’t likely to be minor, and more likely to be the precursor to major or catastrophic failure.

I welcome corrections to the above, should any of it be in error.