--eraseinstall for macOS Big Sur

DBrowning
Valued Contributor

What are people doing to get around the --passprompt or --stdinpass when running the --eraseinstall command with the Big Sur installer?

I have a script available in Self Service for users that want to wipe their machines that works great in Catalina and I was trying to use it for Big Sur as well, but I'm getting an error "Error: failed to authorize for installation. Provide a password with --stdinpass or --passprompt." This happens even when I use sudo or login as root and try the command.

49 REPLIES 49

sdagley
Honored Contributor II

@DBrowning Do you have the --agreetolicense --nointeraction options in your call to startosinstall?

DBrowning
Valued Contributor

I'm using startosinstall --agreetolicense --nointeraction --forcequitapps --eraseinstall --newvolumename "Macintosh HD"

sdagley
Honored Contributor II

What happens if you leave out --newvolumename "Macintosh HD"?

DBrowning
Valued Contributor

So interesting turn of events...I was running this on the new M1 laptop. Just ran it on an Intel MBP and its working......

sdagley
Honored Contributor II

More fun things about dealing with M1 Macs

Chris_Hafner
Valued Contributor II

Hah! You got forked!

ABigRock
New Contributor III

Seeing the same thing on an M1 based MBA.

Strannik
New Contributor III

Apparently on Apple silicon the startosinstall requires authentication by the user.
The policy runs fine on Intel Macs, bit fails on M1 Macs.
Here is the log: “/Applications/Install macOS Big Sur.app/Contents/Resources/startosinstall” --agreetolicense --nointeraction --forcequitapps --eraseinstall --newvolumename “Macintosh HD”...
Result of command:
Error: failed to authorize for installation. Provide a password with --stdinpass or --passprompt.

Attempt to pipe admin password into startosintall command fails with another error: 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…

If I only adding --stdinpass flag without piping the password - the policy hangs at “Running”.

When I enter the password right after --stdinpass flag I’ve got yet another error:
“/Applications/Install macOS Big Sur.app/Contents/Resources/startosinstall” --user admin --stdinpass “adminpass” --agreetolicense --nointeraction --forcequitapps --eraseinstall --newvolumename “Macintosh HD”...
Result of command:
startosinstall: An extraneous argument was specified with option ‘stdinpass’

I hope someone with access to developer documentation can figure out how to use properly the new flags in startosinstall command.
New flags like --stdinpass, --cloneuser or --reducedsecurity are available on M1 Macs.
startosinstall --usage in Terminal shows only this: --user, an admin user to authorize installation.
--passprompt, collect a password for authorization with an interactive prompt.
--stdinpass, collect a password from stdin without interaction.
--reducedsecurity, configure target volume's security policy as Reduced Security (will prompt for authorization after reboot).
--cloneuser, Copy account settings for the owner provided with --user when installing to a new volume.

DBrowning
Valued Contributor

@Strannik

If I only adding --stdinpass flag without piping the password - the policy hangs at “Running”.

while it was sitting at the blank line, i decided to type in my password. Grant it was in plain text, the process started.
0b1fb2c6689346d9ba915ff8d2fcc65a

Strannik
New Contributor III

@DBrowning Yes, you can do it in Terminal while running command as admin user, but the question is - how to do it in Self Service, when script runs as a root and better yet - automate it...

DBrowning
Valued Contributor

@Strannik Yeah..... I'm trying to see if i can figure something out using expect. Not working so well right now....

bizzaredm
New Contributor III

@Strannik Does trying --user admin --stdinpass, where "admin" is "root" instead do anything? I am about to take a look at this myself

Edit: Please see my below responses

HCSTech
Contributor
Contributor

Does this work? echo “YOURPASSWORDHERE” | sudo /Applications/Install macOS Big Sur.app/Contents/Resources/startosinstall --agreetolicense --eraseinstall --user "YOURADMINHERE" --stdinpass

bizzaredm
New Contributor III

@HCSTech

Manually in Terminal

