GRUB menu doesn't appear after showing "GRUB loading."

Bug #1401318 reported by Sworddragon on 2014-12-10
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
grub
Unknown
Unknown
grub2 (Ubuntu)
Medium
TJ

Bug Description

I'm using Ubuntu 15.04 dev with grub-pc 2.02~beta2-18 and this bug was already reported on upstream but they requested to report it to the related distribution: http://savannah.gnu.org/bugs/?40853

Summary:

It is not possible to configure GRUB anymore to automatically boot instantly to the default operating system in a multi-system environment while having the ability to show the GRUB menu if the related button (shift on my system) is keeping pressed while booting.

In comment #2 of the upstream report is an example configuration how to reproduce this behavior. Keeping shift pressed while booting does then show "GRUB loading." but the GRUB menu will not appear. Instead GRUB will immediately boot to the default operating system.

summary: - Grub menu doesn't appear after showing "GRUB loading."
+ GRUB menu doesn't appear after showing "GRUB loading."
Launchpad Janitor (janitor) wrote :

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

Changed in grub2 (Ubuntu):
status: New → Confirmed

Marking as Triaged; there is at least one other instance of this bug reported here; will mark as duplicate as soon as I find it again :)

Changed in grub2 (Ubuntu):
status: Confirmed → Triaged
importance: Undecided → Medium
tags: added: multiboot
Sworddragon (sworddragon) wrote :

I'm now on grub2 2.02~beta2-36ubuntu1 and the issue still exists. It is a bit annoying to see now for ~2 years always on booting in a multiboot environment the boot menu because of it. Any idea what could cause this issue?

TJ (tj) wrote :

Upstream comment #2 referred to above:

Mon 31 Mar 2014 08:49:03 AM UTC, comment #2:

I'm noticing a similar problem: GRUB_HIDDEN_TIMEOUT is set to 0, GRUB_TIMEOUT is set to 0.0 (to bypass a check of os-prober which would set it to 10 if set to 0) and GRUB_TIMEOUT_STYLE is set to menu (but I'm not sure how GRUB_TIMEOUT_STYLE does affect this all). After executing update-grub and doing a reboot I would assume that the grub menu will only appear on pressing shift otherwise it would boot immediately to the default system. But if I'm keeping shift pressed on booting I will successfully see the line "GRUB loading." but instead of displaying the menu GRUB boots immediately to the default system.

At first reading this sounds like the expected behaviour. GRUB_TIMEOUT_STYLE controls how the terminal is rendered whilst the countdown timeout is in progress. "menu" means show the menu during countdown.

GRUB_HIDDEN_TIMEOUT=0 means don't do a countdown but immediately start the default entry.

Testing for the Shift modifier being held down is done by "sleep --interruptable $timeout" - if $timeout is 0 this function isn't used and therefore no check of that state of the Shift modifier flags is performed.

The alternate GRUB_TERM_ESC (the Escape key being pressed/released) is done elsewhere too so pressing Esc may interrupt *if* it gets pressed at the exact moment GRUB is deciding to start the default entry.

I'll do some tests to see if I can reproduce this.

Changed in grub2 (Ubuntu):
assignee: nobody → TJ (tj)
Sworddragon (sworddragon) wrote :

> Testing for the Shift modifier being held down is done by "sleep --interruptable $timeout" - if
> $timeout is 0 this function isn't used and therefore no check of that state of the Shift modifier
> flags is performed.

But pressing Shift on booting shows "GRUB loading." so there is somewhere a successfull check for Shift performed. I think grub should either never show "GRUB loading." if it wouldn't result in loading the menu or on a timeout of 0 pressing Shift should have a higher priority then.

TJ (tj) wrote :

"GRUB loading" message comes from the bootstrap MBR code (the ~440 bytes in sector 0) of the boot device and is activated whilst shift is detected.

The boot-strap code then loads GRUB's core image which is what we might call the real GRUB code, where the $timeout value has an effect.

The only way to prevent bootstrap code from displaying the message is *not* to be holding down Shift when it loads. Since the time difference between that point and core image code checking the Shift key flag is probably in the order of a few millionths of a second its not a viable workaround :)

Sworddragon (sworddragon) wrote :

Maybe before executing "sleep --interruptable $timeout" an extra check could be done if $timeout is 0 and if true executing the function directly instead of using sleep. Could this be a potential solution?

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.