OS upgrade support for Apple silicon

[Gregory Neagle]

As you may be aware, on Apple silicon, running `startosinstall` to upgrade macOS now requires the credentials of a “Volume Owner”. This means that Munki cannot currently upgrade Apple silicon Macs from Big Sur to Monterey.

I plan to experiment with extending the current authrestartd process (with a probable name change instead) to be able to store the username and password of a volume owner, and then also to be able to run startosinstall with those credentials on Apple silicon.

This means:
1) No automated updates of macOS via Munki, as user interaction will be required to get the credentials
2) Possible failure modes if the current user is not a volume owner

Given the restrictions/limitations, I wonder if this is then ultimately worth the effort. If the user is a volume owner and admin user, they could just run the “Install macOS Monterey.app” directly.

If they are not an admin user, they might be able to trigger an upgrade from System Preferences->Software Update.

If that doesn’t work, I’ve done a proof-of-concept tool that temporarily grants admin to a user, launches the “Install macOS Foo.app”, then removes admin when that app exits. Perhaps that approach is a better use of my time.

Ultimately Apple wants us to either interactively use “Install macOS Foo.app” or rely on MDM to trigger OS upgrades, so I hesitate to build anything particularly complex that Apple is going to break in a year.

Curious about others’ thoughts here.

-Greg

[miawri]

"If that doesn’t work, I’ve done a proof-of-concept tool that temporarily grants admin to a user, launches the “Install macOS Foo.app”, then removes admin when that app exits. Perhaps that approach is a better use of my time."

I would be hugely in favour of this approach if it is doable but understand that it may not be worth it if it won't work in the next iteration of macOS.

Can the installer not be launched by root with the volume owner's password or would that need a cleartext password?  Would this be a simpler approach if possible?  Just spitballing...

-Mike

[Gregory Neagle]

On Oct 27, 2021, at 8:22 AM, 'miawri' via munki-dev <munk...@googlegroups.com> wrote:

"If that doesn’t work, I’ve done a proof-of-concept tool that temporarily grants admin to a user, launches the “Install macOS Foo.app”, then removes admin when that app exits. Perhaps that approach is a better use of my time."

I would be hugely in favour of this approach if it is doable but understand that it may not be worth it if it won't work in the next iteration of macOS.

Can the installer not be launched by root with the volume owner's password or would that need a cleartext password?  Would this be a simpler approach if possible?  Just spitballing...

Why don’t you test and report back?

Generally it’s a bad idea to launch an app as root over a user session…

-Greg

-Mike

On Tuesday, 26 October 2021 at 23:22:58 UTC+1 gregn...@mac.com wrote:

As you may be aware, on Apple silicon, running `startosinstall` to upgrade macOS now requires the credentials of a “Volume Owner”. This means that Munki cannot currently upgrade Apple silicon Macs from Big Sur to Monterey. 

I plan to experiment with extending the current authrestartd process (with a probable name change instead) to be able to store the username and password of a volume owner, and then also to be able to run startosinstall with those credentials on Apple silicon. 

This means: 
1) No automated updates of macOS via Munki, as user interaction will be required to get the credentials 
2) Possible failure modes if the current user is not a volume owner 

Given the restrictions/limitations, I wonder if this is then ultimately worth the effort. If the user is a volume owner and admin user, they could just run the “Install macOS Monterey.app” directly. 

If they are not an admin user, they might be able to trigger an upgrade from System Preferences->Software Update. 

If that doesn’t work, I’ve done a proof-of-concept tool that temporarily grants admin to a user, launches the “Install macOS Foo.app”, then removes admin when that app exits. Perhaps that approach is a better use of my time. 

Ultimately Apple wants us to either interactively use “Install macOS Foo.app” or rely on MDM to trigger OS upgrades, so I hesitate to build anything particularly complex that Apple is going to break in a year. 

Curious about others’ thoughts here. 

-Greg

-- 
Find related discussion groups here:
https://github.com/munki/munki/wiki/Discussion-Group
--- 
You received this message because you are subscribed to the Google Groups "munki-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to munki-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/munki-dev/ce63576a-a4aa-41ea-bb7c-51f22577d615n%40googlegroups.com.

[Joaquin Cabrerizo Egea]

I’m an admin with more than 80% of users with standard permissions but in my opinion you shouldn’t waste your time with this. I’m pushing to move our users to be admins on their macs and that is what we all should do or move our fleet to other platform…

Enviado desde mi iPhone

El 27 oct 2021, a las 17:47, 'Gregory Neagle' via munki-dev <munk...@googlegroups.com> escribió:



To view this discussion on the web visit https://groups.google.com/d/msgid/munki-dev/68783020-B9EC-46E0-B374-4530B23AE777%40mac.com.

[Gregory Neagle]

Appreciate the feedback.

I’ll still have to solve this for myself, however, as most of our users are _not_ admin and I do not see that changing in the near term.

-Greg

To view this discussion on the web visit https://groups.google.com/d/msgid/munki-dev/71C5F0F9-83A6-4EE9-B154-62ED7AB6A2AE%40gmail.com.

[Gregory Neagle]

On the other hand, we didn’t buy very many M1 Macs and can manually upgrade these (in fact we’ve mostly completed this). So I might have a year to solve this for my own needs. :-)

Sent from my iPhone

On Oct 27, 2021, at 1:55 PM, Gregory Neagle <gregn...@mac.com> wrote:

Appreciate the feedback.

To view this discussion on the web visit https://groups.google.com/d/msgid/munki-dev/A6178EFF-C342-4463-A57B-0F5686E13CD6%40mac.com.

[miawri]

This is what I get if I launch the installer as root and use the password of the volume owner : -

`sudo /Volumes/Install\ macOS\ Monterey/Install\ macOS\ Monterey.app/Contents/Resources/startosinstall --agreetolicense --stdinpass`

<Password of current Volume owner>

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.
Preparing to run macOS Installer...
Preparing: 0.1%

And using the wrong password: -

sudo /Volumes/Install\ macOS\ Monterey/Install\ macOS\ Monterey.app/Contents/Resources/startosinstall --agreetolicense --stdinpass

<wrong password>

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.
Error: could not get authorization...`

-Mike

[Steve Yuroff]

The temporary admin grant to run Install macOS *.app then return when done seems like the best return on investment to me.  It's not quite as lovely as existing munki methods, but we have to adapt to the changes Apple throws at us.