On Friday, Apple released an update titled “Incompatible Kernel Extension Configuration Data: Version 3.28.1”
This update was an exclude list of bad Kernel Extension’s for 10.11 & included an Apple Kernel Extension.
Below is some more information on this & a possible way to detect affected Macs via the JSS.
The update itself was not a “normal” Apple Software Update, instead it the update was a “ConfigData” update. This is the same as GateKeeper updates.
If an 10.11 Mac is set to automatically “Install system data files and security updates” as per the below, then they may have downloaded the update.
But, don’t worry. If your 10.11 Macs have been on over the weekend they will also have installed the update that Apple released addressing the issue via the same mechanism, “Incompatible Kernel Extension Configuration Data: Version 3.28.2”
It’s also worth noting that a Mac that has the “Incompatible Kernel Extension Configuration Data: Version 3.28.1” update installed but wasn’t restarted afterwards, you might not see the issue as the exclude list would only take affect on start up.
The Real Problem
Now the real problem comes down to the following:
- You have a lab of 10.11 Macs that installed “Incompatible Kernel Extension Configuration Data: Version 3.28.1” on Friday.
- These Macs powered off over the weekend before installing “Incompatible Kernel Extension Configuration Data: Version 3.28.2”
- These Macs clients are on ethernet only.
If you’re Macs are managed via the JSS & you recon regularly, you might be able to create a smart group that detects Macs that might be affected by the above.
This might alert you to a group of Macs that installed “Incompatible Kernel Extension Configuration Data: Version 3.28.1” then powered off (such as under the above circumstances).
Or clients that have had the update installed, powered off over the weekend, & connected to wi-fi when next on.
To create Smart Group for this, the criteria is:
Packages Installed By Installer.app/SWU has com.apple.pkg.IncompatibleKextConfigData.14U2129 AND Packages Installed By Installer.app/SWU does not have com.apple.pkg.IncompatibleKextConfigData.14U2130
The above can be entered in manually. However if you press the dotted button, you’ll get a list of all the Packages Installed By Installer.app/SWU & you can search that this for the KextConfigData updates:
One other thing to note is that this only affects some models of Mac. Sadly (luckily), I don’t have any affected Macs on my JSS.
But you might want to also limit the scope to only iMacs, Mac Pro’s & MacBook Pros.
Apple has posted an updated version of the update as well as this support article.
If you’re going the Smart Group route, I’d advise writing a policy that then issues the below to the members of the group:
sudo softwareupdate --background
Then asking the user to restart, or maybe building a script out that will do the above. Then check to see if a user is logged in via this method (nothing is returned if no one is logged in).
If someone is connected to Wi-Fi, they might not notice. But if you have ethernet only labs then you might have a bad Monday.
So with 10.11, we now have SIP. This causes an issue with a resolution for things like this.
Apple have their own exclusions, & so their installers can work without being impacted. But means that we cannot easily resolve this without booting into something like the Recovery HD or a NetInstall where SIP is not active.
This is shown in Apple’s support article.
For years, admins have managed updates via Apple’s Software Update Server or Reposado. This allows the admin to manage the updates offered to clients.
You can disable the client side autoupdates via:
sudo softwareupdate --schedule off
Which is shown via the GUI as per:
For more information on what you’re missing when disabling updates, see this post.
So, don’t do that.
I mean, you could. Just not without architecture in place to update on a regular interval or the ability to manage those offered to clients.