[UEFI boot only] Holding shift fails to display grub2 menu

Bug #425979 reported by Martin Maney on 2009-09-07
This bug affects 62 people
Affects Status Importance Assigned to Milestone
grub2 (Ubuntu)
Nominated for Jaunty by PatrickSCarrroll
Nominated for Karmic by Carey Underwood
Nominated for Lucid by PatrickSCarrroll
Nominated for Xenial by TJ
Nominated for Yakkety by TJ

Bug Description

Binary package hint: grub2

Ubuntu added a patch on top of mainline GRUB and Debian such that holding down the Shift modifier key during boot will cause it to display
the hidden boot menu.

In the original IBM PC/AT design the modifier keys (Shifts, Ctrls, Alts) are handled separately to all other keys. Instead of reporting state transitions there is an I/O port register that is read by the software where each bit position represents the current state of the associated
modifier key.

The functionality to read this I/O port register works correctly for BIOS systems or UEFI systems starting in Legacy/CSM mode.

On UEFI systems this does not work. The reasons are:

1. At the time this Ubuntu-specific functionality was added to Ubuntu the UEFI specification, and UEFI implementations by manufacturers, did not provide a way to detect the state of the modifier keys.

2. UEFI only provides the same mechanism as for all other keys: detect a transition of state (key_down or key_up).

3. When GRUB timeout is set to 0 (zero) there is no way to detect a key press transition.

It appears that UEFI specification version 2.4 may now support the required reading of modifier key state so I shall be investigating whether we can now add support for UEFI systems that implement the v2.4 specification.

Eddie Hung (eddieh) wrote :

Hi Martin. The new grub2 is described here: https://wiki.ubuntu.com/Grub2 where it says holding down shift will show the grub menu (though I haven't had need to try this myself yet). Can you try that and report back?

Martin Maney (maney) wrote :

On Mon, Sep 07, 2009 at 11:12:43PM -0000, Colin Watson wrote:
> Try holding down Shift at boot time. This change was required by:
> https://wiki.ubuntu.com/DesktopExperienceTeam/KarmicBootExperienceDesignSpec#Bootloader

Ah, I see. Something a committee thought was too cute for words trumps
usability. Pardon me if I'm amazed - we so rarely see this in open
source software.

Considering the brokeness, apparently quite deeply rooted in alpha 5,
with the Radeon video in that box, I don't see any point in swapping
disks around again to try this invisible magic - I only need it to get
it to boot to a text console, since X fails after GDM authentication,
and I've since learned enough to feel that on this hardware alpha 5
just isn't worth the effort. Maybe the next one will have versions of
the various parts that work together.

I'd like to leave you with one thought: What does it say about how
usable this is that I had to file a freaking bug report to learn of
this silliness?

Eddie Hung (eddieh) on 2009-09-08
Changed in grub2 (Ubuntu):
status: New → Invalid

I'll adopt this, as I have similar issues, and can confirm that holding shift down doesn't work on this machine (although it does on others).

Changed in grub2 (Ubuntu):
status: Invalid → New
Carey Underwood (cwillu) on 2009-10-05
Changed in grub2 (Ubuntu):
assignee: nobody → Canonical Desktop Experience Team (canonical-dx-team)
description: updated
Ted Gould (ted) on 2009-10-05
Changed in grub2 (Ubuntu):
assignee: Canonical Desktop Experience Team (canonical-dx-team) → nobody
Jani Uusitalo (uusijani) wrote :

I'm confused by the description of this ticket, but is this about holding the Shift key during boot not working as intended? I'm asking because that's what I'm experiencing. That is, I'm unable to bring up the boot menu by holding down Shift at boot time.

Also, I was looking at Bug #502138 which to me looks related to said issue (although they might be completely separate as well).

Eddie Hung (eddieh) wrote :

One thing to check for is: if you are using a USB keyboard, does your BIOS support it? For me, I had to enable "USB Legacy Mode" in order to even be able to select which kernel to boot. Note that this is for a non-hidden GRUB2 with a non-zero timeout, as I couldn't seem to get the shift-key trick to work for a zero timeout. Will check again now and report back.

Eddie Hung (eddieh) wrote :

After some rather meticulous testing, I have come to the very scientific conclusion that holding down the shift key works only *some* of the time for displaying the GRUB2 menu when GRUB2_HIDDEN_TIMEOUT=0 is set. Repeatedly pressing the shift key down increases the chance of success somewhat. When it does not succeed, I see the underscore cursor ( _ ) flash for a few seconds, as if waiting for me to press a button, but mashing the shift and the esc keys at that point does not bring up the GRUB menu.
From [1], this seems to be intended behaviour:

"During boot, the system will check the SHIFT key status. If it cannot determine the key status, a short delay will enable the user to display the menu by pressing the ESC key."

