Serandib was apparently the original Arabic name for the island we now know as Sri Lanka. In 1505 the Portuguese explorer Dom Lourenco de Almeida arrived by chance on that island they already knew by the name of Seylan. This fortuitous discovery became incorporated into an English name for the island of Serendip, and from that Horace Walpole coined the word serendipity.

Last week I had my share of serendipity, when I was browsing thousands of log entries looking for those recording the post-boot checks made by Software Update and its related services and subsystems. Among those exhaustive exchanges was an unusually long entry spanning multiple lines, in which one of those subsystems, SoftwareUpdateMacController, listed all sorts of deep information about versions of macOS and recoveryOS it had found on that Mac.

Such long entries appear from time to time in the log, often listing dictionaries of key-value pairs being passed between components of macOS. In most cases, the information is of only passing interest, useful if you’re trying to get your head around a problem, but not the sort of thing you want to save for posterity. In this case, it looked to be pure gold.

The particular log extracts I was browsing were taken from a series covering the first minute after the initial entry by the kernel after a macOS guest VM started up. Studying log records from a virtual machine rather than a real Mac has several advantages. It omits the seemingly endless entries detailing all the hardware in an Apple silicon chip booting and being prepared for action. Some loquacious systems, like Wi-Fi, aren’t supported by Apple’s Virtualization framework, so removing even more clutter. But many subsystems, like those involved with Software Update, run much the same as they do on a real Mac. The VM therefore acts as a filter cutting the rate of log entries from tens of thousands per second to as little as a tenth of that.

What caught my eye was a single line:
recoveryOSProductVersion: 12.4
on a VM in which macOS 12.5 was installed and booting. As this is Monterey, the normal paired Recovery Volume, within the boot volume group, will have been 12.5 too, so the version given here should be that in the separate Recovery container on the (virtual) internal SSD, which now functions not as the primary Recovery system, but as its fallback. Checking against a real M1 Mac confirmed that, as it reported a recoveryOSProductVersion of 12.3 for an installed macOS of 12.5. Not only that, but a T2 Intel Mac said firmly
hasRecoveryOS: NO
recoveryOSProductVersion: (null)
although it does of course have a normal paired Recovery volume. To clinch my interpretation, my M1 MacBook Pro running the current beta of Ventura reported a recoveryOSProductVersion of 12.2.1.

If you’ve ever tried investigating either primary paired or fallback Recovery systems, you’ll know how hard it is to get anything useful from them, as they’re mounted disk images rather than live volumes. Fallback Recovery is particularly tricky, as you sometimes can’t even be sure that you have booted into it. The only reliable criterion is that Startup Security Utility doesn’t work, and verifying that isn’t reliable.

Once I had confirmed the log entry that contained this information, I had to work out the best way to retrieve it without having to wade through thousands of irrelevant entries. This turned out to be using a predicate to the log show command of
subsystem == "com.apple.SoftwareUpdateMacController" && eventMessage CONTAINS[c] "Initialized new device:"
conveniently wrapped up in Ulbow’s GUI.

By popular demand, I then had to add this to Mints to provide ready access to the information without having to employ that predicate in Ulbow or Terminal. It was then that my serendipity grew: by looking at multiple entries over time, you can see what a macOS software update has actually changed in your Mac.

The next version of Mints therefore has a single button to display all those log entries over the previous 24 hours. To see what happens in a macOS update or installation, ensure your Mac has started up in the previous 12 hours or so prior to that update being installed. Once complete, Software Update should repeat its entry to provide a full account of what changed in that update, including whether it rotated your old paired Recovery system to become the new fallback Recovery for its updated paired Recovery.

The information provided becomes even more interesting for those now running Ventura beta, with its new patch update system, where you’ll be able to see what Splat is, and when it’s first used.

Finding an island, even one the size of Sri Lanka, in the Indian Ocean was a surprising achievement, and truly serendipitous. Although my moment of serendipity was far more modest, maybe it will prove more immediately helpful to you.