bugGNU GRUB - Bugs: bug #33576, Three issues with grub2 on kiosk...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #33576: Three issues with grub2 on kiosk or headless servers. Waits forever for keystroke.

Submitter:  Bryce Nesbitt <brycenesbitt>
Submitted:  Thu 16 Jun 2011 03:08:37 AM UTC
   
 
Category:  Booting Severity:  Major
Priority:  5 - Normal Item Group:  Software Error
Status:  Invalid Privacy:  Public
Assigned to:  None Originator Name: 
Open/Closed:  Closed Release:  Bazaar - trunk
Release:  Reproducibility:  Every Time
Planned Release:  None

Thu 16 Jun 2011 04:14:07 AM UTC, comment #1: 

First two parts are caused by Ubuntu-specific patches not included upstream for among other things, for this very reason. As for the third it's Ubuntu-specific too but configurable (disable hidden timeout).

Vladimir Serbinenko <phcoder>
Group administrator
Thu 16 Jun 2011 03:08:37 AM UTC, original submission:  

See
https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/797544
https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/428570
http://ubuntuforums.org/showthread.php?p=10940949#post10940949


There are at least three scenarios where grub2 can hang waiting for a keystroke prior to booting.  This is obviously fatal on a machine without a keyboard.  At least as grub2 is configured on Ubuntu:

1) On Ubuntu/Debian systems "apt-get upgrade" can trigger "grub-setup". If by chance there happens to be a USB drive attached with Linux on it... grub will find it. And suddenly you have two OS's in grub.conf and grub changes behavior an asks.

2) If a previous boot fails (for example because of a power failure in the middle), the next boot waits forever for a keypress.  /etc/grub.d/00_header explicitly does this, so the behavior was intentional.

3) On a kiosk, if a visitor happens to press the shift key (or it is stuck) at boot time, the machine won't finish the boot.

While this behavior is more or less documented at:
https://help.ubuntu.com/community/Grub2#Boot Display Behavior
It is not good behavior for kiosk and remote machines.

This bug report is to suggest that grub be altered so there is NO REASONABLE WAY to configure grub to wait forever.  That all paths through grub2 should eventually boot something, even if the
timeout is long.

Screens showing grub2 on a public kiosk:
http://tullinup.dk/temp/1.jpg
Are not good advertisements for Linux :-)

Bryce Nesbitt <brycenesbitt>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attached Files
file #23527:  1.jpg added by brycenesbitt (103KiB - image/jpeg - That's grub 1.97 there on the lower screen.)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by phcoder (Posted a comment)
  • -email is unavailable- added by brycenesbitt (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2011-06-16 phcoder StatusNone Invalid
        Open/ClosedOpen Closed
    2011-06-16 brycenesbitt Attached File- Added 1.jpg, #23527

    Back to the top

    Powered by Savane 3.13-cf05.
    Corresponding source code