Ticket #20637 (reopened defect)
kexts are not loaded after Monterey 12.0.1 reboot
Reported by: | granada29 | Owned by: | |
---|---|---|---|
Component: | other | Version: | VirtualBox 6.1.28 |
Keywords: | Cc: | ||
Guest type: | other | Host type: | other |
Description
The VirtualBox kext bundles are not automatically loaded after a system boot.
My workaround is to load them manually:
sudo su - cd /Library/Application\ Support/VirtualBox/ for f in *.kext; do kmutil load -p $f; done
Change History
comment:2 Changed 8 months ago by klaus
- Status changed from new to closed
- Resolution set to duplicate
Duplicate of #20636.
comment:3 Changed 8 months ago by farmerJack
Thanks for the straightforward, sensible and concise reply. This is exactly the issue I was having with Monterey.
comment:4 Changed 8 months ago by coroos
- Status changed from closed to reopened
- Resolution duplicate deleted
comment:5 Changed 8 months ago by coroos
Reopened. #20636 is about VBoxHeadless not starting.
This PR is about kext not being automatically loaded during boot / when needed.
comment:6 Changed 8 months ago by jpeters86
I am not sure if this was already known, but on GitHub someone addressed the possible issue here: https://github.com/hashicorp/vagrant/issues/12557#issuecomment-957559631 I hope this will be useful in creating a new maintenance release which fixes the issues for MacOS Monterey
comment:7 Changed 8 months ago by sorin
Sadly I am unable to load the kernel extensions due to:
Error Domain=KMErrorDomain Code=27 "Extension with identifiers org.virtualbox.kext.VBoxNetAdp,org.virtualbox.kext.VBoxNetFlt,org.virtualbox.kext.VBoxDrv,org.virtualbox.kext.VBoxUSB not approved to load. Please approve using System Preferences." UserInfo={NSLocalizedDescription=Extension with identifiers org.virtualbox.kext.VBoxNetAdp,org.virtualbox.kext.VBoxNetFlt,org.virtualbox.kext.VBoxDrv,org.virtualbox.kext.VBoxUSB not approved to load. Please approve using System Preferences.}
I mention that they do not appear inside Security & Privacy screen, maybe because the prerelease versions are not signed?
comment:8 Changed 8 months ago by klaus
All our builds are always signed, but as the test build page clearly states the overall package isn't notarized which means that the kernel extensions will not be loaded unless you disable SIP. At least that's how it was to my knowledge until Big Sur...
I'm already thinking about creating a special test build for macOS which is notarized, to get this issue resolved for those who can't disable SIP.
comment:9 Changed 8 months ago by summe
hi, noob question, how do I load the kexts manually please? thanks
comment:10 Changed 8 months ago by sorin
Assuring that the test-builds are signed is indeed a very useful thing to do. TBH, I can disable SIP but I will not do it. It is a very bad security practice and I avoiding using any software that requires it, especially as it opens the door for future security issues. SIP is far worse than "root".
I guess that @summe cannot load extension by hand due to SIP too. The commands for loading them are in the first comment, but they will work with test build only when SIP is disabled.
comment:12 follow-up: ↓ 13 Changed 8 months ago by klaus
Could you try with this test build? It is notarized, to avoid the usual SIP trouble...
comment:13 in reply to: ↑ 12 Changed 8 months ago by aydinchavez
Replying to klaus:
Could you try with this test build? It is notarized, to avoid the usual SIP trouble...
I installed your build on my MacOs Monterey (12.0.1) and after a reboot it worked (meaning no need to load kext bundles manually). Grüße
comment:14 Changed 8 months ago by jpeters86
It's working here too!
I confirm. After every MacOS reboot, I need to load the kexts manually...