echo 'YOURPASSWORDHERE' | sudo /Applications/Install macOS Big Sur.app/Contents/Resources/startosinstall --agreetolicense --eraseinstall --stdinpass ```

Worked for me.  Logged in as myself (an admin), and echoing my password.

However, echoing a password of a different user and using --user to specify which user results in

echo 'YOURADMINPASSHERE' | sudo /Applications/Install macOS Big Sur.app/Contents/Resources/startosinstall --agreetolicense --eraseinstall --user "YOURADMINHERE" --stdinpass
Error: could not get authorization... ```

So now to try out some combos in a policy

bizzaredm
New Contributor III

@HCSTech @Strannik

EDIT: Did not work. I made a dumb

However, it seems that even if you su or sudo to another user, it still checks against the user running it. So in jamfs case, root.

luke_reagor
Contributor II

We are piping in the password using the --stdinpass parameter with no issues. Just have to make sure to use the --user parameter.

echo $pass | /Applications/Install macOS Big Sur.app/Contents/Resources/startosinstall --eraseinstall --newvolumename "Macintosh HD" --nointeraction --agreetolicense --forcequitapps  --user $user --stdinpass &

DBrowning
Valued Contributor

@luke.reagor that is working on M1 macs for you?

luke_reagor
Contributor II

@DBrowning Yes. We have an M1 Air and that's the one I'm using it on.

DBrowning
Valued Contributor

@luke.reagor I could have sworn I tried that.....I may have been missing the --user part. But its working!!

luke_reagor
Contributor II

@DBrowning Yeah, that was the last part we had to add to get ours working when we were working through this. But I'm glad you got it going!

Strannik
New Contributor III

@luke.reagor Hmm... I wonder why it didn't work for me?
I was getting this:
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…
Maybe it didn't like my Admin account which was created by Jamf through PreStage Enrollments > Account settings > Create a local administrator account before the Setup Assistant ?

luke_reagor
Contributor II

@Strannik It's possible. Our admin is created the same way with "Make the local administrator account MDM-enabled" and "Skip Account Creation" selected.

bizzaredm
New Contributor III

It wont work with --user if the --user account does not have a secure token... Just did some testing. That seems to be why it did not work for me

You can test with

sudo sysadminctl -adminUser [admin user] -adminPassword - -secureTokenOn [user being granted SecureToken] -password -
sudo sysadminctl -adminUser [admin user] -adminPassword - -secureTokenOff [user being granted SecureToken] -password -

This will prompt you, at the CLI, to first enter the admin user's password and then the user's password.

I assume this error points to that. I see this error in the "install.log" in console

2020-12-11 09:38:31-05 M1TEST startosinstall[1243]: OSISClient: Failed to set LACredentialTypeBootPassword credential: Error Domain=com.apple.LocalAuthentication Code=-1 "Password rejected (3)" UserInfo={NSLocalizedDescription=Password rejected (3)}

Thats what happens to me if the --user account does not have a securetoken. "LACredentialTypeBootPassword"

DBrowning
Valued Contributor

So there goes my idea of creating a temp admin account in the script.

Strannik
New Contributor III

@bizzaredm @DBrowning My Admin user, created by Jamf PreStage, did have a secure token, but command running in script

echo “adminpass” | “/Applications/Install macOS Big Sur.app/Contents/Resources/startosinstall” --user admin --stdinpass --agreetolicense --nointeraction --forcequitapps --eraseinstall --newvolumename “Macintosh HD”

failed with error:

Could not find provided owner on this system

That's because although I specified admin user and piped the password the script runs as root.
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 for me to reinstall Big Sur in Self Service on M1 MacBook Air.
I don't like using admin password inside a script, so it would be good to encrypt it as shown here:
https://github.com/jamf/Encrypted-Script-Parameters

mattmcchesney
New Contributor III

It seems no matter how I try to run this it always tells me the user I am using is not administrator when it clearly is. I have not been able to figure out why after weeks of trying. Any ideas?

I get "Requested user is not administrator. Allow the user to administer this computer is system preferences to continue." But in system preferences it is admin already.

