• support@amsys.co.uk
  • 020 8660 9999

Workflows for installing macOS

[two_third]Apple has recently been making a few changes that make image deployment of operating systems on Macs more challenging. The following message on the Apple website makes the company’s intentions fairly clear.
about monolithic system imaging
We started to investigate alternative ways to erase and install, or upgrade macOS, avoiding traditional solutions like NetBoot and ASR, and using standard Apple installation tools.
In this blog, I’ll explain some of the options we have tested for in-place upgrades and erasing and upgrading the OS on a Mac. The key topics are:

  • In-place upgrades
  • Erase and re-install
  • Erase and upgrade

It’s worth mentioning that each of these scenarios would require either the use of Apple’s Device Enrolment Program (DEP), or for the administrator to perform some manual steps post install.

In-place upgrades

There are two ways you may want to approach in-place upgrades, either with user interaction, or without.

With user interaction

To make an in-place upgrade available to your users to run when it suits them, there’s a few options.
If the users have local admin rights, they can simply download the macOS installer from the app store and run it.
If the users don’t have local admin rights, you can use a device management tool like Munki or Jamf Pro to make the installer available.

Without user interaction

Although a less likely scenario, as the IT administrator you may want to perform an in-place upgrade of macOS. For the past few macOS versions, Apple has included a binary called “startosinstall”. This binary, documented in depth here allows you to trigger the install. With some additional options, the install can be started with no further user interaction:


#!/bin/sh
"/Applications/Install macOS High Sierra.app/Contents/Resources/startosinstall" --applicationpath "/Applications/Install macOS High Sierra.app" --volume / --nointeraction

Script on Github: https://github.com/amsysuk/public_scripts/blob/master/in-placeUpgrade_high_sierra.sh

Erase and install/upgrade

In education environments, and for some businesses, there is a need to erase and cleanly deploy a group of Macs. There are a number of solutions leveraging the Recovery partition and Internet Recovery, depending on your goals.
The three scenarios that I tested were:

  • Erase the Mac and re-install the same operating system
  • Erase the Mac and deploy the OS that it originally shipped with
  • Erase the Mac and upgrade to a newer operating system

Erase the Mac and re-install the same operating system

This can be achieved using the built-in Recovery partition, which will match the currently installed operating system. The high-level steps would be:

  1. Restart the Mac and hold down “Command-R” to boot to the built-in Recovery partition
  2. Once booted, launch Disk Utility and erase the Macintosh HD volume
  3. Proceed with a standard macOS install

Erase the Mac and deploy the OS that it originally shipped with (requires 10.12.4 or higher)

Option-Command-Shift-R
This is a new feature introduced via a firmware update when you upgrade to 10.12.4 or higher. It gives you the ability to reset a Mac to the OS that it originally shipped with, thereby returning it to an original “out of the box” configuration.
iWork and iLife apps – As a side note, performing a factory reset of a Mac doesn’t restore the iWork or iLife apps. These are freely available on the Mac App store, but does mean that the Mac isn’t returned to a true ‘out of the box” state.

Erase the Mac and upgrade to a newer operating system

This last scenario gets a little tricky. If you use the built-in Recovery partition, you’ll get the OS that is already installed on your Mac. If, for example, you are currently running 10.11 and want to erase and install 10.12, you would have to first upgrade the OS to 10.12, then boot to recovery, erase and re-install the OS a second time.
Option-Command-R
Using command-option-R will “Upgrade to the latest macOS that is compatible with your Mac” (https://support.apple.com/en-us/HT204904). But in the fine print it also states that “If you haven’t already installed macOS Sierra 10.12.4 or later, Option-Command-R reinstalls the macOS that came with your Mac, or the version closest to it that is still available.”

Replace the Recovery partition

A lesser known method to ensure the Macs boot to the correct Recovery environment is to alter the Recovery partition. Taking this route lets you control the version of the macOS that is installed.
The high-level steps are:

  1. Deploy the macOS Install app
  2. Download the RecoveryHDUpdate.dmg from Apple
  3. Extract the scripts from the package with pkgutil –expand
  4. Mount the InstallESD.dmg from /path/to/installer.app/Contents/SharedSupport
  5. Run the dmtest binary from the /path/to/expanded package/Scripts/Tools folder, specifying the target drive, the path to the BaseSystem.dmg and the BaseSystem.chunklist files

Here is the script. The only exclusion is the deployment of the macOS installer, that can be achieved using VPP or via your chosen device management system:
Script on Github: https://github.com/amsysuk/public_scripts/blob/master/createRecovery.sh

Other techniques that I tested…

During the testing, there were some things that either didn’t work, felt too far from the Apple intended approach, or were less efficient than the methods described earlier in this article. Below are the main areas:

  • Creating an install partition using createinstallmedia
  • Changing the Recovery partition by copying files

Creating an install partition using createinstallmedia

The intention here is to pre-load the necessary installation files so when you start the macOS installation process, speeding up the overall installation process.
The basic process, which involved resizing the Macintosh HD, creating a new 12GB partition and then running createinstallmedia to build the install partition.
While the process worked, the complication was around the safe partitioning of the disk. There are a number of possible commands that are needed depending on whether CoreStorage is being used, and whether the volume is HFS+ or APFS.
Because of the number of logic steps that would be needed, the difficulty in fully automating the process, and most importantly the high level of risk involved, it seemed that this approach wasn’t worth pursuing.

Changing the Recovery partition by copying files

Early in my testing, I used a 2012 MacBook Pro that originally shipped with macOS 10.9. Inspecting the Recovery partition, the consistent element was a folder called “com.apple.recovery.boot”. Different OS versions seem to include other folders, but after a little trial and error, it seemed that only the com.apple.recovery.boot folder was required.
I could replace this folder with a copy from a newer OS version, and booting to the Recovery partition offered to install the OS I had copied across.
Since 10.11, Apple have started to introduce security features that are designed to protect the OS from user error. Although the manual copying method worked for 10.9 and 10.10, if the Mac has 10.11 or 10.12 installed, attempting to move, copy or delete files from the Recovery partition produced inconsistent errors.
As the most common scenario we are seeing, at least in education establishments is a desire to upgrade from 10.11 to either 10.12 or 10.13, I decided to abandon the manual copying approach.
Below are a few of the URLs that I researched during the course of the testing:

Close
Search

Hit enter to search or ESC to close