Big Sur Upgrade Bash Command

[sgiesbrecht]

Does anyone know the correct Bash command to upgrade to Big Sur? I tried using "/Applications/Install macOS Big Sur.app/Contents/Resources/startosinstall --agreetolicense --forcequitapps --nointeraction" but it just hangs.

[MLBZ521]

Yeah, I mentioned --applicationpath was deprecated back on the 14th.

That said, it was still required to use when running the startosinstall from Recovery.

[Bernard_Huang]

I waited a log time for the Installation to start.
After 30 minutes, I quit the process, and check the install.log.
I can see

<Macbook serial number> osinstallersetupplaind[2041]: Wrong process invoked.
<Macbook serial number> osinstallersetupplaind[2042]: Wrong process invoked.
etc

Log entry happens every 10 seconds.
My usually script
"/Applications/Install macOS Big Sur.app/Contents/Resources/startosinstall" --agreetolicense --forcequitapps --eraseinstall --newvolumename 'Macintosh HD'"
is really not liking this.

[Cayde-6]

If you are adding this to a script to stage the verify bit. How can you tell when its completed or worked even with terminal?
${bigSurInstaller}/Contents/Resources/startosinstall --usage &>/dev/null

[Bernard_Huang]

Thanks @Cayde-6 ,

Still, only your solution of starting and quitting out of Install macOS Big Sur.app worked for me.

So now, my working code is:

open -a "/Applications/Install macOS Big Sur.app"
/bin/sleep 120
osascript -e 'quit app "/Applications/Install macOS Big Sur.app"'
/bin/sleep 3

'"/Applications/Install macOS Big Sur.app/Contents/Resources/startosinstall" --agreetolicense --forcequitapps --nointeraction  --applicationpath "/Applications/Install macOS Big Sur.app" >> /var/log/startosinstall.log

The first wait (sleep 120) is 120 seconds because starting Install macOS Big Sur.app for the first time really does take around 2 minutes.
This still seems silly to me why I need this section at all.
If any other people can come up with a more elegant way to kick off the Install macOS Big Sur, I would love to hear it and test it :)

[CDAdmin]

@dan-snelson i tried using that script as i used it previously for catalina and it doesn't seem to work as expected. it will get to the point where it prompts the user that a reboot will occur, but the reboot actually occurs about 24 hours later. Not sure what else needs to be changed, but it shouldn't take that long.

[Bernard_Huang]

Hi all,

I've coming up to another error. This time the test case is to Erase existing macOS first, then perform macOS Big Sur installation from scratch. Practical use of this is:

if an end-user finds something is wrong, willing to refresh his/her Macbook.

if the Macbook is to be wiped out of all existing data, ready for the next user to be handed this Macbook to.

The command line I am attempting is this

'"/Applications/Install macOS Big Sur.app/Contents/Resources/startosinstall" --agreetolicense --nointeraction --forcequitapps --eraseinstall --newvolumename 'Macintosh HD''

On the Macbook itself, when triggering this command line off, it pop up with a notification:
"osinstallersetupd wants to make changes"
It is also asking for admin cridentials, which end-users do not have.

From JAMF log, the error message is:

Error: Error: Could not create a new APFS volume. Please try again.
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.

Anyone got any ideas how to make Erase then Install macOS Big Sur work?
This is the exact command line I used for macOS Catalina, and it works fine then. Again not sure what has changed between Big Sur & Catalina.

Edited: I am trying to wipe out macOS Big Sur, then reinstall macOS Big Sur, btw.
Maybe Big Sur treats APFS differently.

[Bernard_Huang]

Extra note on my failed Erase then reinstall macOS Big Sur,

If I run this command line within terminal, it works fine.

sudo "/Applications/Install macOS Big Sur.app/Contents/Resources/startosinstall" --agreetolicense --nointeraction --forcequitapps --eraseinstall --newvolumename 'Macintosh HD'

One thing I notice is I have to create a admin account, then run the command so I can type in a password to execute this.
If I was to run it as a normal user account (without admin rights), it still wouldn't start because it is waiting for admin password.

