grub2 waits forever for keystroke before booting default OS. headless server. hang.

Bug #797544 reported by Bryce Nesbitt on 2011-06-15
204
This bug affects 54 people
Affects Status Importance Assigned to Milestone
grub2 (Ubuntu)
High
Unassigned

Bug Description

Binary package hint: grub2

After a seemingly-routine "apt-get update" on an Ubuntu 10.10 server, the machine hangs on boot.
It is sitting at the grub2 prompt, waiting in vain for someone to come along and press <enter>.

I have tried two workarounds:

---------------------------------------------
Edit /etc/grub.d/00_header to remove the check for recordfail in:

make_timeout ()
{
    echo "set timeout=1"
}
--------------------------------------------------------------------
In /etc/default/grub set
 GRUB_HIDDEN_TIMEOUT=2
---------------------------------
Then "sudo update-grub"

Now I'm pretty dang stuck. There is plenty of forum activity on this issue, but no true solutions.

Bryce Nesbitt (bryce2) wrote :

See also
http://serverfault.com/questions/243343/headless-ubuntu-server-machine-sometimes-stuck-at-grub-menu
http://ubuntuforums.org/showthread.php?t=1312798&highlight=grub
http://ubuntuforums.org/showthread.php?p=10940949#post10940949
http://ubuntuforums.org/showthread.php?p=10940951#post10940951
https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2010-January/010432.html
https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/428570
And especially http://tullinup.dk/temp/2.jpg http://tullinup.dk/temp/1.jpg

Note that the failures I see are after a clean boot... most of the above are reports of a problem after a dirty boot.
I've seen the issue on several machines now... all after performing "sudo apt-get upgrade/update".

This is a very serious issue for any unattended or kiosk type machine. I ask for an "urgent" rating on the bug.
This is not quite a duplicate of the older report 428570 .

Bryce Nesbitt (bryce2) wrote :

Versions:
grub-common 1.98+20100804-5ubuntu3
grub-pc 1.98+20100804-5ubuntu3

Again, asking for "urgent" on this one, as it really affects servers in a major way.

Bryce Nesbitt (bryce2) wrote :

See also
https://help.ubuntu.com/community/Grub2#Boot Display Behavior
Which more or less documents part of this behavior. But remember I get this on clean boot.

Bryce Nesbitt (bryce2) wrote :

SOLVED (sort of):

We found three causes of the "headless server waits forever for someone to press a key" problem with grub2:

1) "apt-get updgrade" 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 and grub 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.
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.

All three issues are problems for unattended/kiosk uses of Ubunu.

Michal Suchanek (hramrach) wrote :

4) you have a serial port

 # cat /etc/grub.d/03_serial
#!/bin/sh

echo serial --unit=0 --speed=115200
echo terminal_input --append serial\; terminal_output --append serial

Launchpad Janitor (janitor) wrote :

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

Changed in grub2 (Ubuntu):
status: New → Confirmed
Changed in grub2 (Ubuntu):
importance: Undecided → High

To work around problem 2), see this: bug 872244

Alex Muntada (alex.muntada) wrote :

In my case, i'm convinced that recordfail is set due to an issue with the SD-MMC card reader of my HP Pavilion g6, which persists even after installing grub with --recheck. Changing timeout on 00_header solved the problem.

Thanks!

Mark - Syminet (mark-syminet) wrote :

Horrible. We do not see this idiocy on Debian Systems, it is an UBUNTU problem. Apparently they re-packaged it without knowing what they are doing. Mint exists because why. Please make your changes much miloder, and concern yourself with the source. If they aren't doing it, then your "new" ideas shouldn't either.

Mark - Syminet (mark-syminet) wrote :

*milder ... sorry for the rant too but I've been venting awhile. I think many people have. Stop reinventing the wheel please and follow your own upstream - they already do most of the work for you.

This has been fixed with 12.10 and a SRU for 12.04 landed today.

To apply the fix, simply put:
"GRUB_RECORDFAIL_TIMEOUT=5" in /etc/default/grub

And then run: "update-grub"

Changed in grub2 (Ubuntu):
status: Confirmed → Fix Released
milestone: none → ubuntu-12.10
Florin Andrei (florin-andrei) wrote :

