VirtualBox Kernel driver not installed

VirtualBox doesn’t run virtual machines on Fedora and Ubuntu when secure boot is enabled.  Secure boot requires the virtual box modules to be signed.

Kernel driver not installed (rc=-1908)

The VirtualBox Linux kernel driver (vboxdrv) is probably not loaded.You may not have kernel driver installed for kernel that is runnig, if so you may do as root: dnf install akmod-VirtualBox kernel-devel-$(uname -r)If you installed VirtualBox packages and don’t want reboot the system, you may need load the kernel driver, doing as root: akmods; systemctl restart systemd-modules-load.service

where: suplibOsInit what: 3 VERR_VM_DRIVER_NOT_INSTALLED (-1908) – The support driver is not installed. On linux, open returned ENOENT

To test whether or not this really is the problem, run modprobe. Modprobe is used to load a single module, a stack of dependent modules, or all modules that are marked with a specified tag.

erawanu@localhost:$ sudo modprobe -v vboxdrv
insmod /lib/modules/3.15.8-200.fc20.x86_64/extra/vboxdrv.ko
modprobe: ERROR: could not insert 'vboxdrv': Required key not available

Secure boot is a process that validates firmware images on devices before they are allowed to execute. Starting with a root of trust (consisting of the hash of a key that is provisioned in firmware during manufacturing), secure boot cryptographically validates the digital signature of all boot components, from the pre-UEFI boot loaders, to the UEFI environment, and finally to the main OS and all components that run in it (such as drivers and apps). Secure boot helps to ensure that only authorized code can execute before the operating system loads. Found this information here

UEFI keys and openssl
The UEFI specification has several possible key types, but X509 is the most useful to us, since it’s the easiest to generate with openssl (The platform key is required to be X509 anyway). Note that when the UEFI spec says “key”, it doesn’t mean the same as an openssl key. In UEFI parlance, the “key” or “public key” means the public part (i.e. the X509 certificate); openssl uses the term key to mean the private key used to sign stuff with.

All keys (PK, and X509 keys in KEK and db) should be X509 CA keys (i.e. self signed). The reason for this is that the platform will verify a key back to its root of trust. It is possible to provision a signature chain going back to the root of trust, but it’s not easy, so starting with self signed CA certificates is easiest. Note that from the CA, you can issue signing keys, but those keys cannot themselves then be used to create subordinate signing keys because the intermediate trust certificate will be missing from the signing chain. I found this information here and they refer to this site.

Creating UEFI CA keys

The easiest way is to use the x509 CA creation command

openssl req -new -x509 -newkey rsa:2048 -keyout PK.key -outform DER -out PK.der -nodes -days <length> -subj “/CN=<my common name>/”

This command will create PK.der, which is the public certificate and PK.key which is the private signing key. The UEFI spec mandates that all X509 keys be 2048 bit rsa keys and the format needs to be “der”. Fill in <days> with how long you want the certificate to be valid for and <my common name> with whatever information you want the common name to be (UEFI doesn’t use this, but it’s customary for every X509 certificate to have at least a common name).

[root@localhost ~]# openssl req -new -x509 -newkey rsa:2048 -keyout privatekey.keyout -outform DER -out privatekey.der -nodes -days 36500 -subj "/CN=MyCommonName/"

After the key is generated, it needs to be imported in the MOK manager. (Module Owned Key). This can be done with the mokutil command. Have a new password ready, because the import requires it. You will need the password while rebooting.

[root@localhost ~]# mokutil --import privatekey.der

To continue a reboot is necessary. After the reboot a blue MOK manager screen will appear. Choose “enroll MOK”, continue and type the password for the key. After booting is finished the virtual box modules need to be signed with the key.

The virtual box kernel modules in Fedora a locates in


Sign all the modules (vboxdrv, vboxguest, vboxnetadp, vboxnetflt, vboxpci, vboxsf, vboxvideo) in this folder with this command:

[root@localhost ~]# /usr/src/kernels/$(uname -r)/scripts/sign-file sha256 privatekey.keyout privatekey.der $(modinfo -n vboxdrv)

I couldn’t find out if it is really necessary to sign all these modules. I just did it…

Reboot and try


2 thoughts on “VirtualBox Kernel driver not installed

  1. Though this worked, it also seemed to disable networking entirely (can’t even use usb tethering with my phone) and broke some extensions.

    Liked by 1 person

    1. Dear Ross, i faced this problem some years ago and later due to circumstances (read work requirements) i needed to stop working with Fedora. This was a very sad day in my life. I can’r help you with the networking. Do you advice me to take this post offline? I am very sorry for any inconvenience.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s