I have tried it via JAMF policy > Files & Processes > Execute Command, so I am trying this command line a simple as possible.
All fail as it ask for admin password before it can execute :(

[mwu1876]

When I run this command I get a strange result. The upgrade worked fine but when it restarts, the username "System Administrator" is automatically populated. I can just changed it and use a local user and it works fine. But strange. If I do a manual upgrade from the App Store that System Administrator user does not come up. Anyone seen this?

[jmackbnd]

Trying to use this method to allow our Standard users to do an in-place upgrade to Big Sur via Self Service. I've got it almost all the way working by leveraging the command below in the Scripts section:

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

The Mac will restart and begin the upgrade almost immediately, but only after I quit Self Service manually. Otherwise Self Service just displays "running" indefinitely and the policy never completes. The --forcequitapps flag doesn't seem to do the trick to close Self Service. Does anyone have any feedback on how I might force Self Service to quit or any other suggestions on how I might approach this?

[Bernard_Huang]

HI @jmackbnd When you were running this via Self Service, was the Big Sur policy opened in the description page? (as in you are seeing the Big Sur policy only, no other policy icons?) At first few tries, I also experienced not able to close Self Service, but then I realise the Policy description view needs to be close before it can quit properly. But then again, the --forcequitapps should have closed Self Service, so this is very weird.

Hi @mwu1876 , Haven't experienced once where it ask for admin rights after it had successfully upgraded. Maybe try a different Macbook to test on. Perhaps there's a start up policy that is triggering off for this particular Macbook.

So far I have tested:
- Upgrade from Mojave to Big Sur - Success
- Upgrade from Catalina to Big Sur - Success
- Reinstall from Big Sur to Big Sur - Fail. Ask for admin rights before starting. The results never seem consistent. Does anyone thing JAMF Pro needs upgrading? We are currently running 10.25.2, haven't upgraded to10.26 yet.

[jmackbnd]

@Bernard.Huang - Thanks so much for that! That was indeed the issue. When I ran the command in Self Service from the main Self Service window rather than with the Description overlay open, it worked! In my testing, the target Mac takes anywhere from 3-10 minutes to restart and begin the upgrade, but it always eventually does.

Also, in chatting back and forth with Jamf support I switched the policy back over to using Files & Processes instead of Scripts and added a bit to the end of the command to encourage Self Service to close. Here's what finally ended up working for me:

/Applications/Install macOS Big Sur.app/Contents/Resources/startosinstall --agreetolicense --forcequitapps --nointeraction && sleep 10 && osascript -e 'tell application "Self Service" to quit'

Hope this is helpful to someone else out there!

[Strannik]

@mwu1876, @Bernard.Huang
I've got similar issue - policy to erase and install Big Sur works fine on Catalina, but fails on M1 MacBook running Big Sur.
"Running command '/Applications/Install macOS Big Sur.app/Contents/Resources/startosinstall' --eraseinstall --agreetolicense --forcequitapps --newvolumename 'Macintosh HD'
Result of command:
Error: failed to authorize for installation. Provide a password with --stdinpass or --passprompt."
If I add flag --stdinpass the policy gets stuck at "Running" and nothing happens. Can't see any errors in Install and Jamf logs on the computer.
Running policy from Self Service.
Any suggestions?

[mwu1876]

I ended up getting this to work if I out the same command into a script, without the stdinpass.

[Strannik]

@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...

[MLBZ521]

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

[Strannik]

@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...

[MLBZ521]

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

[Bernard_Huang]

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 :)

[Cayde-6]

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

[mconners]

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.

[bzuckrow]

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.

[Strannik]

@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

[MLBZ521]

@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.

[mconners]

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

[DirkM2012]

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?

[walt]

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!

[Strannik]

@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

[DirkM2012]

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.

[barnesaw]

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...

[Bernard_Huang]

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.

[mmcchesney]

@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.

[faizal_kamarudd]

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

[sgiesbrecht]

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?

[cradice]

@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.

[mburchett-zymer]

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.

[aaronedmonton]

This is the only command that worked for me! Thanks!

[pete_c]

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

[djdavetrouble]

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

[sgiesbrecht]

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

[efil4xiN]

@sgiesbrecht posted command worked perfect for me.