timeout in grub2 not working

Bug #657871 reported by Markus Schulz
42
This bug affects 9 people
Affects Status Importance Assigned to Milestone
grub2 (Ubuntu)
Expired
Undecided
Unassigned

Bug Description

Binary package hint: grub2

In 10.04 I didn't had to press enter to boot, since I upgraded to 10.10 I have to. And I didn't find a way in /etc/default/grub to change this.

I found the issue in this area in /etc/grub.d/00_header:
if [ "${recordfail}" = 1 ]; then
  set timeout=-1
else
  set timeout=10
fi

If I change the -1 to a positive integer the time out works again... i guess this is just a workaround, the real issue must be with recordfail? But I don't know how to fix this.

Description: Ubuntu 10.10
Release: 10.10

grub2:
  Installed: 1.98+20100804-5ubuntu3
  Candidate: 1.98+20100804-5ubuntu3
  Version table:
 *** 1.98+20100804-5ubuntu3 0
        500 http://us.archive.ubuntu.com/ubuntu/ maverick/universe amd64 Packages
        100 /var/lib/dpkg/status

Revision history for this message
Markus Schulz (schulz-alpharesearch) wrote :

There is one more stage thing, I also have stuff from ### BEGIN /etc/grub.d/00_header.orig ### in my grub.cfg... I think this should not be here... I guess this could be a different bug? I will move this orig file for now!

Revision history for this message
Markus Schulz (schulz-alpharesearch) wrote :

I can confirm that this .orig file was the real reason for the problem ... after I deleted the file I change the other file back to original and run a update-grub2... the grub.cfg file was good now... and timeout was back at the boot!!!
Looks like there needs to find a different rename for this file... maybe the 00 in the beginning needs to go?? But I didn't test this.
I may changed this file in the past so I have a higher resolution for my console... so i don't this this is very wide spread.

Changed in grub2 (Ubuntu):
status: New → Confirmed
Revision history for this message
Antonio Cortes-Rodriguez (antonio-cortes) wrote :

I had exactly the same problem, just after upgrading from 10.04 to 10.10, and the workaround described in the initial report works for me, that is modifying file /etc/grub.d/00_header by replacing the if fi block by the line set timeout=10.

Interestingly enough, the same code was in the original file "/etc/grub.d/00_header" in version 10.04, but it looks that the upgrade affected something that makes "recordfail" variable to be empty when these lines of code are reached.

Revision history for this message
Chris Reynolds (c-reynolds) wrote :

Ok, this is a pain now. I have a large number of 10.10 servers, and seemingly at random, the timeout stops working after reboot. This means I have to take a lift down to the server room, and access a console to get them to boot. I can confirm the workaround solves the problem, but this could really do with being fixed for a server distro.

Revision history for this message
Nick (soapduk) wrote :

I have this problem in 11.04. I've edited the header file and it has worked this time but I haven't since tried rebooting again.

Revision history for this message
cristian.tarsoaga (cristian-tarsoaga) wrote :

problem still present in 13.04, one solution is to add this to /etc/default/grub

GRUB_RECORDFAIL_TIMEOUT=2

Grub seems to be using two separate timeouts, one for clean reboot and one for 'recordfail'.
The default for recordfail case is -1 (infinite) it totally unappropriate for a (headless!?) server.

see also bug 462888

Revision history for this message
partyzan543 (partyzan543) wrote :

Return simply and clear GRUB-0.97!

Revision history for this message
Marcus Tomlinson (marcustomlinson) wrote :

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.

Changed in grub2 (Ubuntu):
status: Confirmed → Incomplete
Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for grub2 (Ubuntu) because there has been no activity for 60 days.]

Changed in grub2 (Ubuntu):
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.