Fwd: [munki-dev] OS upgrade support for Apple silicon

225 views
Skip to first unread message

Gregory Neagle

unread,
Oct 27, 2021, 11:49:16 AM10/27/21
to 'Gregory Neagle' via munki-discuss
Forwarding to munki-discuss to get more visibility and feedback.

Begin forwarded message:

From: 'Gregory Neagle' via munki-dev <munk...@googlegroups.com>
Subject: [munki-dev] OS upgrade support for Apple silicon
Date: October 26, 2021 at 3:22:55 PM PDT
To: munki-dev <munk...@googlegroups.com>

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/75602881-66E8-4E53-AC7F-E8D540EF4DFC%40mac.com.

Steve Major

unread,
Dec 20, 2021, 2:46:14 PM12/20/21
to munki-discuss
We don't have much Apple silicon yet, but for us the big thing is classrooms/labs. Walking around to 40 machines at a time and over 100 teaching rooms to kick off the OS installer is a little crazy and I am, as usual, scratching my head at Apple's worldview. :) So, any automation that could help would certainly be welcome!

lorisarvendu

unread,
Aug 31, 2022, 5:53:13 PM8/31/22
to munki-discuss
Luckily we use the same admin user for all our lab machines,  so I can do it through ssh.  Scp the dmg to each client. Mount it, copy startosinstall to /users/shared. Remove mount. Rm dmg (in case of space issues) and run startosinstall with the passprompt switch. Got it down to to a fine art.

Gregory Neagle

unread,
Aug 31, 2022, 5:54:38 PM8/31/22
to 'Gregory Neagle' via munki-discuss
Seems like Graham Pugh’s eraseinstall tool (https://github.com/grahampugh/erase-install) would be valuable for automating this further…

-Greg

-- 
You received this message because you are subscribed to the Google Groups "munki-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to munki-discus...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/munki-discuss/7641c3ef-d28b-4535-b99d-2e5dbc419c59n%40googlegroups.com.

lorisarvendu

unread,
Sep 1, 2022, 9:22:36 AM9/1/22
to munki-discuss
A bit of clarification of the issues we've found with remote upgrading.  Most of our student lab machines are still Intel, but we have two rooms of Silcons now, and by next week we will have three more rooms of M1  Mac Studios.
When remotely upgrading from Big Sur to Monterey, the EraseInstall option isn't allowed if there is a minor update available, and advises you to upgrade to that first!  So 11.4 can't be erased to 12.5, nor can 11.6.7, because 11.6.8 is available. Catalina or Mojave (or even High Sierra) no problem, no matter what version you're on, because minor updates for them aren't available.  If you're on 11.6.8, erase and install Monterey works fine, and simple upgrade to Monterey (with no erase) is fine on any previous version of Big Sur.

The same applies to Silicons on Big Sur, with one horrible proviso.  Even if you manage to remotely erase and install by providing the volume owner credentials, the Mac still starts up at a black Recovery Console  language selection screen for activation, requiring a finger to press the Enter key.  The Mac then activates, reboots, and if you have zero-touch enrollment (we have Jamf Pro), then your input is no longer needed. But it seems there's no way to avoid a physical finger on a button.
Reply all
Reply to author
Forward
0 new messages