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 Problem
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.
JSS Detection
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
Something like:
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.
Resolution
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.
SIP
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.
Managing Updates
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.
So if I’m reading the correctly it only causes issues on machines that have an actual Ethernet port compared to using a thunderbolt to ethernet adapter?
Yep.
I guess the solution is to make sure no updates get installed the day they are released. What’s the best way of doing that, but keeping auto updates enabled? (Looking to avoid having to manage a SUS though).
We have the schedule off. But weekly run SoftwareUpdate -ia. Just dumb luck it is on a Monday.
You can also block updates client side. But it becomes a chicken & egg scenario.
Ben, do you know if hand installing Incompatible Kernel Extension Configuration Data 3.28.2 (the fixed version) from a PKG stashed on a techs thumb drive fixes this…it seems to at the moment. I harvested the fixed update from a working software update server. Of course user must reboot after installing. Tech should be able to fix easily on a Mac if confirmed. I can confirm I grabbed Incompatible Kernel Extension Configuration Data 3.28.2 and not Incompatible Kernel Extension Configuration Data 3.28.1.
It seems to work but wanted someone else in the wild to confirm.
People have said it fixed it on Slack.
Sadly (luckily), I had no devices affected. So couldn’t test.