Bug 1032018 - "Booting in insecure mode" message delays start
Summary: "Booting in insecure mode" message delays start
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: shim
Version: 20
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Matthew Garrett
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-11-19 11:44 UTC by Kamil Páral
Modified: 2023-09-14 01:53 UTC (History)
9 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2015-06-29 13:01:35 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
shim message before grub appears (181.94 KB, image/jpeg)
2013-11-19 11:44 UTC, Kamil Páral
no flags Details
Clarify the difference between a system without secure boot and user-initiated insecure mode (1.42 KB, patch)
2013-11-19 15:07 UTC, Matthew Garrett
no flags Details | Diff
patched shim.efi (1.32 MB, application/x-ms-dos-executable)
2013-12-04 17:33 UTC, Peter
no flags Details

Description Kamil Páral 2013-11-19 11:44:49 UTC
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):
shim-0.7-1.fc20.x86_64
grub2-2.00-25.fc20.x86_64
grub2-efi-2.00-25.fc20.x86_64

How reproducible:
always

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

Comment 1 Matthew Garrett 2013-11-19 15:07:48 UTC
Created attachment 826094 [details]
Clarify the difference between a system without secure boot and user-initiated insecure mode

This ought to fix that case.

Comment 2 Peter 2013-12-04 11:55:36 UTC
(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

Comment 3 Kamil Páral 2013-12-04 12:29:32 UTC
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.

Comment 4 Peter 2013-12-04 12:56:49 UTC
(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....

Comment 5 Matthew Garrett 2013-12-04 16:15:29 UTC
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.

Comment 6 Peter 2013-12-04 16:41:36 UTC
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.

Comment 7 Matthew Garrett 2013-12-04 16:47:48 UTC
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.

Comment 8 Kamil Páral 2013-12-04 16:54:36 UTC
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 :-)

Comment 9 Peter 2013-12-04 17:33:36 UTC
Created attachment 832790 [details]
patched shim.efi

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...

Comment 10 Kamil Páral 2013-12-04 19:54:14 UTC
(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.

Comment 11 James Lawrence 2014-02-19 13:37:33 UTC
Is there any progress on this?  It really does ruin the user experience during boot

Comment 12 Marco 2014-04-04 18:44:42 UTC
(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.

Comment 13 Kamil Páral 2014-09-18 07:50:01 UTC
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):

shim-0.7-2.fc20.x86_64
shim-unsigned-0.7-1.fc20.x86_64

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...

Comment 14 Kashyap Chamarthy 2014-11-09 18:11:38 UTC
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.

Comment 15 Fedora End Of Life 2015-05-29 09:48:21 UTC
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'
of '20'.

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.

Comment 16 Fedora End Of Life 2015-06-29 13:01:35 UTC
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
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Comment 17 Red Hat Bugzilla 2023-09-14 01:53:58 UTC
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days


Note You need to log in before you can comment on or make changes to this bug.