luke_michelson
New Contributor III

@mattmcchesney The only other thing is the admin account needs to have the SecureToken enabled.

mattmcchesney
New Contributor III

@luke.michelson which I just checked at is says secure token is enabled for this user. I did the fetch installer got the install right from Apple and it still says I'm not administrator. Happens for multiple users I have created. I had this all working pre M1 with no issues.

mattmcchesney
New Contributor III

ok well I did a recovery restore and didn't have it enroll in Jamf and the admin user created at login works on this one. Now to figure out what strange combo of settings stops it from working.

mattmcchesney
New Contributor III

I seem to have figured out my issue with this. I had some kernel extensions configuration profiles still applying to this M1 Mac and when they applied it crashed the OS. This also seemed to do something strange to all admin accounts created after that. Didn't think about the two being linked and the intel Macs didn't have this issue. But after removing all the KEXT policy which we have System Extensions for anyway it all seems to be working great now.

faizal_kamarudd
New Contributor II

Hi @mattmcchesney I also have the same problem..current user is admin and secure token already enable for the user..when I use --stdinpass , then error: user is not admin..when I use --passprompt , it is successfully erased and install big sur..not sure what wrong.. I have some kext profile as well, but I don't see it is related to startosinstall command.

Jason33
Contributor II

I'm still not able to get this working. I've even included a script to run make the logged in user an admin, then proceed with the erase and install. Upgrading works, but the policy sits at "Running" for ~45 minutes, then goes to "Executing"...its been 20 minutes on that portion right now.

Jason33
Contributor II

OMG...I ran in Terminal, and the drive wiped and macOS reinstalled, and took me back to the set up screen; so I assumed I was good to go. Powered off the machine, then decided to run remote management, and when I boot up now the machine goes to recovery and says there's no users on the volume to recover. This is...frustrating. Running on an M1 MacBook Air

luke_reagor
Contributor II

@Jason33 Here's some of the messages we're trying to work through. Have you found what is causing your message? We're still trying to figure out what are causing these.

optional image ALT text
optional image ALT text
optional image ALT text

gachowski
Valued Contributor II

@Jason33

I think that is Apple "known/bug" issue I have seen that a few times when restoring an M1 air.. with a normal internet recovery and there is this Apple doc..

https://support.apple.com/en-us/HT211983

C

gyoshi2002
New Contributor

Also dealing with upgrade issues with Big Sur. We tried to leave it off, but due to hardware stock being low, we had not choice. I was also getting that error: could not get authorization... Here's the syntax that has worked via a script within a policy for mac mini's that have a blank password (they are info displays(that needed auto login(setup before my time))). These mac mini's also don't have file-vault enabled as they are considered Non-Human macs. As long as the mac is enrolled via DEP(not self enrolled via the site) you won't see any prompts for privacy, dark/light mode, stuff.

#Just snippet of the code, without checks and logging. 
#Add Secure token to our desktop admin account (I know dumb)
user="desktopAccount"
pass="desktopPass"
currentUser="loggedInUser"
sysadminctl -secureTokenOn "$user" -password "$pass" -adminUser "$currentUser" -adminPassword ""
#After OS install file is cached in Applications folder 
echo $pass | /Applications/Install macOS Big Sur.app/Contents/Resources/startosinstall --nointeraction --agreetolicense --forcequitapps  --user $user --stdinpass &

Jason33
Contributor II

Has anyone gotten this to work with M1's? Works just fine on an Intel machine running these commands via Policy:
/Applications/Install macOS Big Sur.app/Contents/Resources/startosinstall --agreetolicense --forcequitapps --nointeraction --eraseinstall --newvolumename "Macintosh HD"

Henry1
New Contributor

@Jason33 Hi mate

I've tried running the above on an intel mac. When pushing it through Jamf under files and processes its's stating done but nothing is happening? Any advice?

luke_reagor
Contributor II

@Jason33 M1's have extra security which requires admin credentials added to the command parameters. Look at the post above yours... specifically the --user and --stdinpass parameters.