When you want to provide automated workflows to upgrade to or erase-install macOS Big Sur, you can use the
startosinstall tool. You can find this tool inside the “Install macOS Big Sur” application at:
/Applications/Install macOS Big Sur.app/Contents/Resources/startosinstall
Note: Apple calls the “Install macOS *” application “InstallAssistant.” I find this a useful shorthand and will use it.
Before you can use
startosinstall, you need to somehow deploy the InstallAssitant on the client system. And since the “Install macOS Big Sur” application is huge (>12GB) it poses its own set of challenges.
Different management systems have different means of deploying software. If you are using Munki (or one of the management systems that has integrated Munki, like SimpleMDM or Workspace One) you can wrap the application in a dmg. Unfortunately, even though “app in a dmg” has been a means of distributing software on macOS for nearly 20 years, most management systems cannot deal with this and expect an installer package (pkg).
You can use
pkgbuild to build an installer package from an application, like this:
pkgbuild --component "/Applications/Install macOS Catalina.app" InstallCatalina-10.15.7.pkg
This works for all InstallAssistants up to and including Catalina. With a Big Sur installer application this command will start working, but then fail:
% pkgbuild --component "/Applications/Install macOS Big Sur.app/" InstallBigSur20B29.pkg pkgbuild: Adding component at /Applications/Install macOS Big Sur.app/ pkgbuild: Inferred install-location of /Applications pkgbuild: error: Cannot write package to "InstallBigSur20B29.pkg". (The operation couldn’t be completed. File too large)
The reason for this failure is that the Big Sur installer application contains a single file
Contents/SharedSupport/SharedSupport.dmg which is larger than 8GB. While a pkg file can be larger than 8GB, there are limitations in the installer package format which preclude individual files in the pkg payload to be larger than that.
When you want to distribute the “Install macOS Big Sur” application to the clients in your fleet, either to upgrade or for an erase-and-install workflow, this limitation introduces some challenges.
You can use Composer with Jamf to create a Jamf dmg style deployment, but that will only work with Jamf Pro. You could further wrap and split the application in different containers, but that will increase the creation and deployment time.
There are a number of solutions. Each with their own advantages and downsides, some supported and recommended by Apple and some… less so. Different management and deployment styles will require different solutions and approaches.
App Deployment with MDM/VPP
When you have your MDM hooked up to Apple Business Manager or Apple School Manager, you can push applications “purchased” in the “Apps and Books” area with MDM commands. This was formerly known as “VPP” (Volume Purchase Program and I will continue to use that name, because “deploy with Apps and Books from Apple Business Manager or Apple School Manager” is just unwieldly and I don’t care what Apple Marketing wants us to call it.
Since the “Install macOS Big Sur” application is available for free on the Mac App Store, you can use VPP to push it to a client from your MDM/management system.
When you do this, the client will not get the full InstallAssistant application, but a ‘stub’ InstallAssistant. This stub is small in size (20-40MB).
The additional resouces required for the actual system upgrade or installation which are GigaBytes worth of data will be loaded when they are needed. It doesn’t matter whether the process is triggered by the user after opeing the application or by using the
createinstallmedia tool. Either workflow will trigger the download of the additional resources.
This has the advantage of being a fast initial installation of the InstallAssistant, but then the actual upgrade or re-installation process will take so much longer, because of the large extra download before the actual installation can even begin. For certain deployment workflows, this is an acceptable or maybe even desireable trade-off.
The extra download will use a Caching Server. This approach is recommended and supported by Apple.
Mac App Store and/or System Preferences
For some user-driven deployment styles, having the user download the InstallAssistant themselves can be part of the workflow. This way, the user can control the timing of the large download and make sure they are on a “good” network and the download will not interfere with video conferences or other work.
You can direct then to the Big Sur entry in the Mac App Store with a link. You cannot search for older versions of macOS Installers in the Mac App Store, but Apple has a kbase article with direct links.
You can also use a link that leads a user directly to the Software Update pane in System Preferences and prompts the user to start the download:
# Big Sur x-apple.systempreferences:com.apple.preferences.softwareupdate?client=bau&installMajorOSBundle=com.apple.InstallAssistant.macOSBigSur # Catalina x-apple.systempreferences:com.apple.preferences.softwareupdate?client=bau&installMajorOSBundle=com.apple.InstallAssistant.Catalina
When the InstallAssistant is already installed, this link will open the application. When the Mac is already running a newer version of macOS or doesn’t support the version given, it will display an error.
You can use these links from a script with the
The downloads initiated this way will use a Caching Server. Linking to the Mac App Store is supported and recommended by Apple. The
x-apple.systempreferences links are undocumented.
Catalina introduced the
--fetch-full-installer option for the
softwareupdate command. You can add the
--full-installer-version option to get a specific version of the installer, for example
You can run this command from a managed script on the clients to install the application. The download will use a Caching Server.
This would be a really useful method to automate deployment the InstallAssistant on a client, if it were reliable. However, in my experience and that of many MacAdmins, this command is very fragile and will fail in many circumstances. As of this writing, I have not been able to reliably download a Big Sur InstallAssistant with this command. Most of the time I get
Install failed with error: Update not found
This approach is often recommended by Apple employees, however it will have to be much more reliable before I will join their recommendation.
Please, use Feedback Assistant, preferably with an AppleSeed for IT account, to communicate your experience with this tool with Apple. If this command were reliable, then it would be my recommended solution for nearly all kinds of deployments.
With these solutions so far, we have actually avoided creating an installer package, because we moved the download of the InstallAssistant to the client. A caching server can help with the network load. Nevertheless for some styles of deployments, like schools and universities, using the local management infrastucture (like repositories or distribution points) has great advantages. For this, we need a package installer for the InstallAssistant.
A “magic” download link has been shared frequently in the MacAdmins Slack that downloads an installation package from an Apple URL which installs the Big Sur InstallAssistant.
This pkg from Apple avoids the file size limit for the package payload by not having the big file in the payload and then moving it in the postinstall script. Smart hack.. er… solution!
The URL is a download link from a software update catalog. You can easily find the link for the current version with the SUS Inspector tool.
But it would be really tedious to do this on every update. You, the regular reader, know the “tedious” is a trigger word for me to write a script. In this case it was less writing a script than looting one. Greg Neagle’s
installinstallmacos.py had most of the pieces needed to find the
InstallAssistant.pkg in the software update catalog and download it. I merely had to put the pieces together somewhat differently.
Nevertheless, I “made” a script that downloads the latest InstallAssistant.pkg for macOS Big Sur. You can then upload this pkg to your management system and distribute it like any other installation package.
- GitHub: scriptingosx/fetch-installer-pkg
It works very much like
When you start the script it will download a lot of data into a
content folder in the current working directory, parse through it and determine the Big Sur Installers in the catalog. When it finds more than one installers, it will list them and you can choose one. When it finds only one Installer, it will start downloading that immediately.
You can add the
--help option for some extra options (all inherited from
We will have to wait for the 11.1 release to be sure this actually works as expected, but I am confident we can make it work.
This approach is very likely not supported by Apple. But neither was re-packaging the InstallAssitant from disk in Catalina. This deployment method is likely closer to the supported deployment workflows than some common existing methods.
The download does not use a Caching Server, but since the goal is to obtain a pkg that you can upload to your management server, this is not a big downside.
Big Sur signature verification check
You may have noticed that when you launch the Big Sur InstallAssistant on Big Sur for the first time, it will take a long time to “think” before it actually launches. This is due to a new security feature in Big Sur that verifies the application signature and integrity on first launch. Since this is a “big” application this check takes a while. Unfortunately Big Sur shows no progress bar or other indication. This check occurs when the user double-clicks the app to open it and when you start an upgrade or installation with the
There does not seem to be a way to skip or bypass this check. You can run
startosinstall --usage from a script right after installing the InstallAssistant. This will do nothing really, but force the check to happen. Subsequent launches, either from Finder or with
startosinstall will be immediate.
8 thoughts on “Deploying the Big Sur Installer Application”
Thank you so much for this, it taught me how to use pkgbuild lol! Can’t believe no one has told me about this before, super useful, thank you!!!
There’s so much more to `pkgbuild`. I wrote an entire book about it!
Is there an easy way to make a Booteable USB drive in order to install Big Sur?
Apple Support: How to create a bootable installer: https://support.apple.com/en-us/HT201372
Why not just run the fetch-installer-pkg.py on every client machine via your management server and install the app into the Applications folder instead of using a management server to distribute the packaged app?
Either way it is likely coming from the internet to the machine. Everyone and their mother are working from home, so even if you have local caching servers in the office, they are useless. I’d just go direct with the script on every machine. Shortest path to getting the app to client machines.
Some people still manage on-site Macs that would reach out to Apple’s servers to download 12+ GB and swamp the uplink.
But when you have a distributed, mobile fleet to manage, your approach certainly makes sense. My tool intentionally downloads the pkg installer, so you would need an extra step to actually install the Installer app, before you can use. Greg’s original script does this already, so it would be more appropriate for your approach. Since I wrote this, Apple has fixed a few bugs with the
softwareupdate --fetch-full-installercould work as well.
This is the best article I’ve yet seen on attempting to easily deploy Big Sur to a fleet. Thank you! I have a related question; do you know of a way to automatically initiate unattended Big Sur updates on M1 machines? Older methods no longer work on Big Sur, and require a user to manually enter the username and password on each computer before the update will install. i.e. I can still send ‘softwareupdate -i -a –restart’ to Intel machines and Big Sur will download and install the latest updates to Big Sur without issue. M1 machines will prompt our (non-admin students) to enter admin credentials, which they can’t do. I’ve found no work-around at this point outside of there maybe being a solution if we enroll the M1s in Apple’s DEP, which we prefer not to do. Really scratching my head over this one.
Thanks. Regarding unattended updates and installations on M1 Macs. That is an intentional change by Apple. Monterey will allow MDM initiated updates that don’t require user auth. On Big Sur, you can use the
startosinstallcommand and provide it with a known admin/volume owner password to suppress the user auth. I would recommend joining the MacAdmin Slack and asking about this in the #applesilicon or #bigsur channels.
Comments are closed.