Default grub2 configuration won't boot through to default OS

[Patrick Goetz]

Binary package hint: grub-common

The default settings for /etc/default/grub won't allow the machine to boot through automatically to the default OS -- someone must hit <Enter> on the console, which is almost never an appropriate configuration for a server. Here is the default /etc/default/grub:

# If you change this file, run 'update-grub' afterwards to update
# /boot/grub/grub.cfg.

  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="quiet splash"
  GRUB_CMDLINE_LINUX=""

with just a bit of trial and error I discovered that a non-zero value must be set for GRUB_HIDDEN_TIMEOUT in order for the machine to boot through to the first OS after timeout; e.g.

# If you change this file, run 'update-grub' afterwards to update
# /boot/grub/grub.cfg.

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

Looking over the documentation for grub2, it seems clear that GRUB_HIDDEN_TIMEOUT shouldn't have anything to do with whether or not the machine boots through after timeout. I'm guessing this is a grub2 bug? Ubuntu/package versions listed below:

root@ibis:/home/pgoetz# cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=9.10
DISTRIB_CODENAME=karmic
DISTRIB_DESCRIPTION="Ubuntu karmic (development branch)"

root@ibis:/home/pgoetz# dpkg -l | grep grub
ii grub-common 1.97~beta2-2ubuntu2 GRand Unified Bootloader, version 2 (common
ii grub-pc 1.97~beta2-2ubuntu2 GRand Unified Bootloader, version 2 (PC/BIOS

[Steve Beattie (sbeattie)]

Patrick: can you update to the current version of grub2 in karmic and do grub-install on your boot device (likely /dev/sda, but possibly not). I am unable to reproduce the behavior you see with the current version of grub2, but I did see it with an earlier install, and updating and installing the newer grub version made that behavior go away. There's also been a fair amount of changes in the handling of GRUB_HIDDEN_TIMEOUT since 1.97~beta2-2ubuntu2, and I suspect those changes addresses your issue. Thanks.

[Patrick Goetz (pgoetz)]

apt-get install grub2 updated the grub2 package to 1.97~beta3-1ubuntu8. This appears to have fixed the problem, i.e. I ran

  grub-install /dev/sda

and then changed the value of GRUB_HIDDEN_TIMEOUT back to 0 (the package default)
GRUB_HIDDEN_TIMEOUT=0
ran grub-update, and the machine still boots through as it should.

One very odd thing: the other grub2 packages still report being at version 1.97~beta2-2ubuntu2 ?
This must be a mistake, given that grub2 is just a dummy package.

ibis:~~$ dpkg -l | grep grub
ii grub-common 1.97~beta2-2ubuntu2 GRand Unified Bootloader, version 2 (common
ii grub-pc 1.97~beta2-2ubuntu2 GRand Unified Bootloader, version 2 (PC/BIOS
ii grub2 1.97~beta3-1ubuntu8 GRand Unified Bootloader, version 2 (dummy p

[Patrick Goetz (pgoetz)]

Steve Beattie wrote:
> Patrick: can you update to the current version of grub2 in karmic and do
> grub-install on your boot device (likely /dev/sda, but possibly not). I
> am unable to reproduce the behavior you see with the current version of
> grub2,

The current version is 1.97~beta3-1ubuntu8. I updated to this and the
problem appears to be fixed now. Oddly, the other grub packages are
listed as still being 1.97~beta2-2ubuntu2? That must be some kind of
mistake, since grub2 is just a dummy package...

ibis:~~$ dpkg -l | grep grub
ii grub-common 1.97~beta2-2ubuntu2
GRand Unified Bootloader, version 2 (common
ii grub-pc 1.97~beta2-2ubuntu2
GRand Unified Bootloader, version 2 (PC/BIOS
ii grub2 1.97~beta3-1ubuntu8
GRand Unified Bootloader, version 2 (dummy p

Thanks for alerting me to the update.

[Colin Watson (cjwatson)]

The grub2 package itself contains nothing of any note. grub-common and
grub-pc are the packages it depends on that actually do something, and
you'd need to upgrade those. If you saw any effect from upgrading grub2
on its own, it was coincidental.

Package: grub2
Depends: grub-pc
Description: GRand Unified Bootloader, version 2 (dummy package)
 This is a dummy transitional package to handle GRUB 2 upgrades. It can be
 safely removed.

[Patrick Goetz (pgoetz)]

Yes, I understand, that's the point. If grub2 depends on grub-pc, shouldn't this have updated as well when I updated grub2?

I noticed the grub problem on the initial install of alpha4 (or the current daily build, I can't remember which) and worked around it as outlined in the bug report. When alpha5 came out, I did a dist-upgrade, and then made a point of testing the grub configuration problem again, trying the package maintainer's settings again before switching back to GRUB_HIDDEN_TIMEOUT=1 when the machine wouldn't boot through. After this particular dist-upgrade, debconf was asking me if I wanted to keep the existing /etc/default/grub or install the package maintainer's version (I selected the package maintainer's version for testing), so I'm presuming the postinst script ran grub-update for me?

In any case, the problem seems to be resolved now -- maybe the issue was nothing more than grub-update wasn't getting run on grub2 update.

[Colin Watson (cjwatson)]

On Thu, Oct 08, 2009 at 02:32:00AM -0000, Patrick Goetz wrote:
> Yes, I understand, that's the point. If grub2 depends on grub-pc,
> shouldn't this have updated as well when I updated grub2?

It's an unversioned dependency, so the old version satisfies the
dependency just as well and therefore apt doesn't bother to upgrade it.
(This may be an error in how the dependency is declared, but it's how it
is right now.)

> I'm presuming the postinst script ran grub-update for me?

update-grub is always run, yes.

> In any case, the problem seems to be resolved now -- maybe the issue was
> nothing more than grub-update wasn't getting run on grub2 update.

Could be, though that code hasn't changed in a while ...

[Patrick Goetz (pgoetz)]

> It's an unversioned dependency, so the old version satisfies the
> dependency just as well and therefore apt doesn't bother to upgrade it.
> (This may be an error in how the dependency is declared, but it's how it
> is right now.)

Can we call this a bug? It seems pointless to have a dummy package if it's not going to haul in the latest versions of the dependencies.

[Scott Wilson (srwi)]

It looks like I'm still having this issue with beta 4 in the karmic final, although it may or may not have degraded further: the abovementioned workaround involving a non-zero value for GRUB_HIDDEN_TIMEOUT does not appear to work, and GRUB boots to a menu on every occasion; the only case where it does not is if I set GRUB_TIMEOUT to 0, which is not practical for me as a dual-boot user. Below is my /etc/default/grub, which despite appearances, boots to the menu.

# If you change this file, run 'update-grub' afterwards to update

# /boot/grub/grub.cfg.

GRUB_DEFAULT=0

GRUB_HIDDEN_TIMEOUT=1

GRUB_HIDDEN_TIMEOUT_QUIET=true

GRUB_TIMEOUT=-1

GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

#GRUB_CMDLINE_LINUX=" vga=771"

# 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=800x600x32

# 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 entrys

#GRUB_DISABLE_LINUX_RECOVERY="true"

[Jason Heblack (jason-heblack)]

Hi:
        I had an issue with karmic so now am on LTS 8.04. The issue was with grub2
        and I'm wondering if you had read this:

        http://ubuntuforums.org/showthread.php?t=1312798&highlight=grub

[Patrick Goetz (pgoetz)]

Jason Heblack wrote:
> Hi:
> I had an issue with karmic so now am on LTS 8.04. The issue was with grub2
> and I'm wondering if you had read this:
>
> http://ubuntuforums.org/showthread.php?t=1312798&highlight=grub
>

This does sound like it could be the same (or similar) problem I was
having with grub.

[David Gil (dabito)]

Im having the same issue described on http://ubuntuforums.org/showthread.php?t=1312798&highlight=grub does anybody know of a workaround?

[bpollen (bpollen)]

Only workaround I have found is to reinstall grub-pc and grub-common... EACH AND EVERY time you boot to Karmic. The it will time out and boot to the default OS. But the next time you boot to Karmic (whether default or not) you have to reinstall. If you don't, there is no countdown. At least that is the way it has worked with multiple installs of Karmic.

This is referring to Grub2 up to and including 1.97-beta4-1ubuntu5.

[Patrick Goetz (pgoetz)]

Are you saying the workaround I posted to this bug doesn't work for you?

bpollen wrote:
> Only workaround I have found is to reinstall grub-pc and grub-common...
> EACH AND EVERY time you boot to Karmic. The it will time out and boot to
> the default OS. But the next time you boot to Karmic (whether default or
> not) you have to reinstall. If you don't, there is no countdown. At
> least that is the way it has worked with multiple installs of Karmic.
>
> This is referring to Grub2 up to and including 1.97-beta4-1ubuntu5.
>

[Eric Schumann (liste2010)]

I am also affected by this. It happens on my site on 2 different k7 desktop machines.
those machines have issues with booting modern boot cd's like windows7beta. The code 5 error comes up at least with one of them. So it might be an issue with the older bios boot code.

I'm unsure how to reproduce it, but it looks like going into single user mode by edditing the command line triggers it here. My grub is configured using a gfx pic, no memtest, no single user entry. All grub packages up to rev 4 affected.
No workarround helps but reinstalling grub.

[bpollen (bpollen)]

Yes, Patrick, that is exactly what I am saying. After the initial install of the OS, grub2 works. Should I have the temerity to actually edit the configuration, like say... editing /etc/default/grub, it stops working.

[Eric Schumann (liste2010)]

I tried another computer without known bios issues and also 1.97-beta4-1ubuntu5. with the default configuration.

I can reproduce the timer to not count down by going into recovery mode, drop to a root shell, type reboot.

Next, the countdown does not kick in and the machine waits for a key.

[Jon Jacobsen (jonj)]

I don't need grub2. Do the masses?

I removed grub-pc and installed grub. I had to run update-grub to create a menu.1st and grub-install /dev/sda to update the bootloader.

You my want to edit /boot/grub/menu.1st to taste.

I don't think a beta bootloader should be a default install for Karmic.

[PFudd (kernel-pkts)]

I have Lucid Lynx, and I'm getting this problem (grub2 menu showing up and waiting forever), but the workaround in the initial comment (GRUB_HIDDEN_TIMEOUT=1) doesn't work for me. This is grub-pc 1.98-1ubuntu9.

What I did find worked for me was to edit /boot/grub/grubenv, add 'recordfail=0', and adjust the length of the file to 1024 bytes (probably unnecessary).

This worked for one boot, at which point it erased 'recordfail=0' and I was back at square one.

Part of the problem may be that I copied this hard drive image from a VMware virtual machine to a VirtualBox one. I had to use a rescue disk to reinstall grub2, but it all works, except for this menu problem.

Thanks

[Jacob Nielsen (j.nielsen)]

> [...] I'm wondering if you had read this:
> http://ubuntuforums.org/showthread.php?t=1312798&highlight=grub

From that thread (#7):

> After a forced shutdown (power loss) Grub waits at the menu ignoring the timeout options, some sort of
> "do you want recovery or normal boot?"

My headless server was just bit by this. It's running 10.10 server x86, but has been upgraded through 3 releases.
The default/grub settings are identical to those listed first in the original report, except for GRUB_TIMEOUT=3.

As an incentive to get this fixed :-P here are pictures taken just before new year's, of an Arriva information kiosk probably having the same problem...

http://tullinup.dk/temp/2.jpg
http://tullinup.dk/temp/1.jpg

Nice to know they are using Ubuntu, though.

[Bryce Nesbitt (bryce2)]

Submitted upstream as https://savannah.gnu.org/bugs/index.php?33576

[JC Hulce (soaringsky)]

Upstream comments are really interesting... they state that all of these issues are caused by Ubuntu-specific patches.

BTW I tried to link the upstream bug https://savannah.gnu.org/bugs/index.php?33576 but launchpad wouldn't let me

[alfa (alfa42)]

I have the same issue under 14.04 LTS (amd64, fresh install). My environment is:

root@PC:/etc/grub.d# dpkg -l | grep grub
ii grub-common 2.02~beta2-9ubuntu1 amd64 GRand Unified Bootloader (common files)
ii grub-gfxpayload-lists 0.6 amd64 GRUB gfxpayload blacklist
ii grub-pc 2.02~beta2-9ubuntu1 amd64 GRand Unified Bootloader, version 2 (PC/BIOS version)
ii grub-pc-bin 2.02~beta2-9ubuntu1 amd64 GRand Unified Bootloader, version 2 (PC/BIOS binaries)
ii grub2-common 2.02~beta2-9ubuntu1 amd64 GRand Unified Bootloader (common files for version 2)

root@PC:/etc/grub.d# cat /etc/issue
Ubuntu 14.04.1 LTS \n \l

In my /etc/default/grub file the settings are the same as those in the first page (setting to 0 the timeouts).

[Marcus Tomlinson (marcustomlinson)]

This release of Ubuntu is no longer receiving maintenance updates. If this is still an issue on a maintained version of Ubuntu please let us know.

[Marcus Tomlinson (marcustomlinson)]

This issue has sat incomplete for more than 60 days now. I'm going to close it as invalid. Please feel free re-open if this is still an issue for you. Thank you.