This issue happens only on UEFI systems with enabled Secure Boot.

When I try to install DKMS modules like VirtualBox, Nvidia, or Broadcom drivers, they do not install and I get Required key not available when I try to modprobe them.

VirtualBox complains that vboxdrv is not loaded.

Broadcom wl driver is shown in lspci -k as a kernel module but is not in use. sudo modprobe wl throws Required key not available.

Also this issue may happen when I install some kernel modules from git sources.

This issue may appear after a kernel update as disabled wireless adapter, black screen after a reboot, etc.

How can I fix it?


Since Ubuntu kernel 4.4.0-20 the EFI_SECURE_BOOT_SIG_ENFORCE kernel config has been enabled. That prevents from loading unsigned third party modules if UEFI Secure Boot is enabled.

The easiest way to fix this issue is to disable Secure Boot in UEFI (BIOS) settings.

In most cases you can get into UEFI settings using grub menu. Press ESC button on booting, get into grub menu and select System Setup. Secure Boot option should be in "Security" or "Boot" section of the UEFI.

You can get into UEFI directly, but it depends on your hardware. Read your computer manual to see how to get there. It may be Del, or F2 on boot, or something else.

An alternative way is to disable Secure Boot using mokutil.

Since Ubuntu kernel build 4.4.0-21.37 this can be fixed by running

sudo apt install mokutil
sudo mokutil --disable-validation

It will require to create a password. The password should be at least 8 characters long. After you reboot, UEFI will ask if you want to change security settings. Choose "Yes".

Then you will be asked to enter the previously created password. Some UEFI firmware asks not for the full password, but to enter some characters of it, like 1st, 3rd, etc. Be careful. Some people do not understand this. I did not get it from the first attempt either ;-)

Update: Now this kernel config is enabled in all supported Ubuntu kernels. Ubuntu 16.04, 15.10 and 14.04 are affected.

  • This doesn't work for me. @Sputnik answer does. But still, I'd like to know why mokutil is asking me for a password and when do I need it? Apr 28 '16 at 19:49
  • 9
    @AlwinKesler It asks for a password which it will validate after reboot, before the changes to the MOK database are actually carried out. Without this, a rogue process could change keys in the MOK database which become effective after the next reboot. Also, now the platform 'knows' that the person requesting the change is the same person who is physically present after the reboot, and will thus have passed hardware security measures, such as having physical access to the machine and knowing the boot time system password.
    – zwets
    May 9 '16 at 8:44
  • @Pilot6: I am still on Ubuntu 14.04 LTS due to some technical issues. Thanks a lot for updating the answer.
    – Ravi Joshi
    Jul 22 '16 at 15:37
  • 3
    Worked for me on Ubuntu 18.04. Couldn't figure out for the life of me why installing nvidia drivers wasn't working via any means, or even by reverting to 16.04. Gah! This fixed it. So much time wasted.
    – Nate
    Jul 12 '18 at 5:09
  • 1
    My Ubuntu system was really laggy. Made no sense since this was a brand new laptop. Now I realize the CPU was doing everything and my video card was sitting idle the whole time. This link also helped - linuxbabe.com/ubuntu/install-nvidia-driver-ubuntu-18-04 Jan 23 '19 at 5:21

As suggested by user @zwets, I'm copying (with edits) an answer here:

Since kernel version 4.4.0-20, it was enforced that unsigned kernel modules will not be allowed to run with Secure Boot enabled. If you'd want to keep Secure Boot and also run these modules, then the next logical step is to sign those modules.

So let's try it.

  1. Create signing keys

    openssl req -new -x509 -newkey rsa:2048 -keyout MOK.priv -outform DER -out MOK.der -nodes -days 36500 -subj "/CN=Descriptive name/"
  2. Sign the module

    sudo /usr/src/linux-headers-$(uname -r)/scripts/sign-file sha256 ./MOK.priv ./MOK.der /path/to/module

Note 1: There can be multiple files to be signed for a single driver/module, so /path/to/module may need to be replaced with $(modinfo -n <modulename>), e.g. $(modinfo -n vboxdrv)

Note 2: sudo kmodsign sha512 ./MOK.priv ./MOK.der /path/to/module is an alternative if sign-file is not available.

  1. Register the keys to Secure Boot

    sudo mokutil --import MOK.der

    Supply a password for later use after reboot

  2. Reboot and follow instructions to Enroll MOK (Machine Owner Key). Here's a sample with pictures. The system will reboot one more time.

