Virutalbox fails to install on MacOS 10.13.5

[jav]

Virtualbox fails to install without any obvious explanation except this part of the logs:

error	18:32:10.563277 +0200	syspolicyd	Kernel Extension BLOCKED: <private>
default	18:32:10.563624 +0200	kextd	Kext rejected due to system policy: <OSKext 0x7f9b8a0dadb0 [0x7fffad793af0]> { URL = "file:///Library/StagedExtensions/Library/Application%20Support/VirtualBox/VBoxDrv.kext/", ID = "org.virtualbox.kext.VBoxDrv" }
default	18:32:10.563667 +0200	kextd	org.virtualbox.kext.VBoxDrv failed security checks; failing.

It was also tested with VirtualBox-5.2.97-122902-OSX

[jav]

To be able to install the process is :

• install virtual box until the failure message appears
• start the preference / security & privacy
• accept the changes requested by oracle
• reinstall Virtualbox.

That would be great to mention that it on the error message.

[Socratis]

Replying to jav:

That would be great to mention that it on the error message.

Apple is supposed to do that, and it does, but now always. The error message is not a VirtualBox error message, it's an Apple installer error message. Open a ticket with Apple.

This ticket can be Closed.

[TGOS]

Replying to socratis:

Apple is supposed to do that,

No, you are supposed to do that. Apple will only say that your postflight script fails if it just returns with an error code.

This page explicitly says that you are supposed to display an error and not make the installer fail:

​https://developer.apple.com/library/archive/technotes/tn2459/_index.html

Please stop making the false claim that this is not your fault and people shall talk to Apple. I asked Apple and they said it IS your fault. Your installer script should not fail because it cannot load the KEXTs. Instead your app binary should be testing if the kernel extensions are loaded at start, if not prompt the user for admin privileges to load them and if that fails with exit code 27, display instructions to the user how to solve it.

Alternatively you could display an error message directly in the postfligth script but then you need to take care of localization. Here, run this in Terminal:

osascript -e "display dialog \"The kernel extensions could not be loaded as you need to first authorize them. Therefor please go to ...., then hit try again\" buttons {\"Try again\", \"Abort\"}"

The call blocks until the user presses a button. The pressed button can be captured in the script and the script can react to it. In case of cancel it can fail with an error as you do now (but then the user will at least know WHY it is failing), in case of "Try again" you just try again to load the KEXT and show the same dialog if it fails again with exit code 27.

I'll attach a runable sample showing this in action.

[TGOS]

Sample showing how you can display UI in post... scripts

[Socratis]

Replying to TGOS:

The call blocks until the user presses a button. The pressed button can be captured in the script and the script can react to it. In case of cancel it can fail with an error as you do now (but then the user will at least know WHY it is failing), in case of "Try again" you just try again to load the KEXT and show the same dialog if it fails again with exit code 27.

I'll attach a runable sample showing this in action.

@TGOS

Could you post a comment that your sample code is released under the MIT license?

[Klaus Espenlaub]

I wouldn't be worried about the license of the sample, it's not meant to be integrated in any direct meaning of the word. We'd need to write quite a bit of code ourselves anyway, and the valuable hint is "osascript". Something we didn't think of. Many thanks.

However, it seems to be consensus that UI interaction by the installer scripts is frowned upon (see e.g. ​Packaging Guidelines for macOS), because they cause trouble with non-interactive installs. I don't want to use this as an excuse to not doing it, but there seems to be absolutely no way to tell if the install is a graphical one or started with the 'installer' CLI tool. If I simply missed the information in my half a day of search engine use, please tell me.

[Socratis]

There's no way (that I can think of) that approving and installing a kext from a known developer for the first time, is not going to be interactive. You have to click on that "Approve XYZ" button.

May I remind you of a case where a user was trying to approve Oracle, but was doing it over RDP, and the specific button was not clickable? On purpose? See: ​https://twitter.com/felix_schwarz/status/908690187219283970

Not even "interactive" would work, you had to physically be there... :/

So, I don't see anything wrong with using UI interaction to solve this, since there's no way (on this side of the Universe) that Apple will allow you to run a script and approve-install a kext, there's no "non-interactive" installation. That would defeat their whole logic.