If you’re running Big Sur or Monterey, you’ll be only too aware that updating and upgrading them has changed completely. For a start, there are now only two ways to install a macOS update: an incremental update via Software Update or its command tool softwareupdate, or using a full macOS installer app. There’s also a whole volume devoted to updates, seen at /System/Volumes/Update, but what that does isn’t clear. This article looks at what you can glean from this volume, and what it reveals about the new update system.

There are two files in Update which you may find useful:

• nvram.plist is a dump of the contents of NVRAM at the time of the last update, which can be more comprehensive than you’ll get any other way. Because of the peculiarities of NVRAM on M1 Macs, it’s of more limited use with them.
• restore.log is a long text file which is, in effect, the installer log. It normally contains a full account of every macOS install or update made in that system since the first install of 11.0.1, so can be very large indeed. The rest of this article explains what you will find there.

In the tens of thousands of entries in restore.log, you should find the most complete account of what has happened in each macOS update since switching to the new installer in Big Sur or later. Although entries have sequence numbers, they’re given in hexadecimal, and probably correspond to Mach ticks rather than a regular datestamp. Oldest entries are at the start (top) of the file, and the latest update is at the end. The simplest way to navigate the file is by searching for the update number, e.g. 12.3.1, or its build number, e.g. 21E258, from the top down.

Contents differ considerably according to whether it’s an Intel or Apple Silicon Mac. Although both install common macOS files, much of the update process is concerned with preparation and checking, and dealing with firmware updates, which are completely different.

Periodically, you’ll come across short sequences of entries which record the submission of “events” to one of Apple’s servers. These appear to be instrumentation tracking progress of the update, so that Apple’s engineers can monitor updating performance and problems. Events are sent in JSONised XML, and mostly contain information about the Mac, the update, and its progress, rather than anything which could be used to identify you or your Mac. Apple’s server is at xp.apple.com/report, and connections are secured by TLS. I don’t know how dependent successful updating is on making these connections, although events for posting are held until they can be submitted successfully.

There are two important paths which each update keeps checking: the Update volume itself mounted at /System/Volumes/Update, and a temporary mountpoint at /private/tmp/tmp-mount-[letters] which is removed once the update has completed successfully. The Update volume itself is another volume linked to the active system volume group.

Intel Macs

Early in the process, checks are performed to see if there’s likely to be sufficient free space for preparation of the new SSV snapshot, and libauthinstall, one of the key tools supplied in and used by the update, checks whether this is a VendorInstall, InternalDevelopment, or CustomerInstall. In all normal cases, the update should be designated a CustomerInstall.

The update package is then verified with the pre.bom and post.bom, and its signature is verified. The patches to be applied are unarchived and prepared, files are fixed up, hard links created, and verified with the post.bom. Then follows the preparation of any bridgeOS update and the kernel and kernel collections (of kexts) are prepared. The new system is blessed, to make it bootable, and finally efiupdater is run to perform any necessary EFI firmware update.

Once the update is complete, there are entries in restore.log to indicate success, including:
process_update_result_state: Update attempted (21E230 -> 21E258)
process_update_result_state: Successful Update - made it to the new OS with "success" set in NVRAM

Final tidying up includes clearing out old preference overrides, ‘purging brains’ which is deleting the ‘brain’ updater, and cleaning up any unused prepared updates.

M1 Macs

In contrast, each session for an update in restore.log for an M1 Mac can be huge, and very taxing to navigate. It does a great deal more, including housekeeping tasks such as garbage collections of Preboot, Recovery and iSC Preboot volumes. One valuable new feature in Monterey updaters is that they can also update Rosetta 2, rather than that being performed separately.

Considerable work is performed early on to personalise the update, and the Secure Enclave Processor (SEP) is kept ‘mounted’ for much of the update. In addition to events posted to xp.apple.com, a POST request is sent to gs.apple.com using plain HTTP. Trust is checked on all the components to be installed, as well as verification of the package contents and its signature.

Among the firmware which can be installed are each of the mutable components used in the boot process, and specialist firmware for the M1’s many controllers and chip features, such as its USB-C controller and Apple Neural Engine. Of those, only the iBoot version is readily accessible to the user. After the protracted firmware phase, the system software is updated in similar steps to an Intel Mac. Additional boot time installations such as RosettaUpdateAuto.pkg are then installed before final tidying up. Oddly, updating an M1 to 12.3.1 didn’t result in the declaration of success, despite the update being successful.

Conclusion

The restore.log can be excruciatingly long, and is designed for Apple engineers rather than users. It does contain useful information about all macOS updates since 11.0.1, and in the event of a failed or problematical update might prove useful. If you’re hoping to learn the secrets of how the updater seals and signs the System volume, then you’re likely to be disappointed, and at least some of the tools which the updater relies on are kept on the Update volume and destroyed when the update is complete.