Hi everyone,
I recently upgraded my MacBook Pro 13" 2014-mid from High Sierra to Mojave. I used Karabiner only for eliminating the caps lock delay, and I found Karabiner 12.10 and 11.6 both not work on Mojave 10.14.6. (I have updated to Security Update 2020-004)
There are lots of messages shown in Karabiner Log like:
[info] [kextd] KextManagerLoadKextWithURL: kOSKextReturnNotLoadable
This message shows every 3 seconds. I also found relevant logs in macOS console as follows:
Error making temporary directory: 1
Memory allocation failure.
Unable to stage kext (/Library/Application Support/org.pqrs/Karabiner-VirtualHIDDevice/Extensions/org.pqrs.driver.Karabiner.VirtualHIDDevice.v061000.kext) to secure location.
org.pqrs.driver.Karabiner.VirtualHIDDevice.v061000 was unable to stage properly; failing.
What I have tried:
/var/db/SystemPolicyConfiguration/KextPolicy with sqlite3 command that Karabiner is allowed.spctl kext-consent add G43BCU2T37.ls -laO /Library/StagedExtensions/ and checked the flag of /Library/StagedExtensions is "restricted"sudo kextload and sudo kextutil org.pqrs.driver.Karabiner.VirtualHIDDevice.v061000.kext but both failed (sudo kextutil gave the exact messages shown in macOS console)All measures failed. The only way I could make it work is to keep SIP off, which I really don't want to.
Does anyone have any idea? It's really frustrating. Any help is appreciated.
Based on the temporary directory error, can you check the permissions and flags for the following:
/private/var/db/KernelExtensionManagement should be 0755 with the "restricted" flag set, and the com.apple.rootless attribute set to KernelExtensionManagement (you can check the value of the attribute with xattr -l)/private/var/db/KernelExtensionManagement/Staging should be 0755 with the "restricted" flag set.I recently had an issue where VMWare Fusion broke聽after upgrading to 10.14.6, and after some digging around through the console log, I found that it was trying to use these directories while staging the kexts.
When compared to another Mac running 10.14.6, I found that the "restricted" flag was not set against KernelExtensionManagement, which appears to have affected how SIP treats the directory.
If that's the case for you, you should be able to repair it using chflags (e.g chflags restricted /Volumes/Macintosh\ HD/private/var/db/KernelExtensionManagement) from the terminal in recovery mode.
Oh my! It works! I don't know how to express my appreciation to you @StoneJT! It costed me so much time on solving this problem. For IME other than English, caps lock is usually the default way to switch between that language and English. Caps lock delay really drives me crazy. Thank you so much on providing such a detailed solution!
Glad it worked out. This was the only result I got whilst searching for "error making temporary directory: 1", so I wanted to make sure I replied once I figured out what was happening.
@StoneJT
Not related to this repo, but I was having problems with some external kexts not being loaded, mainly:
And I've been debugging non-stop, and was even planing on doing a full new clean OS install since I had this issue. (This after upgrading from High Sierra to Catalina).
Thank you for the tip, would have costed me a good few hours of work for nothing!
Cheers.
@StoneJT This actually also helped me with an issue in VirtualBox! I do find it odd that I don't see any difference on
# xattr -l /private/var/db/KernelExtensionManagement
com.apple.rootless: KernelExtensionManagement
# xattr -l /private/var/db/KernelExtensionManagement/Staging
after running chflags. Also I ran chflags on "Staging" quite a lot as it appeared to do nothing from within the rescue console. But as I said, it worked nevertheless!
I have a different Mac where the entire directory /private/var/db/KernelExtensionManagement does not exist, so maybe you could also just delete it?!
EDIT:
Found this to actually show the restriction, the rootless attribute is probably something different for SIP.
# ls -ldO /Volumes/Macintosh\ HD/private/var/db/KernelExtensionManagement
drwxr-xr-x@ 3 root wheel restricted 96 30 Sep 12:16 /Volumes/Macintosh HD/private/var/db/KernelExtensionManagement
# ls -ldO /Volumes/Macintosh\ HD/private/var/db/KernelExtensionManagement/Staging
drwxr-xr-x 2 root wheel restricted 64 4 Nov 21:57 /Volumes/Macintosh HD/private/var/db/KernelExtensionManagement/Staging
@StoneJT, just wanted to add my thanks as well. I've been dealing with issues with several apps (Google File Stream, AdGuard, TripMode, Shimo) failing here and there and I could not find the cause. Adding that 'restricted' flag solved the problem.
* `/private/var/db/KernelExtensionManagement` should be 0755 with the "restricted" flag set, and the `com.apple.rootless` attribute set to `KernelExtensionManagement` (you can check the value of the attribute with `xattr -l`) * `/private/var/db/KernelExtensionManagement/Staging` should be 0755 with the "restricted" flag set.
@StoneJT thank you. This fixed an issue I had with VMware Fusion after reinstalling Mojave 10.14.6 on top of the existing Mojave 10.14.6. VMware was in the sqlite3 of approved KEXTs but wouldn't load its KEXTs.
You've earned a virtual mug of your favorite brew!
Turns out that just putting /private/var/db/KernelExtensionManagementin your trash fixes it, as it is recreated when needed!!!
Most helpful comment
Based on the temporary directory error, can you check the permissions and flags for the following:
/private/var/db/KernelExtensionManagementshould be 0755 with the "restricted" flag set, and thecom.apple.rootlessattribute set toKernelExtensionManagement(you can check the value of the attribute withxattr -l)/private/var/db/KernelExtensionManagement/Stagingshould be 0755 with the "restricted" flag set.I recently had an issue where VMWare Fusion broke聽after upgrading to 10.14.6, and after some digging around through the console log, I found that it was trying to use these directories while staging the kexts.
When compared to another Mac running 10.14.6, I found that the "restricted" flag was not set against KernelExtensionManagement, which appears to have affected how SIP treats the directory.
If that's the case for you, you should be able to repair it using chflags (e.g
chflags restricted /Volumes/Macintosh\ HD/private/var/db/KernelExtensionManagement) from the terminal in recovery mode.