bug-grub
[Top][All Lists]
Advanced

[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

URL:
  <http://savannah.gnu.org/bugs/?33576>

                 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: 
                 Release: Bazaar - trunk
         Reproducibility: Every Time
         Planned Release: None

    _______________________________________________________

Details:

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 :-)



    _______________________________________________________

File Attachments:


-------------------------------------------------------
Date: Wed 15 Jun 2011 08:08:37 PM PDT  Name: 1.jpg  Size: 103kB   By:
brycenesbitt
That's grub 1.97 there on the lower screen.
<http://savannah.gnu.org/bugs/download.php?file_id=23527>

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?33576>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




reply via email to

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