This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 468526 - grub ignoring timeout and hiddenmenu settings if using chainloader
grub ignoring timeout and hiddenmenu settings if using chainloader
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: grub (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Peter Jones
Fedora Extras Quality Assurance
: Regression, Reopened
Depends On:
Blocks: F10Blocker/F10FinalBlocker
  Show dependency treegraph
 
Reported: 2008-10-25 12:21 EDT by Jeff Layton
Modified: 2014-06-18 03:38 EDT (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-11-18 21:03:12 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
grub.conf (1.06 KB, text/plain)
2008-10-25 12:21 EDT, Jeff Layton
no flags Details
grub.conf not respecting timeout setting (1.46 KB, text/plain)
2009-05-17 14:18 EDT, Martin Klapetek
no flags Details
grub.conf file as it appears on this F12 i686 system installed through the LiveCD image (with a LiveUSB) (963 bytes, text/plain)
2009-12-20 13:37 EST, Gian Paolo Mureddu
no flags Details

  None (edit)
Description Jeff Layton 2008-10-25 12:21:54 EDT
Created attachment 321514 [details]
grub.conf

Grub is ignoring the timeout and hiddenmenu settings in grub.conf. When booting the menu pops up immediately and just sits there until an entry to boot is selected.
Comment 1 Jeff Layton 2008-10-25 12:50:42 EDT
$ rpm -q grub
grub-0.97-36.fc10.x86_64

...let me know if other info is needed.
Comment 2 Lubomir Bulej 2008-10-31 06:34:18 EDT
When I downgraned to grub-0.97-33.fc9.x86_64, the timeout started to work again. Looking at the changelog between the two, the 36 release adds the following:

* Thu Oct 23 2008 Peter Jones <pjones@redhat.com> - 0.97-36
- Add force-chainloader patch from rstrode (rhbz #458576)

* Wed Oct 08 2008 Peter Jones <pjones@redhat.com> - 0.97-35
- Add dep on newer gnu-efi.

* Thu Jun 26 2008 Peter Jones <pjones@redhat.com> - 0.97-34
- Add keystatus patch from krh.


Of those patches, I highly suspect the keystatus patch, but I have not tried to revert it and rebuild grub.
Comment 3 Jeff Layton 2008-10-31 06:51:39 EDT
I was able to get it to work by reverting to -35, so I'm more suspicious of the force-chainloader patch. From a quick look at the patch there it looks like it mucks with the timeout settings so I think that's probably where the breakage is.

cc'ing Ray since he did the patch there...
Comment 4 Lubomir Bulej 2008-10-31 06:57:46 EDT
I can confirm that after reverting the last chainloader-timout patch, the timeout started to work again.
Comment 5 Ray Strode [halfline] 2008-10-31 09:49:35 EDT
hmm, it sounds like grub thinks you have an entry with a chainloader line in it, so then:

+                 if (builtin->flags & BUILTIN_SHOW_CHAIN_MENU)
+                   {
+                     show_menu = 1;
+                     grub_timeout = grub_chaintimeout;
+                   }
+

runs and since you don't define a chaintimeout it sits indefinitely.
Comment 6 Ray Strode [halfline] 2008-10-31 10:13:12 EDT
Hmm, I can't reproduce this bug with the grub.conf from attachment 321514 [details] .

Lubomir, can you attach your grub.conf?

Can both of you guys try adding

chaintimeout=5

and see if that make the menu go away in 5 seconds?
Comment 7 Jeff Layton 2008-10-31 14:17:19 EDT
Yes. I have a chainloader entry, and adding chaintimeout works around this problem.

So now, in addition to "timeout" we have "chaintimeout"? That seems very confusing. IMO, a better solution would be to have a new grub option that makes grub skip displaying the menu (maybe just a new option for "hiddenmenu"?).

I'm not sure what the best solution here is, but this is going to be confusing for anyone who dual boots.
Comment 8 Ray Strode [halfline] 2008-11-01 14:44:04 EDT
Hi Jeff,

If you have a chainloader entry then you're getting the expected behavior.

See bug 458576 for details.

Lubomir, do you also have a chainloader entry?
Comment 9 Jeff Layton 2008-11-01 19:48:03 EDT
Fair enough. I suppose it's your call, but for the record...

It doesn't make much sense to me to have different behavior for the menu based on whether there is a chainloader entry. I think this will be confusing for users. It seems like there may be better ways to make not displaying the menu be default behavior but to still allow the timeout config option to work as it traditionally has...
Comment 10 Ray Strode [halfline] 2008-11-02 15:52:49 EST
i'm open to ideas.  What we want by default is:

1) Users with windows to always get a menu for 30 seconds or so
2) Users without windows to not see anything at all unless they hold down a key
Comment 11 Lubomir Bulej 2008-11-03 03:37:05 EST
Created attachment 322276 [details]
grub.conf with timeout that doesn't work with the chainloader-timeout patch
Comment 12 Lubomir Bulej 2008-11-03 03:38:53 EST
Hello,

> 
> Lubomir, do you also have a chainloader entry?

No, I don't. See the attached grub.conf...
Comment 13 Lubomir Bulej 2008-11-03 03:40:18 EST
> 
> No, I don't. See the attached grub.conf...

Duh. I saw "chainloader entry" but read "chainloader timeout"... So let's try again: yes, I do have a chaniloader entry in grub.conf :-)
Comment 14 Jeff Layton 2008-11-03 06:42:44 EST
> i'm open to ideas.  What we want by default is:
> 
> 1) Users with windows to always get a menu for 30 seconds or so
> 2) Users without windows to not see anything at all unless they hold down a key

