Red Hat Bugzilla – Bug 1032018
"Booting in insecure mode" message delays start
Last modified: 2015-06-29 09:01:35 EDT
Created attachment 826028 [details]
shim message before grub appears
Description of problem:
With shim-0.7-1 (F20 TC1), I know see "Booting in insecure mode" message every time before grub appears. The message is displayed for a second or two (but it seems like eternity) and delays the boot unnecessarily.
If I turn SecureBoot on, the message is not displayed, and grub is displayed immediately (without any delay).
Also please have a look at the screenshot, the placement of the message is extremely weird. "B" starts at the end of the line. This happens on MSI board. On Mac Mini, the message is correctly placed (top left corner).
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. start the machine in UEFI mode with SecureBoot off
2. see the message for a second or two
3. see grub
Created attachment 826094 [details]
Clarify the difference between a system without secure boot and user-initiated insecure mode
This ought to fix that case.
(In reply to Matthew Garrett from comment #1)
> Created attachment 826094 [details]
> Clarify the difference between a system without secure boot and
> user-initiated insecure mode
> This ought to fix that case.
Lol - there is no difference. Kamil however is raising the fact that there is a very long delay for those of us who don't have secure boot in the bios.
The delay on my system is timed between 3 to 4 seconds. Even though the stall there should only be 2 seconds, it is sometimes longer than that (no idea why).
It is actually almost as long to get to the boot menu and select my OS than it is to boot my system to the login prompt.
My system boots in 2.4 seconds to the login prompt (3.4 if you take the resolution change on my screen into account)
I don't have secure boot, and I don't want to know about it quite frankly. Could this be coded to only display in user-initiated insecure mode, as this would be an obvious way to alert the user to the fact that they haven't enabled it in their bios...and for those of us who don't have secure boot enabled motherboards won't have to have that shoved in their face every time they reboot their machines :P
I have a SecureBoot-enabled motherboard, I have disabled SB intentionally, and I _don't want_ to see it every time I boot. It annoys me as hell to wait two more seconds before I can select my OS in the grub list.
So, I don't really know what the patch does, but please, don't punish me for having a modern hardware. Don't delay my boot.
(In reply to Kamil Páral from comment #3)
> I have a SecureBoot-enabled motherboard, I have disabled SB intentionally,
> and I _don't want_ to see it every time I boot. It annoys me as hell to wait
> two more seconds before I can select my OS in the grub list.
> So, I don't really know what the patch does, but please, don't punish me for
> having a modern hardware. Don't delay my boot.
Or as he said, for those who disable it for a reason...
Would it be possible to perhaps put a message in the menu, bottom right, or where ever, would be most appropriate, stating whether or not secure boot is enabled?
That way there would not be any need to delay the start for anyone for any reason.
I'm not sure if it's by design but in Fedora 20 the boot menu has not borders and no other text displaying, apart from the options for boot.
I like it whether it's intentional or not, but what I'm getting at is if text can be removed then text can be added, and an unobtrusive Notice down the bottom somewhere:
Notice: Secure boot not present, or enabled
Notice: Booting in Secure mode
Would be a much nicer option....
It's not intentional. That's why I posted a patch. If you think this needs to be a blocker, please nominate it as such.
Sorry my bad I didn't notice the patch there was already setting it as only display if set to user_insecure_mode
That solves my problem and it works well (already tested) - however it doesn't solve Kamil or others problem, where they're intentionally setting secure boot off, for whatever reason.....
I still think it would be much nicer for the booting secure unsecured message to display in the menu screen. Althought it's not a show stopper, it just makes more sense to me to do it that way.
On a side note:
So you're telling me that by default the borders (or white box around the menu) and grub title and version text at the top 'SHOULD' be displayed?
Becuase they don't on mine, it makes it look nicer in my opinion - perhaps you guys should keep it that way to differentiate between other distros a little.
The menu items start further up in the left corner, approximately where the white box top left corner would appear, and then it has the text down the bottom about e for editing etc.
It looks much nicer as a change. I haven't tried a background with it yet but I think it would look great without the box and grub text at the top.
Yes, it does solve Kamil's problem - it only displays the message if you've disabled signature validation with mokutil, not if you've disabled it in the firmware.
There should be no borders with current grub.
Thanks, Matthew. This is definitely not a blocker, it does not break any critical functionality and can be fixed later. I'm looking forward to a new shim update :-)
Created attachment 832790 [details]
Ah sweet - the patch made me think it was just setting it to only display when set to user_insecure_mode, but apparently not :)
Attached is a patched shim.efi you can try out Kamil - it works for me to get rid of the message...
(In reply to Peter from comment #9)
> Attached is a patched shim.efi you can try out Kamil - it works for me to
> get rid of the message...
Works perfectly, no message. Thanks.
Is there any progress on this? It really does ruin the user experience during boot
(In reply to James Lawrence from comment #11)
> Is there any progress on this? It really does ruin the user experience
> during boot
Have you tried applying the patch posted by Peter in comment #9? I replaced the shim.efi in /boot/efi/EFI/Fedora/ with that one and the insecure mode advice disappeared.
Matthew, this warning message ("Booting in insecure mode") started to appear on every Fedora 21 Live image, booted on an UEFI machine (secure boot off). F21 Alpha RC1 Live contains these packages (I have no idea why they are .fc20 packages):
I also started to see this problem on my F20 at home, so I guess an package containing the bug arrived as an update.
Can we please release a fixed version to F21 and F20? It has been almost a year...
I just hit this message when booting
Fedora-Live-Workstation-x86_64-21_Beta-4.iso on my Lenovo T440s, with my
firmware boot option set to "UEFI Only" (and Secure Boot disabled).
Although, it only takes a second or two once the message "Booting in
insecure mode" flashes by.
As reported earlier in this bug, once I enable Secure Boot, it goes away
and grub menu appears immediately.
This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora 'version'
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.
Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 20 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
Thank you for reporting this bug and we are sorry it could not be fixed.