Install of kernel drivers fails with osx 10.14.5

[Tunesi Edoardo Fabio]

During installation of VBOX the OSX system show a message to contact Oracle because the software is not compatible with the last upgrade of OSX and the installation fails.

This problem appears after upgrading OSX to 10.14.5 version.

The same error also trying installing previous versions of VBOX.

[spb]

Popup error

[spb]

Same issue. Running VBox GUI works but starting a VM fails with attached screenshot. Error shown is : Failed to open a session for the virtual machine Kali-Linux-2017.2-vbox-amd64.

The virtual machine 'Kali-Linux-2017.2-vbox-amd64' has terminated unexpectedly during startup with exit code 1 (0x1).

Result Code: NS_ERROR_FAILURE (0x80004005) Component: MachineWrap Interface: IMachine {5047460a-265d-4538-b23e-ddba5fb84976}

[Maxim Dounin]

Same here, likely due to notarization of new/updated kernel extensions being required on 10.14.5. Allowing Oracle kernel extensions via

spctl kext-consent add VB5E2TV963

in the recovery mode (command-R on boot) fixes this, see ​this forum thread for details.

[spb]

That's fixed it for me. Thanks.

[Robert Blair]

Just commenting to confirm that the installation of VBox 6.0.8 fails on macOS 10.14.5 for me unless I either disable SIP or add the kext signing trusted vendor ID. Booting into Recovery Mode via Command-R and opening terminal to execute the following command:

spctl kext-consent add VB5E2TV963

Afterwards, rebooting back into the Normal OS environment allowed me to install with no kernel.exit errors. I'd guess this is because VBox does not have their kext extensions notarized. Would have been nice if they included a warning about this problem and the resolution. I'm sure the developers were aware when they created the *.dmg that this would be an issue for most/all of those installing on macOS 10.14.x.

Thanks @mdounin for the solution.

[fdik]

Same here. Fixed by installing Virtualbox 6.0.6, which still works here. macOS 10.14.5 (18F132)

[flofloi]

Replying to fdik:

Same here. Fixed by installing Virtualbox 6.0.6, which still works here. macOS 10.14.5 (18F132)

Same for me. Old version works. 6.0.8 is broken.

[Oompa Loompa]

Can we get a statement from the development team please? Are you aware of the problem? Are you working on getting the kernel extensions notarized? Is there an ETA? Will there be a new release? Is going through the Recovery Mode the recommended workaround for now? Thank you.

[Tunesi Edoardo Fabio]

Using spctl the install procedure ends correctly but the driver is not installed correctly.

Currently fixed by installing Virtualbox 6.0.4 ( 6.0.6 still have the problem ).

[Robert Blair]

Replying to tunesif:

Using spctl the install procedure ends correctly but the driver is not installed correctly.

Currently fixed by installing Virtualbox 6.0.4 ( 6.0.6 still have the problem ).

Must be executed in Recovery Mode. If you did boot into Recovery Mode, then you've got a different problem. Perhaps, clearing your kext cache. Perhaps, using the uninstall tool in the *.dmg, rebooting into Recovery Mode, adding the ID, and then a new installation. Either way, this method worked for more than one person on multiple sites.

[Tunesi Edoardo Fabio]

Ok, solved. Thank you very much!! 6.0.8 installed and working correctly following your instructions.

Replying to CHA05 R31GN5:

Replying to tunesif:

Using spctl the install procedure ends correctly but the driver is not installed correctly.

Currently fixed by installing Virtualbox 6.0.4 ( 6.0.6 still have the problem ).

Must be executed in Recovery Mode. If you did boot into Recovery Mode, then you've got a different problem. Perhaps, clearing your kext cache. Perhaps, using the uninstall tool in the *.dmg, rebooting into Recovery Mode, adding the ID, and then a new installation. Either way, this method worked for more than one person on multiple sites.

[Kevin L Mitchell]

I'm also having this problem. Will look into the suggested spctl fix.

[mkw]

I cannot open terminal in recovery mode due to some sort of MDM issue (the "No administrators found" problem).

Is there any other workaround for 6.0.8? I did manage to get 6.0.6 working, as I suspect that that version was installed before the upgrade to 10.14.5, but not being able to receive future updates is quite problematic.

[Martin Häcker]

Commenting to get notified of changes / discussion here

[Robert Blair]

Replying to mkw:

I cannot open terminal in recovery mode due to some sort of MDM issue (the "No administrators found" problem).

Is there any other workaround for 6.0.8? I did manage to get 6.0.6 working, as I suspect that that version was installed before the upgrade to 10.14.5, but not being able to receive future updates is quite problematic.

