Catalina Macs booting recovery partition after OS update

[RedWings]

Anyone experiencing Catalina Macs booting to the recovery partition after installing a macOS update?

FYI we are using the Jamf built-in Software update policy.

[ImAMacGuy]

I just installed the Catalina update on my machine. Since the update requires a full shutdown rather than a reboot, it returns an error similar to these screens. A quick power off and power back on resolves it.

[hdsreid]

Same issue with the same exact policy. It works fine when the user having the issue manually runs it himself from system preferences. Not really sure what is going on here, but I have temporarily disabled my SWU policy

[macmanmk]

We had the same problem with the 2020-003 security update. I think the issue is with T2 equipped Macs, which as you note, need to be shut down instead of rebooted. The Software Update policy in Jamf doesn't properly shut down T2 Macs and they reboot into the state shown above.

With the help of others here, I found by abandoning the Software Update policy and using softwareupdate from the command line with the --restart flag, the problem is solved.

softwareupdate -ia --restart

[hdsreid]

@macmanmk interesting...the users complaining to me are on newer T2 Macs, while mine with no issues is a 2016 model.

Just to confirm, using that restart command will shut down the T2s?

[jtrant]

I use the softwareupdate binary to patch my Mac servers weekly and still ran into this issue on half my fleet over the weekend. They are all T2 and running Mojave 10.14.6.

[sdagley]

I believe the latest versions of Munki now direct users to System Preferences -> Software Update for Security Updates since softwareupdate no longer provides a reliable mechanism for installing them via scripted control.

[hdsreid]

is there an easy way to make a group for T2 devices? scope by 2018 model and newer? i do not see anything related to it in the inventory

[HCSTech]

@hdsreid Use an EA

!/bin/bash

Report T2 Chip presence in Recon

if system_profiler SPiBridgeDataType | grep "T2"; then tchip="Yes - T2"
fi

if system_profiler SPiBridgeDataType | grep "T1"; then tchip="Yes - T1 "
fi

echo "<result>$tchip</result>"

[RedWings]

@HCSTech
)

So I think I am doing something wrong. Sorry. The one thing I don't use and need to, are Extension Attributes.

[HCSTech]

This might be simpler...
Create a Computer EA with this script... (See Images as well)
Than check your inventory... (Remember to update inventory)
At that point, make a Smart Group or Advanced Search

!/bin/bash

Chip="$(system_profiler SPiBridgeDataType | awk -F: '/Model Name/ {print $NF}' | sed 's/^ *//')"

echo "<result>$Chip</result>"

[hdsreid]

@HCSTech I just made the EA in your latest post and set up my groups. So far so good, thanks for the detailed example!

[RedWings]

@HCSTech Thanks! What should my search criteria be?

[HCSTech]

Similar. I do Like T2...
Keep in mind that this will not be complete until Inventory

[Vaid]

May be you guys need to check on the bridge os causing this

[sburt]

The issue here is when bridgeOS is being updated and the update is calling for a shutdown instead of a restart. The Jamf policy softwareupdate binary does not support the shutdown flag, which causes the update to not apply. Apparently this fix was implemented in Jamf Pro 10.23.0 but I haven't yet tested it: https://www.jamf.com/jamf-nation/feature-requests/7285/add-softwareupdate-restart-support

bp88's AppleSoftwareUpdate.sh takes this into consideration if you wanted to tailor it to your needs: https://github.com/bp88/JSS-Scripts/blob/master/AppleSoftwareUpdate.sh

[hdsreid]

Curious to hear feedback on the fix in 10.23.0. I get upgraded this weekend, hoping it fixes the issue