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.
$ rpm -q grub grub-0.97-36.fc10.x86_64 ...let me know if other info is needed.
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> - 0.97-36 - Add force-chainloader patch from rstrode (rhbz #458576) * Wed Oct 08 2008 Peter Jones <pjones> - 0.97-35 - Add dep on newer gnu-efi. * Thu Jun 26 2008 Peter Jones <pjones> - 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.
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...
I can confirm that after reverting the last chainloader-timout patch, the timeout started to work again.
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.
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?
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.
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?
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...
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
Created attachment 322276 [details] grub.conf with timeout that doesn't work with the chainloader-timeout patch
Hello, > > Lubomir, do you also have a chainloader entry? No, I don't. See the attached grub.conf...
> > 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 :-)
> 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+.
> > 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.
I would like to agree with the suggestions in comment #14. An extra chainloader timeout is terribly confusing.
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?
This bug does that headless systems can't boot after upgrade. I really do think this is something that _must_ be fixed before release.
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;
I have built and tested the change I propose. It works as expected for me.
i'm okay with that type of patch, but it's Peter's call.
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.
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 ;-)
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.
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...
Should be fixed in grub-0.97-38.fc10, booty-0.106-1.fc10.
Tagged for final.
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?
You're right - the logic was inverted there. New build forthcoming. Moving to ASSIGNED until we get the fixed package built.
Yep, thanks for double checking that. Fix in 0.107-1 .
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?
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).
Created attachment 379505 [details] grub.conf file as it appears on this F12 i686 system installed through the LiveCD image (with a LiveUSB)