If the key has been enrolled properly, it will show up under sudo mokutil --list-enrolled.

Please let me know if your modules would run this way on Ubuntu 16.04 (on kernel 4.4.0-21, I believe).

Resources: Detailed website article for Fedora and Ubuntu implementation of module signing. (they've been working on it) ;-)

Additional resource: I created a bash script for my own use every time virtualbox-dkms upgrades and thus overwrites the signed modules. Check out my vboxsign originally on GitHub.

Additional note for the security (extra-)conscious: ;-)

Since the private key you created (MOK.priv in this example) can be used by anyone who can have access to it, it is good practice to keep it secure. You may chmod it, encrypt (gpg) it, or store it somewhere else safe(r). Or, as noted in this comment, remove the option -nodes in step number 1. This will encrypt the key with a passphrase.

  • On Ubuntu 14.10 I continued to see 'required key not available' trying to install a broadcom driver compiled from source, despite preregistering the key and signing the driver. Disabling validation worked.
    – Mark
    Jul 16 '16 at 0:37
  • 1
    This worked for me for VirtualBox and Ubuntu 16.04.
    – YtvwlD
    Aug 4 '16 at 11:18
  • 1
    I get the following error in step 3: "EFI variables are not supported on this system". "dmesg" has no efi entries ("dmesg | grep efi" has no results) What else can I do? Thanks
    – musbach
    Jan 7 '17 at 15:55
  • You can substitute the path in with $(modinfo -n modulename)
    – Shane
    Aug 7 '17 at 1:56
  • On Ubuntu 18.04 here, insmod for talpa_syscallhook.ko module continues saying "Required key not available" despite I have signed that module, and all other modules in the same directory for the Sophos AV just in case. The key has been successfully registered as I can see it when I list all mok keys. Any ideas on how to proceed? Mar 15 '19 at 9:36

You can disable Secure Boot (UEFI) in the BIOS with the following steps:

  1. Reboot your machine and enter the BIOS Menu (In my case pressing F2)

  2. Search for Secure Boot and change to Legacy

In an ASUS motherboard:

  • Go to the Advanced Mode (F7)
  • Go in the Secure Boot option under the Boot section
  • Change "Windows UEFI mode" with "Other OS"
  • Save and restart to apply settings (F10)
  • 2
    Secure Boot and "Legacy" are different settings.
    – Pilot6
    Aug 12 '16 at 10:53
  • But if you have "legacy boot" enabled instead of UEFI, does that entail that Secure Boot is not enabled? Jan 9 '17 at 15:26
  • @Supernormal, yes, this is what I understand.
    – Sputnik
    Nov 17 '17 at 11:22
  • IMHO the best way to deal with this - if you need to be able to load 3rd party kmods - is to build a stock kernel, using your distros /boot/config-* file for the initial .config. Alternatively, rebuild the distro kernel but remove all the patches that deal with mok and kernel lockdown.
    – RJVB
    Aug 8 '20 at 8:25
  • Just to put my previous comment into context: I had reasons to build a recent kernel from Debian Buster (undoubtedly used by Ubuntu too) and discovered I couldn't load my ZFS kmods DESPITE SECURE BOOT BEING DISABLED. Must be because I did NOT use the corresponding config for my build. Or else because not everything required to build a fully functional kernel is provided. To think I'm moving to Linux because of the SIP mess in Darwin...
    – RJVB
    Aug 8 '20 at 8:29

You can also Disable Secure Boot in shim-signed running sudo update-secureboot-policy. This wiki page explains this method:

  • Open a terminal (Ctrl + Alt + T), and execute sudo update-secureboot-policy and then select Yes.
  • Enter a temporary password between 8 to 16 digits. (For example, 12345678, we will use this password later
  • Enter the same password again to confirm.
  • Reboot the system and press any key when you see the blue screen (MOK management
  • Select Change Secure Boot state
  • Enter the password you had selected in Step 2 and press Enter.
  • Select Yes to disable Secure Boot in shim-signed.
  • Press Enter key to finish the whole procedure.

You can still enable Secure Boot in shim-signed again. Just execute

sudo update-secureboot-policy --enable and then follow the steps above


Not the answer you're looking for? Browse other questions tagged or ask your own question.