ctrl-x does not work in grub-efi

Bug #722950 reported by Phillip Susi on 2011-02-22
46
This bug affects 10 people
Affects Status Importance Assigned to Milestone
grub2 (Ubuntu)
Medium
Unassigned
Xenial
Undecided
dann frazier
Zesty
Undecided
Unassigned
Artful
Undecided
Unassigned

Bug Description

[Impact]
On some UEFI platforms, useful key combinations fail to work over the serial console. In particular, ^x/F10 - one of which is needed to boot after interactively editing the boot menu. This leaves end users without a sane way to tweak command line arguments, and potentially other system recovery tasks.

[Test Case]
Boot such a UEFI system to the GRUB menu. Press 'e' to edit the commandline, then attempt to continue the boot using "^x".

[Regression Risk]
The proposed fix is a cherry-pick from upstream that we've been shipping in Ubuntu since 17.10 w/o any any known regressions. However, it is possible that such regressions exist - e.g. if a platform's firmware has a buggy implementation fo the EFI_SIMPLE_TEXT_INPUT_EX protocol.

Janosch Maier (phylu) wrote :

Similar problem on Ubuntu 10.04 Server version.

Igor Mitrenko (igor-mitrenko) wrote :

Ctrl+x doesn't work in grub2 version, shipped with Ubuntu 11.04. As well as other ctrl+<...> hotkey doesn't work.

It won't insert "x" and other symbols like ctrl is not pressed, it just does nothing. Whereas alternative hot keys like F10 and others work well.

Phillip Susi (psusi) on 2011-06-14
Changed in grub2 (Ubuntu):
importance: Undecided → Medium
status: New → Triaged
Janne Snabb (snabb) wrote :

I am affected by this issue on Ubuntu 15.04 x86_64. I have AMI BIOS/UEFI. Ctrl-X does not work (but F10 works). In my case 'x' is inserted as if I did not press Ctrl key.

I found a discussion and a potential patch at: https://lists.gnu.org/archive/html/grub-devel/2013-08/msg00003.html

Possibly related question at StackExchange: https://unix.stackexchange.com/questions/103989/pressing-ctrl-x-or-f10-does-not-boot-linux

Dan Mick (dmick-m) wrote :

This is fixed in the upstream by commit 9e5f70174ec960a0077f20bb74cb9f4da9b57e7b (and a warning removed by 5fcde03bf1e8cf74c186bcef6d705734f2d002c5). Grub also just recently tagged grub-2.02-beta3 with many more fixes. I think this one is major enough that, if the risk of a full transition to beta3 is considered high until more testing is done, then the above two commits should be pulled in as a patch.

This is a complete disabler for those trying to boot EFI over serial-redirected console, as it's likely F10 doesn't work, and neither does ^X.

Launchpad Janitor (janitor) wrote :

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

Changed in grub2 (Ubuntu Artful):
status: New → Confirmed
Changed in grub2 (Ubuntu Xenial):
status: New → Confirmed
Changed in grub2 (Ubuntu Zesty):
status: New → Confirmed
dann frazier (dannf) on 2017-11-30
Changed in grub2 (Ubuntu Artful):
status: Confirmed → Fix Released
dann frazier (dannf) on 2018-01-11
Changed in grub2 (Ubuntu):
status: Triaged → Fix Released
Changed in grub2 (Ubuntu Xenial):
status: Confirmed → In Progress
assignee: nobody → dann frazier (dannf)
Changed in grub2 (Ubuntu Zesty):
status: Confirmed → Won't Fix
dann frazier (dannf) on 2018-01-17
description: updated
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers