JSS-Scripts/OSUpdateNotifier.sh - macOS 11.3.1 Update only rebooting but not installing

[hutzinger]

Hi!

First of all, your script is great.

I have the same issue like mani2care with the AppleSoftwareUpdate.sh script had (issue 2):

When 3 deferrals on macOS 11.3 are reached, all notifications work, the OS reboots, but no software updates will be installed. I attached a part of the install.log. Perhaps you can see something.

How is your experience updating macOS 11 systems?

Kind Regards! macOS-11.3.1_update_install.log

[klssland]

I am also experiencing this issue on 11.4 and 11.2.3

[bp88]

Sorry folks. I think this is unknown behavior with the softwareupdate cli tool in Big Sur. I've noticed this when a user is not logged in but also when a user is logged in. Please keep in mind that for Intel Macs, I'm simply running softwareupdate -iaR. Unfortunately, the logs do not indicate why the update did not install and restart.

My experience on getting Big Sur updates to go through successfully has been hit or miss. In a future update, I'm thinking of removing use of the softwareupdate cli tool to perform updates on Intel Macs and simply use the same workflow I'm using for Apple Silicon Macs which is to force a shutdown after the user has postponed enough times.

[mrazishere]

We are encountering more of this behaviour in 11.5.2 update, just wondering if there's anything to take note if we standardize the Forced Update workflow for both Intel and M1 macs going through GUI instead of CLI?

I can only think of the user not clicking the update button even after being redirected to the Software Update UI?

[Samstar777]

We do see the same issue on OSUpdateNotifier.sh:

All Notification, Defer works correctly and then force update starts > Mac reboot's and come back to macOS but minor update was not done. Can you help fix this. @bp88

[jandersonpos]

@bp88 What workflow are you using on Apple Silicon Macs to get Big Sur to update?

[bp88]

@jandersonpos On Apple silicon Macs, the workflow is described here: https://babodee.wordpress.com/2021/03/30/handling-major-upgrades-and-minor-updates-for-macos-with-jamf

The relevant portion to your question:

if we’re dealing with major OS upgrades and minor OS updates on Apple Silicon Macs, the user will simply be given a final chance to perform the upgrade/update before the computer is shut down. The user will get at least an hour (or longer if you’ve set the Time Out period to be longer) to perform the OS upgrade/update once they’ve reached this state. On Apple Silicon Macs, you cannot perform a command line install without user interaction which is why a command line install is not attempted. if we’re dealing with minor OS updates on Intel Macs, a command line install will take place.

[bp88]

@Samstar777 See my earlier response. I'm aware. Unfortunately, I cannot find a pattern as to why this is happening.

[jandersonpos]

@bp88 Just to be clear, and it looks like this is the case when I read through the script... if the user is on Apple Silicon and and update is required and they have reached their allowed number of deferments, the computer just shuts down, but does not perform any updates?

[bp88]

@jandersonpos That's correct. There is no command line method at the moment with Jamf that would allow us to perform software updates without user interaction which means there's no way to force the computer to update. Therefore a little bit of annoyance is required in the form of shutting the computer down.

[bp88]

I've got a bit more information to share from testing and some potential updates to this issue. It appears that in Big Sur and possibly Catalina, when you try to run softwareupdate -iaR from a process that's 1) initiated from a launch daemon (and that's how would be running this) and 2) there is a logged in user, the software update process starts, states that it can't proceed, but never terminates itself. However, if there is no user logged in, the process is able to proceed.

This is problematic for a few reasons:

1. The softwareupdated process is failing but not terminating itself. Therefore the script continues to run waiting for this process to finish. It never will. This is a bug that Apple needs to resolve. I'm not currently in a position where I'll be able to file feedback to Apple on this. You can easily reproduce this by creating a launch daemon that simply runs /usr/sbin/softwareupdate -iaR and just monitor the install.log.
2. It's not clear when Apple changed this behavior and if they will alter it again.
3. It seems like the user of the parent process calling softwareupdate and the user session need to match up in order for the update to proceed. This will never be the case with Jamf since it's running things via launch daemons which launch as root.

What I've done as a result is I've modified the script to:

1. attempt a software update run when no user is logged in on Macs running not running Apple silicon and on macOS 11 or higher.
2. Additionally, on Intel Macs any software updates where a user is logged in will use the same method of forcing the user to update via the GUI as Apple silicon Macs use. That means, the user will be forced to perform the OS update via the GUI and shutdown if the user does not comply within the hour.

As of this comment, only updates are being released for Catalina, Big Sur and Monterey. I try to focus on the latest major OS that Apple releases so I don't particularly care about Catalina which means I'm not going to test if the behavior I've encountered is the same on that operating system.

This latest update to the script does not address the fact that the softwareupdate process may start and fail but never terminate itself leaving the script in a state where it is running indefinitely. That needs to be addressed in some other fashion.

Note: Attached is a log of a sample run from softwareupdate -iaR being called by a launch daemon when a user is logged in so you can see the output from /var/log/install.log. install_log.txt