Description of problem:Time to display grub menu isn't long enough with current timeout value. Version-Release number of selected component (if applicable):grub-0.97-62.fc13.x86_64.rpm How reproducible:Always Steps to Reproduce: 1.Install rawhide (or any Fedora version with grub) 2.reboot computer 3.watch grub display Actual results:For example, if timeout is only set for 5, you *may* see the grub diplay (options?) for 3 seconds, if that. Expected results:You need to give the timeout at least 2-3 seconds *more* than you originally want, so you have the fully allotted time at the grub menu. Additional info:I believe others have mentioned/argued some different reasons so will let them add their info.
I vote for this change - my BIOS seems to "eat" some early keypresses, so the Shift method is not reliable
The default grub timeout is 0. When there are problems after a new installation, often, extra parameters need to be added or removed from the kernel line, e.g., nomodeset, or perhaps remove rhgb quiet, or, change the runlevel from its default of 5. With the 0 timeout, while it is possible, if, for one reason or another, the keypresses don't work, or if the user mistimes hitting the key, the machine boots, possibly fails, possibly failing without any indication to the watcher of what's wrong. A small timeout, even of a few seconds, gives the user opportunity to add or remove any necessary parameters. Like Karel, I didn't find the shift method reliable (USB keyboard in a KVM).
I'm +1 on this, as discussed on the mailing list. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
This makes no sense increase the boot time for the many for the few that own broken or buggy HW.. First of all we should be focusing on trying to fix the underlying issue that cause the problem which makes the end user(s) press "anykey" @ boot up in the first place instead of working around it by increasing the default grub timeout. Secondly let's not forget the fact that the end user will need to edit grub.conf to add his workaround there in the first place so he can just as well increase the timeout while he's @ it.. -1 -- Fedora QA https://fedoraproject.org/wiki/QA
Unfortunately, it is impossible to anticipate what may, on some hardware or another, cause a system to fail to boot, especially when the default is graphic mode. Take a look at the forums and see what a large number of users experience. Re the end user editing their grub.conf--the problem is, frequently, that they can't get that far. Ergo the original suggestion.
/+1 (scott) Even a short message "press any key to enter boot menu" + 1-2 seconds wait will go a long way to help users recover from a "KMS killed my machine" problem. - Gilboa
When something is wrong, it would be useful to suppress the "hiddenmenu" option and force a delay long enough to allow a user to see the menu and have an opportunity to press some key to stop the default boot operation. When everything is OK, it is desirable to boot quickly (if grub has not been configured to do something else). In particular, we want the default grub configuration to be close to "boot quickly" so users without problems have no real need to modify grub's configuration in order to obtain a faster boot. How close is this to detection by grub of a "clean shutdown" condition? If grub believes the system was gracefully shut down (some note was left under a convenient rock, so to speak) grub follows its configuration directions. If there is no indication of successful, orderly shutdown, grub can then use some "unusual event" protocol that forces a boot delay and insures the boot menu is displayed.
I think it would be great if we could have Anaconda install grub.conf with a short timeout of say 1-2 seconds so that users do have the chance to hit a key if needed, and then have Firstboot change that timeout to 0 once the machine configuration is complete. If the user can complete Firstboot, we can assume that the hardware is at least in semifunctional state and they will be able to get back into the OS and modify grub.conf if needed.
Even a single second delay is better then not giving users instant access to the grub menu. I know that I like playing with boot params when I have an installation on another partition or hard disk. I also occasionally kill my install and need to boot to runlevel 1 or 3. Of course I make this change as soon as I do an install, but I feel that it should be there by default, at least for one second.
Since installing F11 and now 12 the first thing I do is edit grub.conf and increase the time out to 12 seconds. It's generally much longer than I need, but 0 doesn't work for me at all. I think at least 3 seconds should be a minimum. Why are there 3 kernels available when with a 0 timeout you only get to boot the most recent kernel? (I'm not suggesting just 1 kernel, sometimes you have to go back to a previous one if a new one has problems...) otoh, why should I have to remember to edit grub.conf right after I boot to a new Fedora install?
+1 for a 1-2 second delay.
I agree the 0 sec delay is wrong, at least until you work out how to offer a 'safe mode' restart option if the previous session didn't boot or shutdown cleanly.
I also say +1 for a 1-2 second delay.
The first thing I do is change the delay when installing. Luckily I have been able to that. For those who have problems, a 0 timeout is problematic. I understand that shaving 1 or 2 seconds off of boot time is a selling point, but, I'd rather wait the extra time and not have to use rescue mode in case of a problem. +1 for a 1-2 second delay.
Don't forget to vote using the vote link at the top, rather than just posting +1s :)
Agree to increasing the timeout for all the reasons mentioned. Boot time is easily modified and who are we in a race with anyhow? Shaving 2 seconds doesn't mean much when you're unable to boot due to an error.
(In reply to comment #4) > This makes no sense increase the boot time for the many for the few that own > broken or buggy HW.. > > First of all we should be focusing on trying to fix the underlying issue that > cause the problem which makes the end user(s) press "anykey" @ boot up in the > first place instead of working around it by increasing the default grub > timeout. > > Secondly let's not forget the fact that the end user will need to edit > grub.conf to add his workaround there in the first place so he can just as well > increase the timeout while he's @ it.. > > -1 > > > -- > > Fedora QA > https://fedoraproject.org/wiki/QA Poor response, ill thought out. The few seconds concerned do not cause any problem. It is not a race. A five second timeout would be an appropriate setting.
gallagher: the vote totals are more or less totally ignored at present. the major problem with them is everyone has 100 votes they can split as they like, and there's no guidelines for how votes should be split, so it's hard to derive much meaning from the vote totals... -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
When I have a sick server and I need GRUB Splash, this bug actually is elevated one level....I need that decision time! Linux/UNIX is known for empowering the administrator. The "other" OS does everything under the covers and drives us crazy. Lets not try and turn Fedora into the "other" OS AKA "easy to use until it breaks..." If your OS is stable, then this costs you 5 seconds a few times a year ==nothing If you OS is unstable, the 3 seconds we had were priceless to get into grub. If you are using it as a desktop, windows takes so long to boot we could afford 30 seconds for GRUB, and still be ahead. Give this 15 year administrator 3 seconds face time (5 seconds total) back onto every reboot, so that I have one more powerful tool easily available when crisis hits. Putting time=0, saving 4 seconds is like the guy changing lanes every 50 feet during rush hour. The overall savings is negligable. But when bozo crashes, it slows everyone down for hours.
+1 If this were a race to see who could produce the first 10 second booting Linux, then I might understand the logic, but it's not. I'm all in favour of measures/improvements that reduce boot time but chopping 2-3 seconds from the GRUB boot timeout reminds me of biting off your nose to spite your face. Please revert to a sensible default timeout.
Why are people going on about 5 second delays? One single second is sufficient enough time to allow a key press to enter the grub menu. Anything additional is unneeded. I am all for access to the menu without having to set the timeout yourself. That is how I want my system to run as I have no physical security risks. Those with physical security risks can set it to zero accordingly but for the majority of users its better to have a single second between grub loading and it booting the kernel.
williamson: so voting here is a bit like voting in afghanistan elections, pointless. I think the problem here is some people can press a key during the bios boot which gets recognised and some can't, I can't.
(In reply to comment #23) > williamson: so voting here is a bit like voting in afghanistan elections, > pointless. well, not that exactly - although vote count is a bit meaningless, still you can easily see the number of people voting for changing this, which is a bit clearer than going through the comments and counting +1, -1 and those irrelevant like this one
+1 here ... We definitely need a grub timeout greater than zero seconds. I found myself in the situation this week with a Fedora 12 machine that would not boot, and the inability to access grub made the recovery much more complex than it should have been. In addition to the longer timeout we need visibility of the grub menu rather than it being hidden, or at the least some sort of visual prompt that a key can be pressed to access it. The Anaconda install already asks to set a grub password. Anyone setting up a server will do this (or *should* do this) and then there is no risk of someone being physically at the terminal when the grub menu appears. Can the option to unhide the grub menu be added to Anaconda? I don't see what there is to gain from removing all grub screen time, personally it makes no difference to me whether my computer is taking 30 or 35 seconds to boot.
just a quick note - there was a guy at FUDCon who had a problem (turned out to be caused by a kernel update writing a duff initramfs) that we needed to get into grub to diagnose. It was very difficult; certainly holding down a key while the system was booting wasn't enough. It seemed to need the key to be pressed at a _very_ specific point in the boot sequence - the window was very small. We usually had to reboot about five times before we actually nailed it. I really think the assumption that it's easy to get into grub on all (or even 'most') systems even with 0 timeout is not correct. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
After a couple of F13 test installs and experiencing the new 0 setting in grub, it sucks. A cursor just sits there and nothing happens for few seconds, then it finally starts to boot. But you have no idea what is going on or if it's really working or what. This setting needs to be set for at least 3 seconds, and if your at the keyboard, you can just hit enter if you want it to boot faster than that.
+1 on 1-3 seconds. Personally, I'd like 1 second, but a novice would have a hard time catching it in my opinion.
Well, the timeout is currently 0 for all non-serial, non-multiboot installs. If you're doing serial or have multiple operating systems installed, it's five seconds. This was originally set up as part of the kernel modesetting/plymouth features sometime around F10 (https://fedoraproject.org/wiki/Features/KernelModesetting). If you would like to see this change, please discuss it at a distribution-level and then we on anaconda can do our specific piece later. Since this affects the whole bootup experience, it just seems wise to discuss it in a larger setting than a component-specific bugzilla. I'm closing as WONTFIX only on that basis. Don't take it as an offence or that we'll never change this behavior. I'm just not willing to fix it until there's distribution buy-in. Thanks.
When was the 5 seconds for multi OS's (Win 7) suppose to take place? Don't think I've seen it as of yet. Might try test install over the weekend to see what happens.
Anaconda 13.42, which is in RC3. It'll only change in a new install, we didn't implement anything to add a timeout to an existing install. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Yes it did work. I did a test install this morning with dual boot (win 7) system and grub was set for 5 seconds.
(In reply to comment #29) > If you would like to see this change, please discuss it at a distribution-level > and then we on anaconda can do our specific piece later. Since this affects > the whole bootup experience, it just seems wise to discuss it in a larger > setting than a component-specific bugzilla. hm, isn't that kind a Catch 22? http://lists.fedoraproject.org/pipermail/test/2009-November/087247.html or what "larger setting" do you mean?