grub-pc keystatus check

Bug #502138 reported by drs305
30
This bug affects 6 people
Affects Status Importance Assigned to Milestone
grub2 (Ubuntu)
Fix Released
Medium
Unassigned

Bug Description

Binary package hint: grub2

I don't know if this is a bug or by intentional design.

My question relates to the availability to use the SHIFT key to display the Grub 2 menu during boot.

The keystatus check is nested within 30_os-prober conditionals. Unless 30_os-prober is executed and these conditions are met it is not incorporated into grub.cfg.

Additionally, it seems that the keystatus check turns control back over to GRUB_TIMEOUT if invoked. Thus, if GRUB_TIMEOUT=0 the keystatus check may note the depressed SHIFT key but the default menu will automatically boot without stopping the boot sequence to display the menu.

If it is designed merely to interrupt the GRUB_HIDDEN_TIMEOUT and then immediately revert to the GRUB_TIMEOUT, I would suggest that the user wants to see the menu when the SHIFT key is pressed, even if the timeout is set to 0.

Workaround: I can incorporate the keystatus check by putting it into 40_custom and can then display the menu regardless of the settings.

ProblemType: Bug
Architecture: amd64
Date: Fri Jan 1 13:48:29 2010
DistroRelease: Ubuntu 9.10
InstallationMedia: Ubuntu 9.10 "Karmic Koala" - Release amd64 (20091027)
NonfreeKernelModules: nvidia
Package: grub-pc 1.97~beta4-1ubuntu4.1
ProcEnviron:
 PATH=(custom, no user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-14.48-generic
SourcePackage: grub2
Uname: Linux 2.6.31-14-generic x86_64

Revision history for this message
drs305 (drs305) wrote :
Revision history for this message
Jani Uusitalo (uusijani) wrote :

If I'm reading you correctly, then I'm unable to reproduce this. That is, if you're saying that having the keystatus check in grub.cfg depends on another OS being found by os-prober, it's not what I'm seeing in my setup: here, os-prober *does* incorporate the keystatus check into grub.cfg despite Karmic being the only OS present. But do correct me if I'm reading you wrong.

There's another issue though, the keypress not getting picked up by grub despite it being present in the config: Bug #425979 (which is why I was curious about whether I could reproduce this one).

Revision history for this message
drs305 (drs305) wrote :

Jani,

Thank you for taking the time to look at this report.

The point I'm trying to make is that the keystatus check is dependent on
1. 30_os-prober being executed
and (I think)
2. Satisfying these conditionals in 30_os-prober
  if [ "x${found_other_os}" = "x" ] ; then
    if [ "x${GRUB_HIDDEN_TIMEOUT}" != "x" ] ; then
      if [ "x${GRUB_HIDDEN_TIMEOUT}" = "x0" ] ; then

The main issue to me is that it appears 30_os-prober must be run to get the keystatus check to appear in grub.cfg. I don't find any other scripts in /etc/grub.d that place the keystatus check in grub.cfg .

For a variety of reasons, such as using a custom menu or to speed the creation of grub.cfg on a single OS system, a user may choose to remove the executable bit from 30_os-prober. If that is done, the keystatus check is not available - at least the keystatus check is not added to grub.cfg.

Colin Watson (cjwatson)
Changed in grub2 (Ubuntu):
status: New → Triaged
importance: Undecided → Medium
Revision history for this message
TJ (tj) wrote :

Setting this to Fix Released since 30_osprober was modified since 2010 and this no longer affects any Ubuntu release.

An issue that may be confused with this is bug 425979 "[UEFI boot only] Holding shift fails to display grub2 menu"

Changed in grub2 (Ubuntu):
status: Triaged → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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