My laptop came with 14.04 (Trusty Tahr) LTS. Since then, I have made no significant changes, and I have been applying updates whenever I was notified of them.

On 2016-07-15, I was applying updates as normal, or so I thought. The "Software Updater" pop-up window had got as far as "Configuring shim-signed", when I got this "Debconf" pop-up: Screenshot, whose contents are described at length in the accompanying text.

As you can see it:

  • says "Configuring Secure Boot" in large lettering
  • has a "Disable UEFI Secure Boot?" tick-box (check-box)
  • has a "Help" button
  • has a "Forward" button

I have never seen this before. I clicked on the "Help" button prior to taking the screenshot, which brought up the 3rd pop-up that you can see.

Help pop-up text

Just in case anyone searches by any of these phrases ...

Your system has UEFI Secure Boot enabled. UEFI Secure Boot is not compatible with the use of third-party drivers.

The system will assist you in disabling UEFI Secure Boot. To ensure that this change is being made by you as an authorized user, and not by an attacker, you must choose a password now and then use the same password after reboot to confirm the change.

If you choose to proceed but do not confirm the password upon reboot, Ubuntu will still be able to boot on your system but these third-party drivers will not be available for your hardware.

Subsequent Steps

If I remember correctly, ...

  • After a while I agreed to "Disable UEFI Secure Boot", and clicked the "Forward" button.
  • This took me directly to a window where I set up a password (entering it twice).
  • The update process finished in the normal manner, with a pop-up asking me when to restart.
  • I restarted soon after.
  • During the boot process, there was a blue screen saying something like "press any key to configure mok".
  • I pressed a key.
  • Instead of being asked to provide the password I had set up 5 minutes earlier, as I had been expecting, the laptop just quickly booted up in the normal way.
  • I logged in to Ubuntu as normal.
  • The Wi-Fi adapter wasn’t working.
  • I couldn't start VirtualBox VMs. The error was "Kernel driver not installed".
  • Various other problems.
  • I tried restarting again, more than once, but I never saw that blue "configure mok" screen again.
  • I noted that my current kernel was 3.19.0-65
  • So I restarted and used grub to select 3.19.0-64
  • Everything was working fine again.

My Research Notes

Note01 - I looked in my BIOS settings (for the first time on this laptop). Secure Boot appears to be enabled. If "Debconf" had been successful in disabling UEFI Secure Boot, would that have been reflected in the BIOS settings?

Note02 - My laptop is a Dell XPS 13, and other people are reporting problems with 3.19.0-65 on Dell hardware.

Note03 - The update instructions for USN-3037-1 say to upgrade to 3.19.0-65. The final paragraph is:

ATTENTION: Due to an unavoidable ABI change the kernel updates have been given a new version number, which requires you to recompile and reinstall all third party kernel modules you might have installed. Unless you manually uninstalled the standard kernel metapackages (e.g. linux-generic, linux-generic-lts-RELEASE, linux-virtual, linux-powerpc), a standard system upgrade will automatically perform this as well.

(I am just a user and I don't really understand this. Don't we always get a new version number? And don't we always have to recompile & reinstall - a process managed by DKMS or something?)

Note04 - The changelog for 3.19.0-65.73 has lots of UEFI issues, including changes affecting EFI_SECURE_BOOT_SIG_ENFORCE and CONFIG_EFI_SECURE_BOOT_SIG_ENFORCE

Note05 - Because my kernel version is 3.19, I assume I must be on the trusty linux-lts-vivid LTS enablement stack (??), as per the table here, where 3.19.0-65.73 is currently the latest entry.

Note06 - It seems that someone who is on the trusty linux-lts-wily LTS enablement stack (kernel version 4.2) may have got the same pop-ups, the day before me, but without encountering any subsequent problems.

Note07 - There is an answer from April 2016 which says:

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.

Could it be that now, in July 2016, Ubuntu has introduced new Secure Boot requirements to 14.04 LTS? If not, what is the problem I'm having with 3.19.0-65? And either way, what should I (and the other people having problems) do about it?


  • 1
    +1 Just for the amount of work and info you have put into this question. Step by step instructions of everything that happened. This is how a good question should look like in my opinion.
    – Parto
    Jul 17, 2016 at 10:12
  • 1
    I'm that other person (note 6). This boils down to a three way choice: turn off secure boot (fairly easy), lose 3rd party driver functionality (unacceptable), or sign the drivers yourself (super complicated). The system attempted to help you turn off secure boot but it didn't work in your case...it did in mine. Jul 17, 2016 at 11:45

2 Answers 2


You are correct. The Canonical Kernel Team has enabled EFI_SECURE_BOOT_SIG_ENFORCE in the new 3.19 Ubuntu kernel.

That prevents from loading unsigned 3rd party kernel modules.

It looks like there is a script with GUI that is supposed to help to disable Secure Boot.

It did not work in your case. It depends on specific UEFI implementation in your computer.

But you can simply disable Secure Boot in your UEFI settings.

See this answer and comments below.

  • Thanks. The linked answer mentions "mokutil --disable-validation" as an option. Is it worth me trying that first? Or signing the modules myself? (Or is it something that I have to research and decide for myself; how much benefit I get from keeping Secure Boot enabled?)
    – Peter Ford
    Jul 17, 2016 at 20:23
  • The easiest way is to disable Secure Boot and leave it disabled. There is no benefit in that stupid Microsoft Secure Boot feature.
    – Pilot6
    Jul 17, 2016 at 20:43
  • Disabling Secure Boot is also Dell's recommended solution: en.community.dell.com/techcenter/os-applications/f/4613/p/… I'll come back and post here when I've tried it.
    – Peter Ford
    Jul 19, 2016 at 0:32

You can also disable Secure Boot running sudo update-secureboot-policy. This wiki page explains this method.

  • Thanks. That wiki page also seems to be the closest I've seen to an official confirmation that the answer to my question is "yes, deliberately". I guess "update-secureboot-policy" was executed on my machine as part of the update process, resulting in the experience I described in my question. And for some reason it failed to disable Secure Boot, and wasn't able to handle that failure or explain to me the situation.
    – Peter Ford
    Aug 5, 2016 at 17:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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