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

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

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 :)

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?

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.

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

"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 :)

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?

On testing this again on Ubuntu 18.10 dev with grub-pc 2.02-2ubuntu13 and this time by not setting GRUB_HIDDEN_TIMEOUT at all, setting GRUB_TIMEOUT to 0.0 and then testing with GRUB_TIMEOUT_STYLE being set to menu (while keeping shift pressed at booting), hidden (while keeping ESC pressed at booting) and coutdown (while keeping ESC pressed at booting) I'm still seing the behavior from the startpost.

But according to the documentation at https://www.gnu.org/software/grub/manual/grub/html_node/Simple-configuration.html it should work:

> ‘GRUB_TIMEOUT_STYLE’
>
> If this option is unset or set to ‘menu’, then GRUB will display the menu and then wait for the timeout set by ‘GRUB_TIMEOUT’ to expire before booting the default entry. Pressing a key interrupts the timeout.
>
> If this option is set to ‘countdown’ or ‘hidden’, then, before displaying the menu, GRUB will wait for the timeout set by ‘GRUB_TIMEOUT’ to expire. If ESC is pressed during that time, it will display the menu and wait for input. If a hotkey associated with a menu entry is pressed, it will boot the associated menu entry immediately. If the timeout expires before either of these happens, it will boot the default entry. In the ‘countdown’ case, it will show a one-line indication of the remaining time.

One could argue if a timeout of 0 can be interrupted by a button press or not but there are a few reason why it should:

- Otherwise I see not how the wanted behavior from the startpost could be possible (booting to the default operating system at default without waiting and only displaying the selection if a related key is pressed).
- The reporter from the upstream report claims that this has worked in the past.
- I think the documentation for GRUB_HIDDEN_TIMEOUT also implies that a timeout of 0 should be interruptable.