Aug 22, 2022, 2:04:45 PM8/22/22
Sign in to reply to author
Sign in to forward
You do not have permission to delete messages in this group
Sign in to report message as abuse
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
I continue to work on support in Munki for upgrading macOS on Apple silicon.
The approach I’m taking is to launch the “Install macOS” app, temporarily promoting the user to admin if needed. You’d think this would be straighforward, but I’ve encountered some unfortunate complications.
In testing with the Install macOS Ventura beta apps, the launch takes a very long time. This makes the UX really poor. Managed Software Center shows the Ventura upgrade; the user clicks “Update”, and in some cases it can be upwards of two minutes before the user sees the main window of the Install macOS app. In the meantime, they get very little feedback.
With the help of some people on the MacAdmins Slack, we found that if we ran the `startosinstall` tool in the app bundle (with the `—usage` flag so it doesn’t actually start the install, that that reduces the launch time. (It doesn’t actually reduce the overall time spent, but we can provide user updates while running that tool)
BUT: this only improves the launch time if the app is copied from the diskimage to local disk — if we run `startosinstall` in the app contained on the mounted disk image, there is no improvement in launch time. Plus now we’ve added the time it takes to copy the app to local disk. But: we can provide user feedback on all the steps up until we actually attempt to launch the app. Even with these “improvements”, the app still takes up to 30 seconds to launch in some cases. It’s still sub-par UX. I’ve not found any way to detect when the main app window is finally displayed, so we can’t have MSC.app display a “please wait” type of message.
To make sure we continue to have sufficient disk space to actually install the OS update, after copying the app to /Applications, we delete the diskimage from Munki’s cache. But this triggers another issue: if Munki runs again before the OS install starts, Munki will see the OS is still not updated, that the disk image is missing, and will download it again. (later, when attempting to install, the disk image may get removed again, but this is a huge waste of bandwidth, potentially redownloading 13G+ of data.
I continue to work on these issues, but I’m increasingly starting to think that support for macOS upgrades on Apple silicon might need some more dramatic re-thinking.
I originally wanted people to be able to just import an “Install macOS” applicaiton, and a single Munki pkginfo item could then be used by Munki on either Intel or Apple silicon, and Munki would adapt it behavior based on the architecture.
But it feels like some of the issues I describe above might be addressed if upgrades on Apple silicon required _two_ pkginfo items.
The first item would simply copy the Install macOS application to /Applications. It would be essentially the copy_from_dmg approach used by Munki to copy applications from a disk image to /Applications. This would allow us to do the copy in the background and the “startosinstall —usage” stuff in the background as well in many cases, improving the user experience. This would also eliminate the potential for repeated downloads of the installer disk image, as the presence of the expected app in /Applications would inform Munki that part of the process was already complete.
The second item, would would require the first item, would be essentially a nopkg item that launched the “Install macOS” application (in the right user context, and temporarily promoting the GUI user to admin if needed). Since much of the “prep work” for the install might happen in the background during an “—auto” run, this would improve the user experience.
What’s the downside here, you might ask? This adds more work for the admin, and potentially increases the disk space usage on the Munki repo. Since the Intel pkginfo and the Apple silicon pkg info are now different, this means a doubling up (or more!) of the work for the Munki admin. And If not careful, the Munki admin might end up with two copies of each installer uploaded to the Munki repo.
It _might_ be possible to rework `munkiimporter` to special-case macOS installs and create and upload _three_ pkginfos instead of just one. I’m not sure how difficult that might be.
End of today’s update!