[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #33576] Three issues with grub2 on kiosk or headless servers. Waits

From: Bryce Nesbitt
Subject: [bug #33576] Three issues with grub2 on kiosk or headless servers. Waits forever for keystroke.
Date: Thu, 16 Jun 2011 03:08:38 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/534.30 (KHTML, like Gecko) Chrome/12.0.742.91 Safari/534.30


                 Summary: Three issues with grub2 on kiosk or headless
servers.  Waits forever for keystroke.
                 Project: GNU GRUB
            Submitted by: brycenesbitt
            Submitted on: Wed 15 Jun 2011 08:08:37 PM PDT
                Category: Booting
                Severity: Major
                Priority: 5 - Normal
              Item Group: Software Error
                  Status: None
                 Privacy: Public
             Assigned to: None
         Originator Name: 
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
                 Release: Bazaar - trunk
         Reproducibility: Every Time
         Planned Release: None




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:
Are not good advertisements for Linux :-)


File Attachments:

Date: Wed 15 Jun 2011 08:08:37 PM PDT  Name: 1.jpg  Size: 103kB   By:
That's grub 1.97 there on the lower screen.


Reply to this item at:


  Message sent via/by Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]