shim prints "Booting in insecure mode" when booting without SecureBoot enabled

[Steve Langasek]

shim 0.7 has an unfortunate bug where when booting with SecureBoot disabled (i.e., in setup mode), it will print the message "Booting in insecure mode" and pause for two seconds before booting.

This has been corrected upstream in commit d95b24bd02cf41cca9adebd95f10609d6424d2b3, which postdates 0.7. We will include this fix in the next upload of shim (dependent on a Microsoft round-trip for signing).

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Mark Rich (sir-marky)]

I have secure boot enabled on my machines and this happens on boot anyway.
Are you sure it only applies to disabled secure boot?

[Steve Langasek (vorlon)]

On Fri, Oct 24, 2014 at 07:54:18AM -0000, Mark Rich wrote:
> I have secure boot enabled on my machines and this happens on boot anyway.
> Are you sure it only applies to disabled secure boot?

I can confirm that in testing on systems which have secure boot enabled, this
message+delay is not seen (or else we would have caught it earlier). Are
you sure you have secure boot enabled?

[Franck (alci)]

I also have secure boot enabled, and I also get this message.
However, I am using linux-lowlatency, which might not be signed. Could this explain the message ? (and subsidiary question, why is there no signed lowlatency kernel ?)

[md_5 (md-5)]

After my latest apt-get upgrade I have this issue. Did not have it in 13.10, 14.04 and the release version of 14.10

[John Lenton (chipaca)]

Just saw this for the first time booting 15.04 today. Not sure if it's been happening all the time and I haven't seen it, or if it's new (the screen does not come up reliably enough for me to see this every time).

[Tażdin Amietszajew (tazdinamietszajew)]

Any updates on this?
I also have the issue with newest kernel of 14.10 - with SecureBoot enabled still getting the message.

[Arda Ünlü (betseg)]

I have secureboot disabled but this happens.

[Prateek Saraswat (kylekartan)]

I am getting the same error message. It started when I upgraded to 15.04 from 14.07

[Phil Ferrar (phil-ferrar)]

Any Help,
Is there any way someone can post [or direct users to] a simple response to this issue. My experience is that although I've upgraded to 15.04 o.k. and seem to be working properly, I have issues [like I'm unable to boot from a Live-DVD] and have read things online about having to 'short out' contacts on the laptop's processor ? Will the situation resolve itself over time or are we stuck with hardware that has been 'fried' [or whatever the term] such that we can not regain control of BIOS / UEFI etc.
Thanks,
Phil

[valerio (passini-valerio)]

In my setup, Asus Vivo PC vc60 dual boot with Windows 8.1, I have met this problem since I upgraded kubuntu from 14.04 to 15.04. Today I have tried to play with shim package and UEFI settings, finally I got rid of the message. I have done a lot of things, so this protocol might be redundant or wrong in some part, but you can try if you wish so. Uninstalling shim doesn't change anything in the boot message. so I went to UEFI options:
- Changing the UEFI settings seems to work in this way: Secure Boot -> Windows UEFI enabled + Key Management -> Clear secure boot keys
- Pay attention that the UEFI chooses the right boot loader order in Boot option priorities: there are two options to boot Ubuntu (they are grub related options) and I have experimented both, plus some options to boot directly into Windows (I suppose you are not considering these).
- I reinstalled shim and updated grub, after that no more insecure Boot message.
System can boot in kubuntu (my custom packaged 4.0.4 kernel and the 3.19.0 stock kernel) and in W8.1 without warnings and wasting time.

[Dave F (commercial-e)]

My system has been flakey since 15.04 and that's after a long drawn out fight... I tried using Boot Repair to see if that would fix the 'insecure' thing but it didn't. I was really sure to uncheck the secure boot option (it's off in UEFI settings). I thought I had removed £€%\£!!!!! Shim.

What it did do was attempted murder on my windows partition. Now when I select Windows from the GRUB menu I get:

-------

Shim UEFI Key management

Continue boot

Enroll key from disk

-------

etc., etc..

Fortunately I can get to Windows via my MB boot menu on the semi-rare occasions that I need it but it's still a pain.

It would be nice if someone could really really deal with the secure boot issue once and for all... seriously, how many people want it other than whoever coded it in there?

[Steve Langasek (vorlon)]

This bug report is about a spurious message being displayed on boot telling users that the system is "Booting in insecure mode" when no message should be displayed.

This bug report is *not* about any problems anyone is experiencing being able to boot Ubuntu.

If you are having any problems booting Ubuntu, please file a separate bug report.

[Launchpad Janitor (janitor)]

This bug was fixed in the package shim - 0.8-0ubuntu2

---------------
shim (0.8-0ubuntu2) wily; urgency=medium

  * No-change rebuild against gnu-efi 3.0v-5ubuntu1.

shim (0.8-0ubuntu1) wily; urgency=medium

  * New upstream release.
    - Clarify meaning of insecure_mode. (LP: #1384973)
  * debian/patches/CVE-2014-3675.patch, debian/patches/CVE-2014-3677.patch,
    debian/patches/0001-Update-openssl-to-0.9.8za.patch: dropped, included
    in the upstream release.
  * debian/patches/sbsigntool-not-pesign,debian/patches/second-stage-path:
    refreshed.

 -- Steve Langasek <email address hidden> Tue, 12 May 2015 17:48:30 +0000

[Luca Ciavatta (cialu)]

I have installed Ubuntu 15.04 on a MacBook Pro with EFI boot partition and I get "Booting in insecure mode" message at every boot.

[Ubuntu Foundations Team Bug Bot (crichton)]

As a part of the Stable Release Updates quality process a search for Launchpad bug reports using the version of shim from trusty-proposed was performed and bug 1489987 was found. Please investigate this bug report to ensure that a regression will not be created by this SRU. In the event that this is not a regression remove the "verification-failed" tag from this bug report and tag 1489987 "bot-stop-nagging". Thanks!

[Steve Langasek (vorlon)]

Bug #1489987 is most likely user error (upgrading to shim in trusty-proposed before a corresponding version of shim-signed was available). It is not a regression caused by this SRU.

[Ubuntu Foundations Team Bug Bot (crichton)]

As a part of the Stable Release Updates quality process a search for Launchpad bug reports using the version of shim from trusty-proposed was performed and bug 1489987 was found. Please investigate this bug report to ensure that a regression will not be created by this SRU. In the event that this is not a regression remove the "verification-failed" tag from this bug report and tag 1489987 "bot-stop-nagging". Thanks!

[Steve Langasek (vorlon)]

This bug is not present in precise or vivid. It's only present in shim 0.7 or later.

[Launchpad Janitor (janitor)]

This bug was fixed in the package shim - 0.8-0ubuntu2

---------------
shim (0.8-0ubuntu2) wily; urgency=medium

  * No-change rebuild against gnu-efi 3.0v-5ubuntu1.

shim (0.8-0ubuntu1) wily; urgency=medium

  * New upstream release.
    - Clarify meaning of insecure_mode. (LP: #1384973)
  * debian/patches/CVE-2014-3675.patch, debian/patches/CVE-2014-3677.patch,
    debian/patches/0001-Update-openssl-to-0.9.8za.patch: dropped, included
    in the upstream release.
  * debian/patches/sbsigntool-not-pesign,debian/patches/second-stage-path:
    refreshed.

 -- Steve Langasek <email address hidden> Tue, 12 May 2015 17:48:30 +0000

[Steve Langasek (vorlon)]

This bug is not present in precise or trusty. It's only present in shim 0.7 or later.

For vivid I have verified that the updated SRU version fixes this bug.

[Andreas Brudin (andreas-brudin)]

I did a fresh install of 16.04, and experienced the same behavior as is described here: http://askubuntu.com/questions/761864/ubuntu-16-04-booting-in-insecure-mode-message-even-when-turned-off-manually-in

So, now secure boot is turned off, but I still have the delayed startup process and the annoying message everytime I boot.

[Mark (mark-delta-echo)]

I triggered this situation when trying to install a proprietary NVIDIA driver. This driver cannot be loaded into the kernel. First must its key being registered in the bios. During install of the driver I'm asked to switch off UEFI secure boot and then reboot. On reboot a blue screen appears with MOK management. The process is failing, the driver is not installed correctly and also brings this problem with "Booting in insecure mode".
As I understand there is a fix for this problem in Ubuntu Trusty.
I have 14.04 Trusty and still seem to have this problem

#get --installed list | grep shim Tells me:

shim/trusty-updates,now 0.8-0ubuntu2 amd64 [installed,automatic]
shim-signed/trusty-updates,now 1.17~14.04.1+0.8-0ubuntu2 amd64 [installed]
systemd-shim/trusty,now 6-2bzr1 amd64 [installed,automatic]

so > 0.7
Do I have the fixed version? And what must I do to let the change have effect?
Thanks in advance.

[Steve Langasek (vorlon)]

On Fri, Jul 22, 2016 at 08:58:53PM -0000, Mark wrote:
> I triggered this situation when trying to install a proprietary NVIDIA
> driver. This driver cannot be loaded into the kernel. First must its key
> being registered in the bios. During install of the driver I'm asked to
> switch off UEFI secure boot and then reboot. On reboot a blue screen
> appears with MOK management. The process is failing, the driver is not
> installed correctly and also brings this problem with "Booting in insecure
> mode".

This bug was about shim printing a warning about booting in insecure mode
when SecureBoot was not enabled in your firmware. That is not why you are
seeing this message. You are seeing this message because *you have
configured your system to boot in insecure mode*, overriding SecureBoot in
MOK, which is a prerequisite for newer kernels to load unsigned modules
(such as the nvidia driver).

If you are seeing this message on boot, *and* the nvidia driver is not
loading for you, then there is a bug somewhere other than shim and you
should file a new bug report about this.