Since it's an issue with kext signing/notarization, then another solution is disabling SIP. Obviously, if you can't use terminal in Recovery Mode, then you could boot into Single-User Mode. However, if you've got a permissions requirement of needing to approve changes per an administrator account, then I don't know of a workaround. If this is your notebook to make all changes to and isn't issued by another controlling entity, then you should work on why you're not able to access the administrator account. You've got a bigger problem than just kext signing problems. If you're not supposed to make changes to the notebook because it's controlled by an actual Sys Admin and you don't have permission to access system-wide changes, then you should contact whoever has administrative access.

[mkw]

Two issues:

• Machines with the T2 chips and MDM either always or often have Single User mode disabled.
• The SIP is enforced and impossible to disable, even in single user mode. Recovery mode is required because it boots off of a separate partition.

I suspected that the only options are to:

• Get our IT to update the MDM to use one of the ways of pre-loading the signatures into /var/db/SystemPolicyConfiguration/KextPolicy
• Wait for Oracle to get the kext files notarized.

Neither is desirable, but the bulk of our use of VirtualBox is for Docker, so we'll likely have to explore a port of our internal tools to Docker for Mac.

[Robert Blair]

Replying to mkw:

Two issues:

• Machines with the T2 chips and MDM either always or often have Single User mode disabled.
• The SIP is enforced and impossible to disable, even in single user mode. Recovery mode is required because it boots off of a separate partition.

I suspected that the only options are to:

• Get our IT to update the MDM to use one of the ways of pre-loading the signatures into /var/db/SystemPolicyConfiguration/KextPolicy
• Wait for Oracle to get the kext files notarized.

Neither is desirable, but the bulk of our use of VirtualBox is for Docker, so we'll likely have to explore a port of our internal tools to Docker for Mac.

Sounds like you should be contacting those with admin privileges. I don't have any experience with the T2 but booting into SUM with T1 and prior is doable. Apple doesn't mention nor has updated their official support page to reflect that this can't be done with the T2 chip equipped computers and this chip controller has been released for quite some time.

​https://support.apple.com/en-us/HT201573

So, I would wager that booting into SUM has been disabled by your Sys Admins.

[Socratis]

UPDATE

Effective immediately (2019-05-23 18:00 UTC) the install of VirtualBox 6.0.8 and 5.2.30 should simply work on macOS 10.14.5.

Please give it a try...

[Robert Blair]

Replying to socratis:

UPDATE

Effective immediately (2019-05-23 18:00 UTC) the install of VirtualBox 6.0.8 and 5.2.30 should simply work on macOS 10.14.5.

Please give it a try...

Thanks for the update. I can confirm that the problem was resolved for me. I just tested a clean installation of 6.0.8 on macOS 10.14.5 and it was successful without the need for the previous workaround.

[myersjustinc]

Replying to socratis:

Effective immediately (2019-05-23 18:00 UTC) the install of VirtualBox 6.0.8 and 5.2.30 should simply work on macOS 10.14.5.

Will this fix be provided for future 6.x releases? Had a colleague run into this problem this week with VirtualBox 6.0.12r133076 on macOS 10.14.6.

He got himself unstuck with the provided Recovery Mode command, and I can have other people do that as needed in the future, but if there's a way to make that command unnecessary, it'd be very much appreciated.

[Socratis]

Replying to myersjustinc:

Will this fix be provided for future 6.x releases?

Yes, all released versions are now notarized.

Had a colleague run into this problem this week with VirtualBox 6.0.12r133076 on macOS 10.14.6.

Have your colleague open a new thread in the ​VirtualBox on Mac OS X Hosts section of the forums.

[justdave]

I just ran into this trying to upgrade to VirtualBox 6.1 on Mac OS X 10.15.2.

I have this resolved, but the installer still doesn't play friendly with it.

Note that you do NOT have to go into Recovery mode to fix this. You only need to go to the System Preferences -> Security & Privacy -> General and click the Allow button next to the prompt asking to approve extensions signed by Oracle Inc.

However, the Installer still handles this badly. Right now, it just says the install failed. Then you have to know to go look at the System Preferences and approve the extension. Then run the installer again and it succeeds.

The installer should instead prompt the user to go approve the extension in the system preferences after detecting that the extension failed to load (instead of immediately failing out). It should then wait for the user to come back and say they did so and test it again. Otherwise users aren't going to have any clue why the installation just fails unless they do a Google Search and find this ticket (which gives a lot of instructions they don't really need anymore).

Thanks for all your hard work!