Grub loses timeout

[joneall]

When I booted this morning, grub did no timeout. I.e., it waited for me to enter <Enter>.

This has happened twice now. The first time was after a dist-upgrade. But I did no system mods yesterday. The dates indicate that none of the grub config files have changed. In /boot/grub/grub.cfg, I see

if [ "${recordfail}" = 1 ]; then
set timeout=-1
else
set timeout=10
fi
### END /etc/grub.d/00_header ###

Don't know what this is all about, but it might explain the problem. When would "${recordfail}" = 1?

Btw, whatever happened to the great grub doc which used to be at kubuntuforums.net/forums/index.php?topic=3106368.0

[cavedweller]

I've been adjusting grub from /etc/default/grub. /boot/grub/grub.conf doesn't seem to do much of anything anymore.

[Snowhog]

Btw, whatever happened to the great grub doc which used to be at kubuntuforums.net/forums/index.php?topic=3106368.0

See http://www.kubuntuforums.net/showthr...l=1#post193705

[oshunluvr]

What does your /etc/default/grub say?

[james147]

This might be of interest.

I've been adjusting grub from /etc/default/grub. /boot/grub/grub.conf doesn't seem to do much of anything anymore.

You are right, grub.conf does nothing, it is /boot/grub/grub.cfg you might be thinking of. And this file handles allot during the boot, but it is auto generated by update-grub from the values set in /etc/default/grub which is what you really want to edit.

[Snowhog]

When I booted this morning, grub did no timeout. I.e., it waited for me to enter <Enter>.

This has happened twice now. The first time was after a dist-upgrade. But I did no system mods yesterday. The dates indicate that none of the grub config files have changed. In /boot/grub/grub.cfg, I see

if [ "${recordfail}" = 1 ]; then
set timeout=-1
else
set timeout=10
fi
### END /etc/grub.d/00_header ###

Don't know what this is all about, but it might explain the problem. When would "${recordfail}" = 1?

Btw, whatever happened to the great grub doc which used to be at kubuntuforums.net/forums/index.php?topic=3106368.0

See http://sourceforge.net/apps/mediawik...rdfail_feature

[joneall]

As I said, my /boot/grub/grub.cfg continas these lines:

if [ "${recordfail}" = 1 ]; then
set timeout=-1
else
set timeout=10
fi
### END /etc/grub.d/00_header ###

The system booted fine this morning without my assistance, so I assume the timeout worked. Yet I have made no changes to the system nor run update-grub for several days. So all I can figure out is that this bit of code is where the problem occurs. But I have no idea what it is looking at, nor what the variable ${recordfail} may signify. Altho... earlier on in grub.cfg, I see

function recordfail {
set recordfail=1
if [ -n "${have_grubenv}" ]; then if [ -z "${boot_once}" ]; then save_env recordfail; fi; fi
}

which does not help me a whole lot. This bit of code originates in /etc/grub.d/00_header; the other (if recordfail...), in 10_linux.

[Snowhog]

Did you read the entire link?

[joneall]

Did you read the entire link?

Uh, it's kinduv long and has lots of links. Instead, I googled "grub recordfail" and found several answers. The explanation is given here

http://www.mikespicer.net/wp/linux/u...nd-grub-2-fun/

so it's "works as designed." It's to make sure there is no timeout after a power failure. There are various ways of dealing with it, like commenting out the whole if...fi recordfail sequence I quoted or removing (!) /boot/grub/grubenv, as explained at

http://superuser.com/questions/12499...meout-in-grub2.

I guess I'll just leave it for now. The main thing is to understand it.

Btw, the following grub2 doc seems to be as much up to date as any:

https://help.ubuntu.com/community/Grub2

(Why is this an https?)

So thanks, all.

[jlittle]

I've read lots of links, but only once did I find an explanation of how the recordfail feature is supposed to work. Late in the boot process, the scripts in /etc/rc2.d are run and one of them, S99grub-common on my Quantal, unsets the recordfail variable in the grubenv file. So, the idea is that if a system boots successfully, grub is happy to boot automatically next time. Now, if you have several installs and use a separate grub boot partition, independent of the installs, like I do, the recordfail isn't reset once it gets set. I have to mount my boot partition, and

sudo grub-editenv /media/boot/grub/grubenv unset recordfail

Since I'm maintaining my grub.cfg manually, I could rip out all that recordfail dreck, but if the default entry failed to boot and restarted the machine, I'd have a PC thrashing away indefinitely.
There's a new /etc/default/grub entry GRUB_RECORDFAIL_TIMEOUT which can be used, too. Just set it and /etc/grub.d/00_header uses it instead of -1 when generating grub.cfg. Hard to find because most of the variables that can be used are already in /etc/default/grub but commented out; maybe that's because I've customized mine.

Regards, John Little