Go back a few major versions of macOS, and all that had to happen to install a macOS update could be accomplished in scripts for the Installer app: it was basically a matter of copying a load of files to the System folder, rebuilding some key items such as the pre-linked kernel, containing both the kernel and all extensions to be loaded during startup, and that was it in a nutshell. This was made more complex with the arrival of SIP, when Apple necessarily gave itself a special free pass for its installers.
This became more complex when Apple split the startup volume into System and Data volumes in Catalina. For Big Sur’s new Sealed System Volume (SSV), there’s too much for Installer scripts to handle: building the bootable system now requires the whole System volume to have a Merkle Tree of cryptographic hashes culminating in the hash to rule them all, the Seal, which is compared against Apple’s requirement; then a snapshot is made of that, and the Mac started up from that snapshot.
Full installers are different
These differences are reflected in the full installers for macOS. Look inside one for Catalina 10.15.7, for example, and in the app’s SharedSupport folder you’ll see three Disk Images, each containing various parts of macOS to be installed.
A Big Sur installer comes in only one form, that’s a full installer, as there’s no such beast as a standalone Big Sur updater. What’s inside is also completely different: most of the payload is in a single Zip archive, which contains a whole load of files which appear quite alien. Some are in a format already used in iOS installations, but most are just large blobs of binary.
I have a suspicion that this new arrangement is convenient to Apple for several reasons, among them maintaining the security of the update process, in particular the construction of the Merkle Tree of hashes and sealing the System volume. Currently, once a user has broken the seal on Big Sur’s SSV, there’s no way to reseal it, even if its Seal were to match that prescribed by Apple, which seems highly improbable anyway. Were any user, whether well-intentioned or malicious, able to reseal the system, much of the value of the SSV would be lost. Extracting the tools necessary to perform resealing is currently extremely difficult; standalone delta updates could only increase the chances of that happening.
Big Sur updates
The simple process of downloading a few Installer packages and installing them has been replaced with a series of phases, best seen when updating an M1 Mac. A minimal update, such as that for macOS 11.2.1, is very large, and, if you run a local Content Caching Server and are updating an M1 Mac, requires a combination of fresh downloads and data from your local server’s cache.
The first gigabyte or so of the update has to be downloaded direct from Apple’s servers at [https] mesu.apple.com/assets/macos/ This includes a long list, such as
- Embedded Speech support,
- Ad Blocker,
- Home Kit,
- Software Authorization Header,
- Mac Update Brain, responsible for running the update,
- SFR Software Asset,
- Device Check,
- Time Zone Update,
- Context Kit,
- Kext Deny List,
- Core Suggestions.
For M1 Macs these are marked out so that they can’t be obtained from the Content Caching Server. The size of this additional directly downloaded part of the update is essentially the same as the difference in total size of macOS updates between Intel and M1 Macs, around 1 GB.
The bulk of the update, over 2 GB of it, can be obtained from the local server, and in the second phase of updating,that’s delivered very quickly indeed, as the progress bar races towards the end.
The third and final phase of obtaining the software update is its preparation, which normally takes 15 minutes. This is run by the Update Brain Service (com.apple.MobileSoftwareUpdate.UpdateBrainService), and includes checking and verification of the entire update to be installed, much in the way this occurs on iOS devices. This has to be performed locally, and isn’t affected by using a local Content Caching Server.
Once that phase has been completed successfully, the update proceeds.
Intel Macs follow a similar course, but when updating from a local Content Caching Server, any direct download from Apple’s servers is very small and not noticeable. They are thus able to update (almost?) entirely from that local cache, and significantly faster than M1 models.
Should you use a Content Caching Server?
If you have two or more Macs which you keep up to date with similar macOS updates, then a local Content Caching Server will save you time updating your Macs. As an example, here are comparable figures for my own situation.
I have four active Macs: two T2 Intel models, and two M1 Macs. Without the Content Caching Server, updating them all from macOS 11.2 to 11.2.1 would have required over 11 GB of direct download from Apple’s servers. Using the Content Caching Server, the total required to be downloaded falls to just over 4 GB: 2.3 GB for one Intel Mac, and 1 GB extra for each of the two M1 Macs. The cost of each additional Mac beyond those four is 0 GB for an Intel Mac, and 1 GB for an M1 model.
You can read more about enabling the Content Caching Server in this article.
Over the coming week or two, I will be looking in more detail at what happens during Big Sur updates.