First, a question...

Is there any mode-switch performance penalty to printing the "Press esc for menu..." lines from hiddenmenu if you use the default text mode to print them. i.e. you could only switch to a splashimage screen when you go to display the menu.

If there is a penalty here, then my suggestion would be to back out the chaintimeout patch and change the behavior of hiddenmenu. Rather than have it print out "Press esc for menu..." line, just have it not print anything at all, and maybe change it to display the menu when you hit any key and not just esc.

When you go to set up grub from the installer, enable "hiddenmenu" for any grub config that doesn't have a chainloader entry. If someone adds one later, it's their responsibility to disable "hiddenmenu".

Another idea might be to instead add new options to hiddenmenu. Something like:

hiddenmenu --invisible --anykey

...that makes the "Press esc key..." line not be printed and allows any key to break into the menu. Then just set up grub.conf with that when there isn't a chainloader entry defined.

This approach seems more intuitive to me. As long as we set up grub.conf for the desired behavior at install time, I see no problem with placing the burden of later configuration on whoever is editing the grub.conf.

We have to also look at this another way -- there's nothing really special about chainloader entries. It's possible to have other entries that use grub's "normal" boot method and we want to allow people to be able to access them. We even ship at least one of them -- memtest86+.
Comment 15 Lubomir Bulej 2008-11-03 07:46:55 EST
> 
> When you go to set up grub from the installer, enable "hiddenmenu" for any grub
> config that doesn't have a chainloader entry. If someone adds one later, it's
> their responsibility to disable "hiddenmenu".
> 
> Another idea might be to instead add new options to hiddenmenu. Something like:
> 
> hiddenmenu --invisible --anykey
> 
[...]
> We have to also look at this another way -- there's nothing really special
> about chainloader entries. It's possible to have other entries that use grub's
> "normal" boot method and we want to allow people to be able to access them. We
> even ship at least one of them -- memtest86+.

I like this approach and I also think that the fact that a user has a chainloader entry has nothing to do with grub -- grub should provide the means, and the installer should set the policy. Changing default grub behavior if there is a chainloader entry is IMO step in the wrong direction. There is only one menu and there should be only one menu timeout definition.

I would also like the hiddenmenu options :-) 

This adds features to grub without burdening them with special cases.
Comment 16 Danny Baumann 2008-11-05 03:08:00 EST
I would like to agree with the suggestions in comment #14.
An extra chainloader timeout is terribly confusing.
Comment 17 Ray Strode [halfline] 2008-11-05 10:05:41 EST
So one low impact change we could make (that wwoods suggested) is making

chaintimeout inherit timeout if no chaintimeout is specified.

Whether we do that or something like comment 14 this late in the game, I'm not sure.

Peter, what's your thoughts?
Comment 18 Mads Kiilerich 2008-11-10 18:41:37 EST
This bug does that headless systems can't boot after upgrade. 

I really do think this is something that _must_ be fixed before release.
Comment 19 Mads Kiilerich 2008-11-10 19:28:46 EST
My system do have a chainloader boot entry. (On some servers that is a must to have in order to be able to access or update firmware and get hardware support.)

I propose the following (untested!) patch. The intention is that chaintimeout only should be used if it has been set in grub.conf. That is almost the same as wwoods "chaintimeout inherit timeout if no chaintimeout is specified" in comment 17, only even more safe and with a minimal and thus low-risk change. The new chainloader-magic does then not silently take action in on existing systems - and IMHO that is essential when new functionality is added to the boot loader. 

--- stage2/stage2.c.org	2008-11-11 01:10:59.000000000 +0100
+++ stage2/stage2.c	2008-11-11 01:11:37.000000000 +0100
@@ -1038,7 +1038,7 @@
 		    /* Unknown command. Just skip now.  */
 		    continue;
 
-		  if (builtin->flags & BUILTIN_SHOW_CHAIN_MENU)
+		  if ((builtin->flags & BUILTIN_SHOW_CHAIN_MENU) && (grub_chaintimeout != -1))
 		    {
 		      show_menu = 1;
 		      grub_timeout = grub_chaintimeout;
Comment 20 Mads Kiilerich 2008-11-11 05:20:14 EST
I have built and tested the change I propose. It works as expected for me.
Comment 21 Ray Strode [halfline] 2008-11-11 09:47:51 EST
i'm okay with that type of patch, but it's Peter's call.
Comment 22 Jeff Layton 2008-11-11 10:04:45 EST
FWIW, -1 on this whole scheme. It adds non-intuitive behavior to grub that isn't obviously fixable by just changing grub.conf. It also makes the grub menu behavior dependent on the type of entries that happen to be in grub.conf/

A better solution would be to have the installer build a grub.conf by default that gives you effect you want here (no mode switches), but have existing grub.conf files still work as they always have before.
Comment 23 Mads Kiilerich 2008-11-11 10:19:34 EST
Jeff, FWIW I agree on the -1. But f10 is close and it is too late to advocate major changes.

The patch I propose do what you request: restores the old behaviour for old grub.confs without chaintimeout, and only new booty-generated with chaintimeout setting will get the new undocumented non-intuitive behaviour ;-)
Comment 24 Lubomir Bulej 2008-11-11 12:02:05 EST
Again, I would like to support what Jeff proposes - the change clutters grub with context-dependent behavior to achieve something that can be achieved by the installer.

