Troubleshooting Munki failing to install Apple updates


If you see Apple updates (that require a reboot) not installing properly via Munki, it may be because the downloaded update is stale somehow. Not really 100% sure on how this works, since I've seen this fail even on a "stale" update downloaded the same day (not weeks ago).


When you log out to update, you'll see Munki's progress bar over the login screen window, and it will look for a split second as if it's trying to install the pending Apple update but then move on almost immediately to requiring a reboot.

Then, if you check the logs at /Library/Managed Installs/Logs/Install.log, you'll see something like

Apple Software Update install of Security Update 2017-001-10.12.6: FAILED for unknown reason


You could create a script (run from its own Launch Daemon or as part of a Munki run) to clear old updates from the /Library/Updates folder periodically (though, again, I saw this happen even with a recently downloaded update).

I've found that if you run

softwareupdate -d -a
the newly downloaded update will install just fine via Managed Software Center.

This is tricky, because it's not technically a Munki issue (Munki just uses Apple's built-in softwareupdate to install Apple software updates), but clearly there's some flaw in invoking the software update mechanism.

Skipping Apple updates in Managed Software Center manual checks

Why would you want to selectively disable Apple software updates?

Munki allows you to change a preference on client machines to check for and install Apple software updates.

This is pretty cool. It means I can bundle Apple software updates and third-party software updates together for my users.

But sometimes, it's a little frustrating when I'm helping a user to use Managed Software Center, and MSC checks for new updates but also decides to check for Apple updates... don't really need it to check for Apple updates then. Totally want Munki to check for Apple updates in the background and all the other times, just not when the user launches up MSC.

It's true if you've just checked very recently. you may see Skipping Apple Software update because sucatalog is unchanged, installed Apple packages are unchanged and we recently did a full check, but even if it's been a while since the last check, I just don't want any check happening if the user has manually launched up MSC.

Use a Preflight script

Munki allows you to run preflight and postflight scripts during each Munki run. As Munki is out of the box, you are supposed to have one preflight script named preflight (no extension). If you use MunkiReport, though, as I do, you'll notice MunkiReport has the preflight script run a bunch of scripts in the preflight.d directory, which allows a bit more flexibility to add in various scripts instead of lumping them into one combined preflight script.

Script logic

Preflight scripts can use the runtype to do different things based on whether the Munki run type is an auto, logoutinstall, checkandinstallatstartup, installwithnologout, manualcheck, or custom.

What the script does is just check to see if there's a manualcheck and then turn the InstallAppleSoftwareUpdates preference off. If it's any other type of run, the script turns the preference on.

The actual preflight script

Here is the preflight script, which you can deliver as a payload to /usr/local/munki/preflight.d/ (or as /usr/local/munki/preflight if you don't have a preflight directory). You can create the .pkg using Packages, The Luggage, munkipkg, or even just pkgbuild.

If you want to make it based on another runtype you can change the logic there or tweak the script to use a time-based or date-based logic to run Apple updates less frequently. The possibilities are endless!