Big Sur Upgrade Bash Command

@mwu1876 Did you make it work on M1 Mac, or Intel Mac? For me it works for Intel Macs running Big Sur, but fails on M1 Mac.
No matter if I use Files and Processes command or Script. Same error: failed to authorize for installation. Provide a password with --stdinpass or --passprompt.
Jamf support has no clue...

@Strannik Did you ensure the Install macOS Big Sur.app installer you have is compatible with M1 Macs?

@MLBZ521 The installer is fine. I can reinstall Big Sur from Terminal by entering admin password.
Apparently Apple now requires authentication to use startosinstall command on Apple Silicon Macs.
I can't find a way to pass admin credentials to startosinstall using --stdinpass flag in order to be able to use in Jamf policy.
Automation is broken for now. Jamf support suggested me to contact Apple to figure it out...

Wouldn't be surprised. Apple does not understand enterprise needs.

Hi all,

Just a check-in with my issue. My previous comment was I could not perform Erase then reinstall macOS Big Sur.
sudo "/Applications/Install macOS Big Sur.app/Contents/Resources/startosinstall" --agreetolicense --nointeraction --forcequitapps --eraseinstall --newvolumename 'Macintosh HD'

AppleCare had responded to my question, and they can confirm if run under a non-admin account, this command line also broke for them. If run under a non-admin account, it will also ask "osinstallersetupd wants to make changes", which requires admin credentials.

Based on AppleCare response to me, I have added

sudo dseditgroup -o edit -a $3 -t user admin 
sudo "/Applications/Install macOS Big Sur.app/Contents/Resources/startosinstall" --agreetolicense --nointeraction --forcequitapps --eraseinstall --newvolumename 'Macintosh HD'
sudo dseditgroup -o edit -d $3 -t user admin

to grant adim rights before executing the startosinstall.

If the startosinstall succeeds or fails, the last line will remove the admin rights so the user is back to standard account.
Another stupid workaround, but it will do me :)

But running that command from Self Service should execute the code as root

I find all of this troubling. While many of us will get this working without a hitch, I really feel that Jamf needs to create this process for us rather than giving us just a pile of lego's for us to figure out the build. This is some basic stuff that any MDM should be doing. I suspect a policy with the package for the installer and then a check box to reinstall, wipe and install and so forth. Just frustrated by the lack of internal support for this stuff.

Thanks to all for the good info.

I can confirm startosinstall will work on an M1 machine from terminal with the --user and --passprompt switches.

--user "adminuser" --passprompt

Full command line:
startosinstall --agreetolicense --eraseinstall --newvolumename "name" --forcequitapps --user "adminuser" --promptpass
Made me type A to agree to license and prompted for password.

Did not try with the --nointeraction switch added. Did not try without --forcequitapps --stdinpass failed for me

I have not tried running this from a policy. From the posts above it seems like the issue is getting the password to pass in a policy. I am guessing they intended -stdinpass for this so many things ahead to try and test.

I would be interested to hear more about any positive results running this from a policy.

@bzuckrow That was my experience too. I can erase and reinstall Big Sur on M1 Mac in Terminal by entering admin password when prompted, but can't find a way to automate it for Self Service policy.
I have more in this thread https://www.jamf.com/jamf-nation/discussions/37479/eraseinstall-for-macos-big-sur

@mconners There are too many ways that people would want to do this for Jamf to try and do. Jamf can only do what Apple allows/provides for them to do. Besides, this is Apple's problem. Apple can't make a universal way to perform the same actions on two different machines. They also apparently feel that administrative workflows should not be silent or scriptable and that running actions "as root" is nefarious and shouldn't be done.

Thank you @MLBZ521 I don't disagree at all. Just incredibly frustrating.

Is the general consent that --user SomeAdmin --stdinpass SomePassword does not work on M1 Macs but --passprompt does if the command is run from Terminal?

If so, is there a way to open Terminal from a policy so that the logged in user can see the password prompt?

for that using methods like:

/Applications/Install macOS Big Sur.app/Contents/Resources/startosinstall --agreetolicense --forcequitapps --nointeraction

are you deploying the Lite (stub) installer or the full 12GB file?

it appears deploying the lite installer with startosinstall does pull down the additional components for erase and install..but curious about the upgrade portions.

thanks!

@DirkM Command running in script fails because the script runs as root.

echo “adminpass” | “/Applications/Install macOS Big Sur.app/Contents/Resources/startosinstall” --user admin --stdinpass --agreetolicense --nointeraction --forcequitapps --eraseinstall --newvolumename “Macintosh HD”
Error: Could not find provided owner on this system.

Solution for me was to run command as user:

/usr/bin/su -l admin -c "echo adminpass | /Applications/Install macOS Big Sur.app/Contents/Resources/startosinstall --eraseinstall --newvolumename 'Macintosh HD' --nointeraction --agreetolicense --forcequitapps  --user admin --stdinpass"

That worked on M1 MB Air to reinstall Big Sur in Self Service.
However, using admin password inside a script is a bad idea, so it would be good to encrypt it as shown here:
https://github.com/jamf/Encrypted-Script-Parameters

I managed to write a script that prompts the logged in (admin) user for his or her password and then use the echo ... | startosinstall ... --stdinpass to kick of the eraseinstall. We do have a localadmin user with secure token and stored password in Jamf Pro. So the next step is to write a script that gets the localadmin password from Jamf Pro and then echo that to the eraseinstall command.

However, using admin password inside a script is a bad idea, so it would be good to encrypt it as shown here: https://github.com/jamf/Encrypted-Script-Parameters

People need to stop advising this, since the "encrypted" password and all info needed to decrypt is then in plain text on the machine anyway...

Hi all,

I received some statements from AppleCare:

"There are two authorization types required for installing macOS Big Sur. One is required for all Macs, and the other only for Apple Silicon. The first authorization type is the one required to install software. Running the OSInstaller requires admin privileges, and that is true for all Macs. So, when running startosinstaller in a standard user context, it does require a password entry to elevate privileges and the standard user is prompted with the dialog in the screenshot - osinstallersetupd wants to make changes. We understand that customer is using Jamf Self Service with script — and therefore startosinstall — was running in root context and being executed by theJamfagent user. When executed in a root context, there is no prompt for the standard user to authenticate. So, regarding this questions about scoping the Jamf Self Service policy, customer will need to direct those to Jamf support instead. The second authorization type corresponds to the new arguments added to startosinstall usage in macOS Big Sur (--user, --prompt, and --stdinpass), and is only applicable to Apple Silicon. Since customer is using Intel Macs in this report, the new authorization type and its corresponding arguments are not applicable. So, to summarize: For Intel Macs, startosinstall requires admin authorization to run and will prompt for credentials if executed in a standard user context. To avoid that, run startosinstall in a root context (e.g. with sudo). This behavior is the same as macOS Catalina installation on Intel Macs. For Apple Silicon, in addition to the admin authorization required to install software described above, startosinstall can use the --user argument with either --prompt or --stdinpass to stash credentials for the second authorization requirement needed to complete installation."

Hope this helps some of your queries.

@Dirkm I tried this using your command but get "Requested user is not a administrator. Allow the user to administer this computer in System Preferences to continue." when the user is an admin.

hi all, i get same error:

By using the agreetolicense option, you are agreeing that you have run this tool with the license only option and have read and agreed to the terms.
If you do not agree, press CTRL-C and cancel this process immediately.
Requested user is not a administrator. Allow the user to administer this computer in System Preferences to continue.

but the user is already administrator

Upgrading to Big Sur 11.2 (via full package) and noticed that the installer takes about 50 minutes to "Prepare" before it would start to preform the upgrade itself (50 min 'prepare' + 50 min 'upgrade')

I still use "/Applications/Install macOS Big Sur.app/Contents/Resources/startosinstall --agreetolicense --forcequitapps --nointeraction" (without the quotes) with no other issues other then "Preparing"

I package the "Install macOS Big Sur.app" with Composer and saved as a dmg.

Any ideas?

@Bernard.Huang just to understand, would this mean that passing the username and password of an admin on the local computer is necessary for all Apple Silicon OS updates?

For Apple Silicon, in addition to the admin authorization required to install software described above, startosinstall can use the --user argument with either --prompt or --stdinpass to stash credentials for the second authorization requirement needed to complete installation.

I had been ripping my hair out trying to get this to work. I think I found the combination that does now.

I removed the pop-up interaction from the policy to inform users what they're getting into (Guess they'll have to read the email).

The policy runs a script with this line:

sudo '/Applications/Install macOS Big Sur.app/Contents/Resources/startosinstall' --agreetolicense --forcequitapps

For whatever reason, removing --nointeraction worked. It took about a minute or so for the policy to run in self service, but it finally did.

NOTE: Also, do NOT copy paste the line into Jamf. I had to type it all out. Jamf doesn't seem to like removing metadata from copied text.

Remember that policies run as root, so sudo is unnecessary unless you're trying to run a command as a specific user.

Is this working as a workflow? I dont see a conclusive answer. Looking at Catalina > Big Sur Intel erase and installs

@djdavetrouble /Applications/Install macOS Big Sur.app/Contents/Resources/startosinstall --agreetolicense --forcequitapps --nointeraction --eraseinstall