2019-004 High Sierra 10.13 Security Update pulled over wake from sleep kernel panics

After investigation it looks like only EmbeddedOS (T1) and BridgeOS (T2) systems are affected.

2017 iMac Pro
2018 Mac Mini
2018-2019 Macbook Air
2016-2019 MacBook Pro with Touch Bar

I just confirmed that the installer will create a Time Machine localsnapshot.

You can boot to recovery and restore to a point before the update is installed. NOTE: the snapshot only lasts for 24 hours.

Check to see if you still have the snapshot by running this command

tmutil listlocalsnapshots /

Yikes they just pulled the 2010-004 Sierra update! Must be the same problem as High Sierra.

https://support.apple.com/kb/DL2013

@ClassicII I've reached out to Apple Enterprise Support and they have nothing to share regarding the issues with these updates...
Gave up when they asked for a sysdiag in order to escalate with Product Engineering...

@myronjoffe

Thanks for the update, I was going to do the same but figured after the update was pulled engineering knew something was wrong.

The thing is, how was Enterprise Support not informed ???

I was hoping they could at least give us a timeframe for when the fixed update will be available.

I've got one similar issue report. User with MBP 15-inch (Mid 2017)

I had a user yesterday with it, upgraded them to Mojave and everything worked fine after that.

We also have a ticket open about this, let's keep pushing for an answer...

Thanks for posting. I was wondering why my Smart Group with value Security Update 2019-004-10.12.6 was shrinking.

Great blog btw...

Guess that explains why they were suddenly listed as deprecated in reposado without a superseding patch!

This is why we have a testing branch and wait a few days before unleashing to the world...

The updated version of 2019-004 was just released for 10.13 and 10.12 and looks to fix the issue.

Is there a good way to force a Mac to re-run an update that was already successful? We only scope to run updates on machines that have them available, and none of them are showing that currently.

-Edit- Nevermind, we've had a few machines start to update themselves via Apple Software Updates this morning.

Is the system version number any deferent when never 2019-004 installed?

Yes - now 17G8030

Thank you Sean

It’s build 16G2128 for Sierra.

The trick question in my mind is now what do I do if the old pkg is cached and my start group has 450 systems in it... I suppose rename the new pkg with the build in the name and modify the smart group the install policy is scoped to?

Is there a more elegant way to tweak a smart group so that it looks for the new version of SecUpd2019-004<OSVersion>.pkg? It looks like we're literally stuck just looking for a filename... :-(

Sorry, we have no more Sierra. HS and Mojave only

@Sterritt I'm going down the route of purging old the pkg from the waiting room and re-caching the new one

This post has a few methods of achieving it.

https://www.jamf.com/jamf-nation/discussions/5878/removing-or-purging-the-waiting-room

@garybidwell Long story short - I don't think you need to purge, just flush any caching policy logs, the new instance of the file should replace the old one. I'd love to know the logic of how that works (will it copy older file over newer?) Anyway, no need to specifically purge waiting room, but I appreciate the link because I've got a few malingerers loitering there.

Longer Story: Sorry that I wasn't clearer before; I've set up two policies - one to cache SecUpd2019-004 to each machine scoped to machines without the current build and one to install the cached update scoped to machines that have it cached. Since the cache policy more or less completed last week on the 23rd, but I had to pause my deployment scheduled for the 25th for impacted Macs (more touchbar / T#-security headaches!) I didn't know whether simply flushing the original cache policy and replacing the pkg in both policies with the new build SecUpd2019-004, adjusting the scope of the current build smart group accordingly, would suffice to get the new pkg on all those machines. Since the filename was the same I was worried that the cache policy would see the file was already present and not push the new build instance to that client...

I implemented it nevertheless, and went home.

Then in a panic the next morning I renamed SecUpd2019-004 to SecUpd2019-004-current in Jamf Admin's packages. Upon running the install cached policy it failed because it couldn't find the cached file, because it had been pushed to the client with the old name. It looks like most of the fleet needing the update received it overnight, and a little further testing/examination/spot checking proves out that the new version of the package with the same name does indeed get cached to clients.