Whilst it seems to wait for me to change my mind, it does not seem to detect me furiously pressing SHIFT or ESC.

[1] http://wiki.ubuntu.com/Grub2

Gabe Gorelick (gabegorelick) wrote :

Marking as confirmed since multiple users have reported this.

Changed in grub2 (Ubuntu):
status: New → Confirmed
summary: - [karmic alpha 5] grub2 has no visible pause for menu
+ Holding shift fails to display grub2 menu

Still present in current Lucid.

Is this a BIOS problem? I also cannot get my machine to show the menu. I am on a USB keyboard, but I know for certain that my BIOS supports it. Holding down Shift (and even escape) actually makes my machine reboot itself. I have tried tapping shift in response, but the same outcome happens. Is there a workaround that can be used?

I also have this problem. I hold the SHIFT key (left and/or right) down on every boot. I have yet to see the boot menu.

Here is my hardware:

Gigabyte GA-MA785GMT-UD2H
AMD 550 BE AM3
2x1GB Corsair XMS3 DDR3/1333
Avant Stellar keyboard (PS/2 connector)

Note this motherboard has built-in RADEON 4200 video.

Had the problem since 9.10. Still having it in 10.04, original first-day install ISO and all updates since then.

This bug made fixing X on 9.10 nearly impossible. I had to use a live boot disk to recover.

Oh, a suggestion. Stop fixing what isn't broken, (Ctrl-Alt-Backspace, ESC on boot), and stop breaking what works (grub vs grub2).

Monika Eggers (monikakrug) wrote :

On my PC holding down Shift only succeeds to show the grub menu about 1 in 10-20 attempts.

Monika Eggers (monikakrug) wrote :

These are my settings (Lucid default):

If anyone has a Natty test install available, see if it's working now. It seems to be working fine with this current version for me:


James Young (marmarama) wrote :

This is still broken for me with Natty. If the grub2 menu is hidden then pressing shift does not show the menu as expected. Machine is a Dell Latitude E5510.

Lassi (lassi-vaatamoinen) wrote :

Related issue also observed here with 11.04 Natty (Kubuntu). Although grub menu is not set as hidden, but is should display always, sometimes only the background image is displayed (without menu entries), this happens about 40-50% of the time.

However, if during the boot only the grub2 background is displayed, pressing shift brings menu visible also, but *only* if shift-key is pressed within some amount of time (the menu hidden timeout value). Otherwise screen stays blank with the background image visible.

Observed on Lenovo T510. Upgraded from 10.10 to 11.04

João Silva (joaomiguelsilva) wrote :

I can't get it to show on 11.10, either.

Jani Uusitalo (uusijani) wrote :

Still present on Precise today. I'm on an Asus M4A78-EM and a PS/2-connected keyboard, if that matters.

Jani Uusitalo (uusijani) wrote :

Oh, but I couldn't reproduce it on a Fujitsu Siemens Amilo M7400 laptop, so it seems to be hardware dependent.

Jani Uusitalo (uusijani) wrote :