> Jeff, FWIW I agree on the -1. But f10 is close and it is too late to advocate
> major changes.

I can understand that. The problem is that the change was somewhat invisible for long time. Even though I run rawhide all the time, I only update grub (in /boot) only once in a while and suddenly things stopped working.

> 
> The patch I propose do what you request: restores the old behaviour for old
> grub.confs without chaintimeout, and only new booty-generated with chaintimeout
> setting will get the new undocumented non-intuitive behaviour ;-)

It still adds the chaintimeout stuff to grub, which is unnecessary, and even if better solution (proposed by Jeff) is actually adopted later, the chaintimeout stuff would have to remain in grub for compatibility with earlier installed grubs...

So it's two things now -- your patch gives me back the old behavior, which is fine with me, but doesn't fix cluttering grub with unneeded stuff, which is, well, someone else's call.
Comment 25 Jeff Layton 2008-11-12 15:38:49 EST
Yep, we'll have to live with "chaintimeout" for a long time after this if this patch stays in. Do we really want to carry that in fedora's grub for the forseeable future?

IMO, I think we need to step back a minute. This whole change was made to reduce mode switches at boot time. While that's a laudable goal, an extra mode switch isn't generally fatal.

If time before release is the issue, then I suggest we back these changes out of grub for now. A new solution can be designed for F11 (or sooner possibly). That seems like a better solution to me than what's there today...
Comment 26 Bill Nottingham 2008-11-18 17:00:12 EST
Should be fixed in grub-0.97-38.fc10, booty-0.106-1.fc10.
Comment 27 Jesse Keating 2008-11-18 17:47:33 EST
Tagged for final.
Comment 28 Mads Kiilerich 2008-11-18 17:54:50 EST
The obvious question is: How has it been fixed?

For the record, the changelogs gives the answer:

- Remove chainloader timeout patch; fixing it in booty instead in order to
  address rhbz#468526 .

Looks like a good resolution. Thanks!

But ... the change from 105 to 106 has:

     def write(self, instRoot, fsset, bl, langs, kernelList, chainList,
             defaultDev, justConfig, intf):
+        if self.timeout is None and not chainList:
+            self.timeout = 5
+

FWIW I don't understand the "not chainList". Why the negation? I would expect a timeout to be enforced if there _is_ anything in chainList?
Comment 29 Will Woods 2008-11-18 20:41:34 EST
You're right - the logic was inverted there. New build forthcoming.

Moving to ASSIGNED until we get the fixed package built.
Comment 30 Peter Jones 2008-11-18 21:03:12 EST
Yep, thanks for double checking that.  Fix in 0.107-1 .
Comment 31 Martin Klapetek 2009-05-17 14:18:26 EDT
Created attachment 344342 [details]
grub.conf not respecting timeout setting

Hi,

my grub-0.97-38.fc10.x86_64 still doesn't respect the timeout correctly. The attached grub.conf has timeout=10, but there is no timeout in the menu, the menu just appears and sits there until I select which entry to run. And if I uncomment the chaintimeout=10, then it immediately runs the first entry, no timeout, no reaction to keypress, the menu just blinks in and out. 

So how should I change the conf options so the menu will stay for 10 secs and then will run the first entry?
Comment 32 Gian Paolo Mureddu 2009-12-20 13:34:51 EST
I just installed Fedora 12 i686 onto this HP Mini 110, and I have exactly the same behavior as already profusely described in this bugzilla:

Timeout not taking effect, hiddenmenu not taking effect, and GRUB boot lists sitting there for ever until a boot option is selected.

The GRUB version I have seen this with is grub-0.97-62.fc12.i686, the strangest thing is that in my main laptop system I also have Fedora 12, only x86_64 instead of i686, same GRUB version and I do not see this happening there... Reading through this I thought of adding the chiantimeout option to the grub.conf, but I'm not sure if it will work.

Also, since this is a netbook, I installed through a LiveUSB rather than using the installation images, which may be why I'm getting this (especially if there has been any changes to Anaconda and how does it configure GRUB). To the best of my knowledge, GRUB is installed onto the MBR, I do NOT have a chainloader option in my grub.conf (as I nuked Windows 7 off this system).
Comment 33 Gian Paolo Mureddu 2009-12-20 13:37:59 EST
Created attachment 379505 [details]
grub.conf file as it appears on this F12 i686 system installed through the LiveCD image (with a LiveUSB)

Note You need to log in before you can comment on or make changes to this bug.