--eraseinstall for macOS Big Sur

[DBrowning]

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.

[sdagley]

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

[DBrowning]

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

[sdagley]

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

[DBrowning]

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]

More fun things about dealing with M1 Macs

[Chris_Hafner]

Hah! You got forked!

[ABigRock]

Seeing the same thing on an M1 based MBA.

[Strannik]

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]

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

[Strannik]

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

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

[bizzaredm]

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

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

[bizzaredm]

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

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

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]

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

[luke_reagor]

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

[DBrowning]

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

[luke_reagor]

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

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

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

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]

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

[Strannik]

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

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]

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

[mattmcchesney]

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

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]

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]

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]

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]

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]

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

[gachowski]

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

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]

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]

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

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