Mac Admin

Performing an Erase and Install of Mojave with jamJAR

Hi All.

So I’ve been a little quiet on the blogging recently. Between starting a new job and jumping two feet in, it’s been a bit of a hectic few months!

I was recently asked by my new boss (Ben, aka Mac Mule) to look into building a workflow with jamJAR to erase and install a copy of Mojave with minimal interactions. This would allow someone to deploy a ‘clean reinstall’ policy without having to use NetBoot, or the Recovery Partition.

Without further ado, let’s get to it.

Time Sensitive Information

For possible historic reason, please find the versioning of various aspects below.

  • Date: October 2018
  • Jamf: 10.7.1
  • Munki:
  • macOS: 10.14.0

The Requirements

So the requirement was to utilise the newer feature of the ‘Install macOS Application’ (added in the ‘Install macOS High Sierra Application’ version 10.13.4) to perform an erase  and install from the command line, via the --eraseinstall option.

As discussed in a few videos and conferences, we at dataJAR utilise a mixture of Jamf Pro and Munki for software deployments / patching, called jamJAR, therefore the aim would be to use this to achieve our goal.

In case you haven’t heard of it, jamJAR leverages Jamf to write out the contents of local-only manifests for Munki which then performs most software installations and patching. This leans on the strengths of both products to provide the best solution.

Technical Requirements

To utilise this new option, there are two main requirements from a technical perspective:

1) The volume we will be targeting must be running APFS.

  • For devices running High Sierra, if they are using an SSD / Flash storage, they’ll have been converted to APFS automatically, by default.
  • For devices running Mojave, they’ll have all been converted to APFS automatically, by default.

2) You will need to use an “Install macOS High Sierra” Application that installs High Sierra 10.13.4 or newer, or Mojave.

  • For this, I have only tested the Mojave 10.14.0 process, but I don’t see why this wouldn’t work for 10.13.4+, just test in your own environment!

3) Ideal (but not required!) you’d have the device in DEP, assigned to your management solution of choice, therefore giving you an almost ‘Imaging’ workflow.


Now as we use jamJAR, we’ll be using Jamf Pro for scoping. In our work here we purely scoped the relevant jamJAR  policy (in this case, “Add to installs” “ERASEAndInstallmacOSMojave”) to devices with an OS  “like” “10.14.”

You should set this up as required for your own environment. Perhaps you add devices to the policy manually? Perhaps you put the policy in Self Service and behind a login barrier?

For our usage, we also set the policy up as Self Service only (no triggers). This meant we could control the testing and deployment.

Forced Logout

Lastly, as we have the Munki install configured as requiring a logout, it won’t trigger automatically until someone logs out. To get around this, we added a ‘logout’ action into the same Jamf policy that will force a logout once the Munki install is cached and good to go.

How’s it look?

A little something like this, complete with some dataJAR Munki rebrand work (More info):

Please Note: This has been sped up over the slower screens. Total time from clicking ‘Go’ to rebooted back to the setup assistant is around 40 minutes. This included download time!

So what do I need to do?

So in order to get this working as intended, I had to add two keys to the pkgsinfo ?file (ERASEAndInstallmacOSMojave.plist): additional_startosinstall_options and installcheck_script:


Of the two keys to add, this is the newest and the one with (arguably) the least amount of testing and documentation of all possible options. This is mostly due to how new the commands are, and how often they change / are added to.

This key is detailed in the Munki wiki here, but essentially we simply add the erase flag as show here. This is what instructs the startosinstall command to erase the disk first instead of performing an ‘in-place’ install.


This key is used to change the default behaviour of Munki, detailed here. In summary, Munki will not try and install a macOS installer Application workflow if the current device is already running the same major OS version, e.g. If I add a 10.13.6 Install macOS appliance to a manifest, it won’t install on any devices running macOS 10.13.0-10.13.6. This is helpful as it’ll stop devices going through a 1 hour workflow just to update their OS, when a combo update would be better for the job.

Unfortunately, this breaks our usage above, so to get around this, I simply added a installcheck_script that runs an exit 0 which asks Munki to proceed with the install. This is shown here.

Complete pkgsinfo file

To help you get a better understanding of how the pkgsinfo file looks for the above, you can find a copy here.

Please Note: This won’t be a drop in replacement for your own one, but is more to give you an idea.

Considerations if you’re not using jamJAR

So you’re looking to role this out yourself but aren’t using jamJAR? It’s easily possible, with some considerations.

I’m using Munki…

I’m using Jamf Pro…

The folks at Jamf have a White-paper already written up for you, go check it out here.

Other associated links


Phew that was a long one! I’ve detailed how we utilise jamJAR to perform an Erase and Install of macOS Mojave, as well as some considerations if you’re not using jamJAR, but are using Munki or Jamf Pro. As always, if you have any questions, queries or comments, let me know below (or @daz_wallace on Mac Admins Slack) and I’ll try to respond to and delve into as many as I can.

The usual Disclaimer:

While the author has taken care to provide our readers with accurate information, please use your discretion before acting upon information based on the blog post. I will not compensate you in any way whatsoever if you ever happen to suffer a loss/inconvenience/damage because of/while making use of information in this blog.