This "feature" makes no sense to me. I've been using Linux on servers since Slackware came on a stack of floppies. Any sysadmin worth their salary will tell you it's an extremely bad decision to let the server hang if it was improperly shut down. I want my servers to come back online after an issue, why are you keeping them offline?

One of my 12.04 servers is crashing regularly due to a 3.2 kernel bug. EVERY SINGLE TIME someone needs to walk all the way there and hit the reset button. Lost power once - same thing, Ubuntu won't come up; but Windows did; Red Hat did. This is revolting.

Please, please, please, remove this caricature of a "feature" from a distribution meant for servers. Please ask experienced sysadmins before making such changes. A server should come up ALL BY ITSELF whenever possible. Do not prevent it from doing so.

I will update the kernel to a non-buggy version and reconfigure grub to not hang anymore, but meanwhile this distribution is installed on numerous of servers around the world and causes unnecessary downtime because of a nonsensical decision in a package somewhere. :(

Ubuntu team, you have really let the ball drop on this one.

The default should be... the system boots.
It should be hard, if not impossible, to change that default.

Alecz20 (alexguzu) wrote :

This is still an issue on Ubuntu 12.10

I used the XBMCBuntu iso, which installs a custom version of 12.10, and this issue persists regardless of clean/forced reboot.

I have tried editing the /etc/grub.d/00_header, but it did not help.

I will try the suggestion in post #11 and let you know how it goes.

While it might make some sense to do something different when the power is cut off, waiting for an "Enter Key" is not a sensible choice.

What should be done is the following:

- fsck all drives! (see http://ubuntuforums.org/showthread.php?t=1386549 and http://ubuntuforums.org/showthread.php?t=1601810 for problem)

- show the grub menu for 10 seconds (in case somebody is watching and wants to do something)

Alecz20 (alexguzu) wrote :

Just to follow-up on my last comment.

I was unable to try the solution as grub would not see the Linux OS after a grub-install on /dev/sda, and omitting to run update-grub right afterwards.
I struggled with a live-USB to fix grub, but after several hours, I ended just re-installing the whole thing.

After the new install the issue no longer appeared.

I guess there is something flaky in the code that causes the issue to only appear on occasion.

Ivan Kozik (ludios) wrote :

I spent about 15 hours trying to figure out why my headless Ubuntu 14.04 Beta server wasn't booting. No IPMI or remote hands were available in this case, unfortunately. I finally got on the right track when I noticed in my identical test VM that grub2 wasn't always automatically booting the first menuentry. After a few more dead ends with some grub options, a Google search for 'grub2 not automatic' led me to an askubuntu answer that mentioned GRUB_RECORDFAIL_TIMEOUT. Setting it to a positive integer fixed my boot problems.

Ivan Kozik (ludios) wrote :

And the reason for my troubles? I imaged my Ubuntu VM (for remote deployment elsewhere) after powering it off during the earliest stages of a boot. A strange form of a "power outage". I would've never guessed a feature designed to avoid reboot loops would come into play.

nh2 (nh2) wrote :

I don't understand what the status with 14.04 is.

Are there still cases where that might wait for a key stroke?

steverweber (steve-r-weber) wrote :

Yes this issue still happons in 14.04.

We have an issue with our storage on an ESX enviroment ~100+ guest systems were forced to hard reboot.
All the windows and centos systems had no issues, ubuntu was stuck at the grub screen and required manualy work.

This is crap and is bad for the ubunut brand!

Please fix

steverweber (steve-r-weber) wrote :

/manualy work/ = key stroke

Stephan Henningsen (zta77) wrote :

14.04 hangs and waits for key stroke. A headless server is not supposed to do that!

Claudio (claudio-enjoy) wrote :

Some machine with 2 different VM ,
debian 7.6 wheezy 3.2.0.-4 works fine but
on ubuntu 14.04 server 3.13.0-12 manually boot :/ .

Bryce Nesbitt (bryce2) wrote :

Still happens with 14.04
The default should be... the system boots.
It should be hard, if not impossible, to change that default.

Gary (vengefultacos) wrote :

I just want to add my voice that I spent hours of intense frustration dragging a headless server back and forth between the desk where I have a keyboard and screen and the room in lives in, all because of this issue. This looks like a totally random bug if GRUB isn't communicating to you why its hanging... which it doesn't. It just doesn't autostart. That's incredibly lazy.

Robert Campbell (camprr) wrote :

We are also having this problem on 14.04.1 LTS.

Extremely frustrating and completely pointless for a (headless) server-OS.

RaymondDay (raymondday) wrote :

Running a (headless) Ubuntu 12.04.1 server too. Looks like after a update have to press enter for it to boot up.

Any one know of a fix?

-Raymond Day

RaymondDay (raymondday) wrote :

Just rebooted with a screen on it and it reboot with out touching the keyboard.

I have "Welcome to Ubuntu 14.04.1 LTS (GNU/Linux 3.13.0-39-generic x86_64)"

Not sure what I did to fix it because I did not test a reboot right after the fix.

-Raymond Day

RaymondDay (raymondday) wrote :

Not sure if this will help but the start of my /etc/default/grub looks like this:

# If you change this file, run 'update-grub' afterwards to update
# /boot/grub/grub.cfg.
# For full documentation of the options in this file, see:
# info -f grub -n 'Simple configuration'

GRUB_DEFAULT=0
#GRUB_HIDDEN_TIMEOUT=0
GRUB_HIDDEN_TIMEOUT_QUIET=true
GRUB_TIMEOUT=2
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT=""
GRUB_CMDLINE_LINUX=""
GRUB_RECORDFAIL_TIMEOUT=5

The rest after is just starts with # so it don't do any thing.

-Raymond Day

PowerPenguin (x-mair-x) wrote :

Same issue for the first time now on
Welcome to Ubuntu 14.04.2 LTS (GNU/Linux 3.13.0-46-generic x86_64)

Do I have to change
GRUB_CMDLINE_LINUX_DEFAULT=""
and why ?

Power Penguin

below my config
------------------------------------------------------------------------------------------

# If you change this file, run 'update-grub' afterwards to update
# /boot/grub/grub.cfg.
# For full documentation of the options in this file, see:
# info -f grub -n 'Simple configuration'

GRUB_DEFAULT=0
GRUB_HIDDEN_TIMEOUT=0
GRUB_HIDDEN_TIMEOUT_QUIET=true
GRUB_TIMEOUT=10
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
GRUB_CMDLINE_LINUX=""

# Uncomment to enable BadRAM filtering, modify to suit your needs
# This works with Linux (no patch required) and with any kernel that obtains
# the memory map information from GRUB (GNU Mach, kernel of FreeBSD ...)
#GRUB_BADRAM="0x01234567,0xfefefefe,0x89abcdef,0xefefefef"

# Uncomment to disable graphical terminal (grub-pc only)
#GRUB_TERMINAL=console

# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command `vbeinfo'
#GRUB_GFXMODE=640x480

# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux
#GRUB_DISABLE_LINUX_UUID=true

# Uncomment to disable generation of recovery mode menu entries
#GRUB_DISABLE_RECOVERY="true"

# Uncomment to get a beep at grub start
#GRUB_INIT_TUNE="480 440 1"

PowerPenguin (x-mair-x) wrote :
bascuppen (bascuppen) wrote :

For me... solved it by noticing that after I use
sudo umount /boot
the command
ls /boot
still showed directory content. Therefore, every adjustment to the file /etc/default/grub would be written to the directory on /dev/sda1 that is mounted over my boot directory on /dev/sda3. However, during boot, mounts won't take place after a selection is made in the grub menu (either manual or by timeout)

So, I remounted my partition:
sudo mount /boot
and noted the partition I made long time ago as a boot partion by issuing the command:
mount|grep boot
I then unmounted the boot partition, moved the directory out of the way, and made a new mount point, and mounted again by:
sudo umount /boot && sudo mv /boot /boot.backup && sudo mkdir /boot && sudo mount /boot
After that, I installed the correct info to the mbr (master boot record):
sudo grub-install --recheck /dev/sda
Edited the configuration file /etc/default/grub and ran update-grub.

Hope this helps people who stumble upon this bug looking for a solution. Bear in mind you only try these commands when you know what each command does, and understand the underlying logic. I leave it to you to determine if you use MBR or uefi, or want a unbootable system.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers