Mac admin'ing

Fix for VirtualBox Extension Pack postinstall script hanging in Munki

The problem

If you’ve been running the VirtualBoxExtPack.munki.recipe AutoPkg recipe, and you’ve noticed the VirtualBox Extension Pack postinstall script in Munki hanging indefinitely (30 minutes and beyond), it’s because the license hash has changed.

The fix

According to @jessepeterson (the maintainer of that AutoPkg recipe), the license hash doesn’t change very often, but it did change, and @lctrkid made a pull request (now merged in) on that recipe repo to put in the new license hash, so you may have to run a autopkg repo-update jessepeterson-recipes and then possibly re-create the recipe override or manually add the license part of the override.

Some background

The license hash is something you can find by manually running a command like this (with the actual extension pack in your Downloads folder, of course): sudo /usr/local/bin/VBoxManage extpack install --replace ~/Downloads/Oracle_VM_VirtualBox_Extension_Pack-6.1.14.vbox-extpack. It will display the whole license, and then prompt you to accept the terms: Do you agree to these license terms and conditions (y/n)? y

Once you’ve accepted, you will then see the hash:

License accepted. For batch installation add
to the VBoxManage command line.

Successfully installed "Oracle VM VirtualBox Extension Pack".


Special thanks to @lctrkid and @jessepeterson on the MacAdmins Slack for helping understand what’s going on.

Mac admin'ing

AutoPkg failed: hdiutil: attach failed – no mountable file systems error

If, when running AutoPkg, you get an error like

failed: hdiutil: attach failed - no mountable file systems

but you’re able to mount the .dmg manually (i.e., it’s not a corrupted download), double-check you don’t have a restrictions profile installed that requires you to authenticate when mounting disk images. That setting is pretty much useless anyway if you’re an admin user (you won’t be prompted in the GUI to authenticate when mounting disk images via Finder), and it will just make it so when AutoPkg is trying to run

/usr/bin/hdiutil attach -plist -mountrandom /private/tmp -nobrowse /PATH/TO/DOWNLOADED/DISKIMAGENAME.dmg

that it will choke with that error.

(Oddly enough, if you just do hdiutil attach without all those other options, it will still work just fine.)

Special shoutout to @elios on the MacAdmins Slack for helping another user figure this out three years ago, and so that’s how I was able to solve my problem.

Mac admin'ing

If you update an AutoPkg parent recipe, but your override is still using old settings…

AutoPkg has a cool feature called parent trust that allows you to create recipe overrides that store a hash of the parent recipe (instead of running the parent recipe directly), and then prevent you from running the recipe if there’s a change to the parent recipe, until you update the trust info. (I also have a script that runs a list of recipes, checks trust info, and prompts you to approve changes if there are changes.)

But you may sometimes run into a situation in which you see the changes, the changes are important (for example, the download URL has changed to a new URL), but even after you accept the changes and update the trust info in your override recipe, the recipe still keeps using the old URL.

Here’s an example: AndroidStudio SEARCH_PATTERN error.

So if you make an override for AndroidStudio: autopkg make-override AndroidStudio.munki, you should see something like this:

Those input variables are copied over from the parent recipe. But then if the parent recipe updates SEARCH_URL to be a different URL, your override will still have the old value for SEARCH_URL.

So if you see a change to a parent recipe, and your override still seems to be using the old values, check your override for input variables, and delete the ones you don't want to override.

Mac admin'ing

Using AutoPkg to distribute and test Munki 4 (or any new Munki version) in prerelease

10 December, 2019 update: Munki 4 is now an official (not pre-) release, so the below instructions are for when the next version is in prerelease…

25 November, 2019 (original post)
As of this writing, Munki 4 is in the late stages of testing (its current on release candidate 1), so if you want to be part of the testing process and distribute it to part of your fleet, you want to start by first importing it into your Munki repo.

There is a new AutoPkg recipe for this called munkitools4.munki.recipe

First, make the override for it:

autopkg make-override munkitools4.munki

Then, edit the override, so it includes prereleases by adding in the appropriate true to the override’s XML:


Then, run it as you normally would, just to verify it works (before including it in your scheduled runs):

autopkg run -v munkitools4.munki MakeCatalogs.munki