- #GET MACOS BIG SUR INSTALLER HOW TO#
- #GET MACOS BIG SUR INSTALLER INSTALL#
- #GET MACOS BIG SUR INSTALLER CODE#
# Not sure if using the –path option makes a difference
Spctl -add "/Applications/Install macOS Big Sur Beta.app" Volumes/Macintosh\ HD/System/Library/Frameworks/amework/Frameworks/amework/Support/lsregister -R -f "/Applications/Install macOS Big Sur Beta.app" # Stop spotlight from trying to index app Spctl -a "/Applications/Install macOS Big Sur Beta.app" Xattr -cr "/Applications/Install macOS Big Sur Beta.app" # Clear all extended attributes recursively from app bundle Xattr -dr "/Applications/Install macOS Big Sur Beta.app"
#GET MACOS BIG SUR INSTALLER CODE#
Investigating options to workaround code signing validationįor the curious, I did try a bunch of things to kick off the code signing validation before I tried to launch the app or to avoid code signing validation altogether. I assume that spctl is the tool that’s supposed to interact with syspolicyd.
#GET MACOS BIG SUR INSTALLER HOW TO#
There is a CLI to this: /usr/libexec/syspolicyd but it’s not very clear to me how to interface with this or whether I’m supposed to. The .find.bundles key seems to be relevant based on the name. There is a Launch Daemon at /System/Library/LaunchDaemons/.plist which seems to have the frequency at which some syspolicyd actions might be taking place depending on the LaunchEvent. Some research on syspolicyd that helped a bit in my testing and research: If you try to see what’s going on in the when you launch the installer macOS app, you will see XProtectService mentioned in the Console logging when dealing with one of these apps and syspolicyd. Additional research XProtectService and syspolicyd Jamf has a good article that discusses the various options for providing Apple with feedback. This would also have benefits to other large apps as well. You can run the script immediately after deploying the installer app to the computer.įile feedback with Apple so that they can improve this user experience and macOS installer apps can be scanned immediately after a download has taken place.
#GET MACOS BIG SUR INSTALLER INSTALL#
The idea is to make the user experience better so that when the user launches an OS upgrade whether through a GUI install (as Apple intends) or a CLI install relying on “startosinstall” there’s no a 2-3 minute period of silence. I’ve designed it for use in Jamf Pro, but you could easily modify it for other uses if you wanted. I’ve written a simple script that is designed to run immediately after “Install macOS Big Sur.app” has been installed. This will not actually run an OS upgrade and macOS will start to scan “Install macOS Big Sur.app” silently in the background. This would obviously lead to a bad user experience for the end user.Īs a workaround, you can trigger the code signing validation by using startosinstall -usage.
There’s no way to force macOS to scan a particular app for its code signature validation other than actually trying to run it. If you run the app through the CLI using startosinstall, it will show no activity until the scan completes. If you launch the app installer through the GUI, the app will simply bounce in the dock until the scan completes. The macOS installer app for Big Sur suffers from this too and as a result if you try to run “Install macOS Big Sur.app” it will take at least 2 minutes while macOS scans it. Some apps include: Xcode, Matlab, Mathematica, etc. This results in some really large apps taking 2-3 minutes before they can run. As part of Gatekeeper, macOS runs a code signature validation scan on all apps when they are run the first time.
0 kommentar(er)