Ah, it seems I am able to bring up the menu 100 % reliably on the M4A78-EM as well by hitting and holding the shift *immediately after firmware initialization screens* (Asus' boot graphic and ATA Security eXtension). So holding shift from power-up or from the boot graphic screen won't work in this setup, but seems to work with others (such as my FS laptop). I'd expect it to work from power-up consistently across different setups.

Peter Wagner (o-petris) wrote :

Encounter the same with a forgot-the-name desktop PC (Intel Core i3 530) on Precise. Even if I set GRUB_HIDDEN_TIMEOUT=20 (plus update-grub), the boot continues without delay as if no hidden wait would happen. Neither SHIFT nor ESC makes a menu appear, and in the case of a non-zero hidden timeout neither any other key.

I returned to a GRUB_TIMEOUT=1 in order to be able to react in the case of a defect on Precise. This really works. Live CD also wouldn't help, as it comes with a not working nouveau graphical adapter, and only the alternate CD really starts.

<email address hidden>

Rainer Rohde (rainer-rohde) wrote :

Same here on Quantal Alpha 2...

Any progress on this bug?

ceg (ceg) wrote :

This is grub bug someone forward this to grub authors!


Somehow even if HIDDEN_TIMEOUT is set to a positive value, "the" shiftkey (said to be only the right-shift !!!) is said to only work if there is also GRUB_DISABLE_OS_PROBER=true

fejes (anthony-fejes) wrote :

I'm going to come out and say "Me too", but with the adde bonus that it's a problem in 13.04 kubuntu - so obviously still around. (Yes, it has become a major issue for me, as the 3.7 kernel is broken and I can't boot into a working kernel... wonderful.)

bolodya (bolodya) wrote :

I had the same problem - cant access to grub menu by esc or shift keys during boot if I tried to hide it (I have windows and ubuntu on one disk).

The reason is one strange condition in /etc/grub.d/30_os-prober script. it bloks hidden menu part of grub.cfg if os-probber found any other os.

So for me works the following:

1. In the file /etc/grub.d/30_os-prober
- comment line 33: if [ "x${found_other_os}" = "x" ] ; then
- and comment closing it "fi" at line 67

2. Sudo updade-grub

After that if you have GRUB_HIDDEN_TIMEOUT >=1 then you can access to grub menu by esc key during this timeout,
if you have GRUB_HIDDEN_TIMEOUT =0 then you can access to grub menu if you press "shift" during grub startup,
and no hidden menu if GRUB_HIDDEN_TIMEOUT =-1.

Matthew (mh00h) wrote :

/etc/grub.d/30_os-prober does not exist on my 12.10 machine

it's /etc/grub.d/proxifiedScripts/os-prober on 13..04

after working with grub customizer

Alexander Luetjen (luetjen) wrote :

Same problem here.

* Ubuntu 12.04.2 LTS

* Hardware:
 Manufacturer: Hewlett-Packard
 Product Name: HP Z220 SFF Workstation
 USB keyboard.

Aleš Pospíchal (ales-s) wrote :

Still not fixed, I have same problem with Ubuntu 13.10, I installed 12 school computer for dualboot with Windows. Then I configured default entry to be Windows and GRUB_TIMEOUT=0 and was expecting that I can use Shift key to access grub menu but it does not work.
I tried ESC but it causes reboot.

Vladimir Rutsky (rutsky) wrote :

On fresh install of Ubuntu 14.04.1: both shifts (holding or repeatedly pressed) do nothing --- system continues to boot.
Pressing "escape" just after GRUB is started presents menu, but this requires quite good timing (in contrast to just holding shift during computer boot).
If "escape" is pressed repeatedly, GRUB shell appears (as if you press "escape" in GRUB menu).

Robert Hrovat (robi-hipnos) wrote :

Damn I'm freaking out over this. Trying to fix new installation of 14.04.01 when fglrx driver did not switch backlight on and I can't get inside boot menu!!! Ubuntu, please stop making it impossible to fix mistakes even from your official repos.

Still a problem on 15.04 MSI UEFI hardware. Shift never works, though it has on *some* other computers.

TJ (tj) on 2016-05-10
summary: - Holding shift fails to display grub2 menu
+ [UEFI boot onlu] Holding shift fails to display grub2 menu
summary: - [UEFI boot onlu] Holding shift fails to display grub2 menu
+ [UEFI boot only] Holding shift fails to display grub2 menu
Changed in grub2 (Ubuntu):
assignee: nobody → TJ (tj)
importance: Undecided → High
status: Confirmed → In Progress
TJ (tj) on 2016-05-10
description: updated
Marcho Markov (marcho) wrote :

I'd like to chip in here. Hardware is Thinkpad X220. Ubuntu 16.10 UEFI boot. Keyboard works fine when menu is visible, grub just fails to detect the desired keys in order to bring up the menu.

Marcho Markov (marcho) wrote :

I'd like to chip in here. Hardware is Thinkpad X220. Ubuntu 16.10 UEFI boot. Keyboard works fine when menu is visible, grub just fails to detect the Shift keys in order to bring up the menu. Esc key works, though.

Daniel Richard G. (skunk) wrote :

Hello everyone,

There is a bug report similar to this one on the Debian side:


There, Colin Watson made an interesting comment:

> When I last looked into this, this wasn't possible with UEFI: the
> firmware doesn't tell us about held modifier keys. You'll probably need
> to use a short but non-zero timeout and press Escape instead.
> (It's possible that more recent versions of the UEFI spec have improved
> this; but if so then somebody would need to implement that in GRUB, and
> it would still only work if you had new enough firmware.)

So it would seem that the old way of bringing up the GRUB menu by holding down the Shift key just doesn't work in this brave new UEFI world anymore.

It would be interesting to hear if anyone is aware of a system that boots in UEFI mode and *does* respond to the held Shift key. Currently, I don't believe it's clear as to whether this is an architectural limitation of UEFI (i.e. it can't be fixed), or if newer UEFI firmware versions could potentially make held modifier keys usable.

Ploni Almoni (ploni) wrote :

I'm having the same issue, but I'm booting using Legacy/CSM mode on my Lenovo Thinkpad T430 running Ubuntu (MATE) 18.04.1.

Aimo Ella (aimo-ella) wrote :

Is #1258597 a duplicate of this one?

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

Duplicates of this bug

Other bug subscribers

Remote bug watches

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