More updates on supporting macOS upgrades on Apple silicon
64 views
Skip to first unread message
Greg Neagle
Aug 22, 2022, 2:04:45 PM8/22/22
to munki-dev
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!
-Greg
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!
-Greg
Nick McSpadden
Aug 22, 2022, 2:12:22 PM8/22/22
to munk...@googlegroups.com
I'm personally in the camp that the goal of having a single unified pkginfo installer that "just works", while a noble goal, doesn't seem super worth the amount of work involved. I think the two-pkginfo approach - one for getting it on disk, the other for actually doing something - makes sense, and could also potentially be abstracted by another CLI tool (or even just a tiny script). While the additional load on the repo is generally not fun, this is already part of the cost Munki operators will generally accept so I don't think this adds a significant burden.
--
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/7FDBF2C9-56F8-4ED2-B6FF-CC7E90902417%40mac.com.
Greg Neagle
Aug 22, 2022, 3:02:46 PM8/22/22
to munki-dev
There doesn’t _need_ to be extra “load”/diskspace usage in the repo — multiple pkginfo items can point to a single downloadable installer item.
-Greg
Rob Renstrom
Aug 22, 2022, 4:22:08 PM8/22/22
to munki-dev
To overcome the issue of it re-downloading the disk image, perhaps add a special case in download_installeritem code to skip the download (return True) if the pkginfo installer_type is startosinstall and there's an existing Install macOS Foo.app previously copied to /Applications that matches the version in the pkginfo (looks like DTPlatformVersion in the app Info.plist is the OS version that will be installed, except in cases where's it a patch version it just has major.minor, eg 12.2.1 has DTPlatformVersion 12.2).
greg.neagle
Aug 22, 2022, 4:39:45 PM8/22/22
to munki-dev
The complexity makes properly testing this sort of thing and making sure there are no unexpected interactions really difficult.
a special case in download_installeritem code to skip the download (return True) if the pkginfo installer_type is startosinstall and we're on Apple silicon and there's an existing Install macOS Foo.app previously copied to /Applications that matches the version in the pkginfo and then also make the osinstaller code skip mounting the disk image and instead use the existing /Applications/Install macOS Foo.app as long as it seems to match the one in the pkginfo, but if we skip mounting the dmg in this case, also remember to remove it if it's present oh and now also modify makepkginfo to also record additional keys from the app's Info plist like DTPlatformVersion and DTPlatformBuild (so we can distinguish Ventura betas from one another since they are all DTPlatformVersion 13.0....
It's so convoluted.
Reply all
Reply to author
Forward
0 new messages