Inconsistent results with erase-install from Ventura 13 to Sonoma 14

[tubmant]

Our org has been using erase-install 33.1 off and on for full macOS upgrades but now we want all users on Sonoma 14.

When testing on a (Intel) VM logged in as regular user, it runs through and finishes the update properly.  It also worked on about half the client Macs but also fails to work on a lot of other client Macs.  A common failure in the logs is:

2024-08-16 12:16:11 | v33.1 | [get_user_details] user cancelled dialog so exiting...

How are they doing this as it's set for no user interaction and I've done all the screenshots to track the procedure.  Is it hanging somewhere and the error is spurious?  The script is long and convoluted and I'm definitely not comfortable with scripting and therefore not good at interpreting it's errors.

One user was not present for the procedure as they were out of town and later on when trying to upgrade their Mac manually in Software Update, it errored out twice with an 'internal error'.  Manually downloading the Sonoma installer worked.

Does anyone know if erase-install is affected by official Apple OS installer problems or seen this as a wider issue?  Or is there a better method to upgrade the OS to a new major version?  Thanks in advance!

[McAwesome]

Out of curiosity, is there a reason to use erase-install for the upgrade instead of using the built in route from System Settings?  It no longer requires admin (as of 12.3), and it's significantly faster than downloading the full Install macOS package.

erase-install is a great tool for wiping an Intel mac, but as of 12.3 I wouldn't use it for upgrading an end user machine.

[tubmant]

The erase-install tool was experimented with and used by another person in our org for major OS upgrades with some good success and we were looking for ways to upgrade the OS overnight for always-on Macs.  No user interaction.

We've used the built-in OS upgrade and it works (I use it with a standard user account) but the request of us was to do the upgrades without bugging the users.  Sounds like the built-in route is the better way, I'll search to see if that is automateable.

[AJPinto]

You mentioned they tried to manually upgrade and it failed which rules out any of the scripting causing issues. MacOS Updates can be a pain to troubleshoot, 95% of the time the issues are network related, but it is possible to get bad source files. MacOS records macOS updates logs in /var/log/install.log, this is where I would start for anything involving OS updates and upgrades.

I suggest moving away from erase my Mac, and using MDM/DDM commands as Apple is pushing for that method to manage updates. With Apple you really do it their way or you don't do it at all. Without a strong background in scripting, erase my Mac may be just too much to use.

[tubmant]

Based on your response and the one below, it sounds like moving to DDM is the recommended path, time for some searching and learning.

[mschlosser]

I'd agree that DDM based update commands are for the best; that being said I'd also advocate for the fact, that they really only work with any reliability on the latest OSes and you gotta get there somehow as they say. That said I recently used the following command to upgrade 100+ machines to Sonoma without any user interaction whatsoever.

curl -s https://raw.githubusercontent.com/grahampugh/erase-install/release/erase-install.sh | zsh /dev/stdin --os=14 --reinstall --check-power --no-timeout --very-insecure-mode --credentials <base64 encoded credentials here>

Goes without saying, all kinds of bad form here, piping to zsh, embedded base 64 creds, that said I trust the script as does the community, all said it did work to easily bring the fleet to Sonoma where DDM is much more predictable.

Directions are here:

https://github.com/grahampugh/erase-install/wiki/5.-Erasing-macOS

Base 64 encode script is here:

printf "%s:%s" "<USERNAME>" "<PASSWORD>" | iconv -t ISO-8859-1 | base64 -i -

After you get to v14, rely on DDM

Hope that helps.

M

[tubmant]

I might not be able to get away with sending encoded credentials in the DDM command but I will explore this option.  Thanks for the links!