When installing 16.04, I was asked to turn off "Secure Boot" if I wanted to install 3rd party modules/drivers.

I did not comply.

And when I installed manually the only 3rd party drivers I use (bcmwl-kernel-source), I was asked again (during the installation of the package) to turn off "Secure Boot".

Using bcmwl-kernel-source was perfectly fine with Secure Boot in 15.10. This does not seem to be related to a bug to me.

So this does look like Ubuntu refuse to sign anymore the 3rd party drivers/modules to make it work (??) with "Secure Boot". Or seem to consider 3rd party modules as insecure and breaking "Secure Boot" hence inforcing to disable it to make it clear ?? Am I right ?

  • 6
    Well, IMO, it is because people (falsely) assume the secure boot will break 3rd party modules when giving advice. Technical information on secure boot is here - wiki.ubuntu.com/SecurityTeam/SecureBoot . Personally I disagree with the seeming ubiquitous advice to trun off secure boot, works just fine on my hardware with secure boot enabled. IMO leave secure boot enabled unless you have a problem with it, no reason to blindly disable security features.
    – Panther
    Commented Apr 8, 2016 at 15:01
  • 8
    I haven't looked into this in depth, but as I understand it, 16.04 is moving to a stricter Secure Boot enforcement than 15.10 and earlier versions used. Specifically, in 15.10 and earlier, once Shim launches GRUB, GRUB will launch any Linux kernel; the Secure Boot protections end with GRUB. My understanding is that with 16.04, Secure Boot policy enforcement extends to the kernel, so Ubuntu's GRUB will no longer launch unsigned kernels. If it goes beyond that, then unsigned kernel modules will also be affected, when they weren't before. Again, though, I haven't studied this in depth.
    – Rod Smith
    Commented Apr 9, 2016 at 14:22
  • 1
    Some good background: bugs.launchpad.net/ubuntu/+source/grub2/+bug/1401532
    – dpb
    Commented Apr 10, 2016 at 22:19
  • 1
    With people messing with their systems in an attempt to install third party modules, I'm left wondering if this feature isn't going to do more harm than good.
    – Daniel
    Commented Jul 17, 2016 at 14:44
  • Is there anyway to re-enable it after having turned it off?
    – shaunakde
    Commented Sep 30, 2016 at 13:55

4 Answers 4


This is not a bug, it is a feature.

As Anthony Wong says, when you install a DKMS package you are compiling the package yourself, thus, Canonical cannot sign the module for you.

However, you can definitely use Secure Boot, however this is exactly the use case where Secure Boot is trying to protect you from yourself because it cannot know whether you trust a module or don't.

By default, there is a Platform Key (PK) on your UEFI machine, which is the ultimately trusted Certificate Authority for loading code in your processor.

GRUB, or shim, or other boot mechanisms can be digitally signed by a KEK which is trusted by the root CA (PK), and thus your computer can, without any configuration, boot software like Ubuntu Live USB/DVDs.

On Ubuntu 16.04 the kernel is built with CONFIG_MODULE_SIG_FORCE=1, which means that the kernel will enforce modules to be signed by a trusted key in the platform. Take into consideration that the UEFI platform by default contains a PK that you do not have any control over, and thus you cannot sign binaries with a key recognized by your own machine.

Some people bash and rant against that, but there is really no better way (from a security standpoint) than it being yourself who enrolls the new key you want.

If your boot system uses shim, you can use something called a Machine Owner's Key database, and enroll your key as a MOK (You can do that with mokutil). If you don't, you can also enroll your key in the UEFI database as a signing key.

After you enroll your key, you can sign your DKMS-built package with your MOK (there should be a perl script at /usr/src/kernels/$(uname -r)/scripts/sign-file), and after it is signed, you can load it into the kernel.

Granted, someone should make more visual instructions on this, and probably even make a wizard or a better DKMS standard to allow keys to be taken into consideration, but this is what we have as of now.

You can refer to this explanation on how to sign your own kernel modules: https://askubuntu.com/a/768310/12049

  • 1
    I disabled it, and now I get an annoying "booting in insecure mode message" Is there anyway to undo this? I cant seem to even explain the issue on the forums here. @ssice -- I am using UBUNTU 14.04 so I do not think this is even relevant to me. [
    – shaunakde
    Commented Sep 30, 2016 at 14:18

In short, this is not a bug but a new change introduced in 16.04.

Because what you are installing is a dkms package. DKMS modules are compiled on your own machine and so Canonical can't sign the module for you. If Canonical cannot sign it, there is no way to digitally verify it. If you have secure boot turned on, that will mean your module can't be used, and in order to use it, you will have to turn off secure boot, that's why you are getting asked by the question.

For why it only happens in 16.04 but not in previous releases, Rod Smith has given a good answer. In Ubuntu 16.04, Ubuntu starts to enforce secure boot to the kernel level. Before 16.04, Ubuntu does not really enforce you to use signed kernel and signed kernel modules, even you have secure boot turned on. But this is no longer the case in 16.04.

This is the related bug: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1401532

This is the related blueprint: https://blueprints.launchpad.net/ubuntu/+spec/foundations-x-installing-unsigned-secureboot

  • I could still load the wl module with 16.04 beta2 and after update. But now with the release I got an error "modprobe: ERROR: could not insert 'wl': Required key not available"
    – solsTiCe
    Commented Apr 23, 2016 at 11:09
  • Can you try running: sudo apt install mokutil; sudo mokutil --disable-validation Commented Apr 26, 2016 at 2:54

Another way to do it is to create your own key, insert the public part into the MOK database and sign the modules you compile with the private part. Look here for detailed info: Could not load 'vboxdrv' after upgrade to Ubuntu 16.04 (and I want to keep secure boot)


The accepted answer is very complete, but I'd like to add this simple piece of information, taken from here:


Basically secure boot may prevent you from loading some driver you installed which can be quite frustrating. I have been through this myself: the driver installed correctly, everything seemed to be good to go, but it just didn't work. Took me some time to find it was secure boot's preventing the OS from loading it.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .