Less than a month ago, on 4 January 2018, my Mac running Sierra 10.12.6 kindly downloaded a ‘security’ update from 2016 and installed it, all without my knowledge. A few days ago, the same happened again. It’s only because I now keep a watch on such updates using my free SystHist that I noticed that at 1751 UTC on 29 January 2018, the OSX1012IncompatibleAppList update from the autumn of 2016 was installed again.

One problem in tracking such spurious updates is that their installer records are not just concealed – you won’t see them listed in normal places – but each new re-installation overwrites the old one. So now that is listed as being installed on 29 January, all trace of the previous spurious update on 4 January has vanished.

For all I know, my Mac may have been performing these spurious updates every month since Sierra was first installed.

This time, I have been more determined and prepared to find the cause of this odd and unwelcome behaviour, but have so far drawn a blank. As before, this seems to have been orchestrated by, and at the request of, migrationmanagerd, a service which I certainly didn’t use directly on either occasion. It’s possible that the stimulus was connecting a USB memory stick which contained a High Sierra update, as a disk image, but all my efforts to trace the cause have drawn a blank.

Investigating what did happen has been a good exercise of both my log browsers, Consolation 3 and Woodpile, and has centred on the activities of the subsystem com.apple.mac.install, which seems to have jurisdiction over migrationmanagerd, and like everything else here is completely undocumented.

com.apple.mac.install log entries are very hard to find, as they tend to be stored in Special log files not the more persistent ones, so are rapidly aged out of the records. Using Woodpile, I have found just two bursts of their entries, which coincide with the two spurious updates on 4 and 29 January, shown in the screenshot below. Outside of those, there are hardly any log entries for them to be found: searching in Consolation using the subsystem com.apple.mac.install returns next to no entries during most days.

For whatever reason, the com.apple.mac.install subsystem starts with the startup of systemmigrationd. Once ready, it announces
New connection for System Selection
then adds a client SMDSystemScanner_XPCClientConnection and logs
Inform Remote Client of new System
followed by a UUID for the event. I have no idea whether this ‘remote client’ is something else on the other side of the internet, although there don’t appear to be any truly remote connections set up to operate that. It then proceeds to scan all mounted volumes, as if they were something new, for each logging reports like
Volume Appeared : SKCSPVDisk { CSLV UUID: 41530D69-50AB-4E98-94E3-742546F818B5 BSD Name: disk1s2 Role: kSKDiskRoleStorageImplementation Type: kSKDiskTypeCSPV }
mountDiskIfNeeded: Disk (SKCSPVDisk { CSLV UUID: 41530D69-50AB-4E98-94E3-742546F818B5 BSD Name: disk1s2 Role: kSKDiskRoleStorageImplementation Type: kSKDiskTypeCSPV }) has mountpoint - No Disk is Disk Image - No Disk is locked - No Scanner Allowed to Mount - No

In this example, this reports that disk1s2, a Core Storage volume, doesn’t have a mountpoint, is not a disk image, is not locked, and is not allowed to mount.

It then checks the software update catalogue at
https://swscan.apple.com/content/catalogs/others/index-10.12customerseed-10.12-10.11-10.10-10.9-mountainlion-lion-snowleopard-leopard.merged-1.sucatalog.gz
and starts taking particular interest in the latest Time Machine backup on my backup disk (an external RAID). As a result of that, it downloads the spurious update and installs it, although the logs are not clear whether it is installed to the backup or startup volume:
17:50:14.035505 Began to install update to Incompatible Software Data.
17:51:21.208672 Update to Incompatible Software Data installed.
17:51:21.208684 Incompatible Software Data update process completed.

The com.apple.mac.install subsystem then removes its XPC clients and quits.

The Bill of Materials for this installation at /System/Library/Receipts/com.apple.pkg.OSX1012IncompatibleAppList.bom doesn’t tell us where the spurious update was installed, but the companion property list in com.apple.pkg.OSX1012IncompatibleAppList.plist reveals that the InstallPrefixPath was / – in other words, this wasn’t installed in the Time Machine backup, but in the current system location on the startup volume.

Pulling all this together, Sierra may, for no apparent reason, decide to run its com.apple.mac.install subsystem, in particular the System Migration daemon systemmigrationd. When that happens, it may decide quite incorrectly that it needs to download and install the current version of OSX1012IncompatibleAppList, although that is already installed. This occurs because it doesn’t check whether the version available from Apple’s update server is more recent than that currently installed.

Because this spurious update is performed not by softwareupdate but by systemmigrationd, no entry is made in the normal Install History. The only evidence that it has occurred is hidden away in /System/Library/Receipts. As the receipt files (.bom and .plist) there overwrite the earlier receipts for the last spurious update, there is no way of knowing how often these spurious updates are occurring.

Unusually, log entries from the com.apple.mac.install subsystem appear to be kept in more transient Special log files, and not moved to the Persist log files, which ensures that they are weeded from those files relatively quickly. For a subsystem concerned with installing and migrating system software, this is inappropriate, and can prevent investigation of any problems other than the very recent.

I count at least five distinct bugs there – you may recognise more. I’d be interested to know how many of them are fixed in High Sierra, which has its own Incompatible App List maintained by systemmigrationd as far as I can tell, but seems to use new com.apple.mac.install tools including MacBuddyX. More of those another time.