This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 541315 - Increase grub timeout
Increase grub timeout
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
13
All Linux
low Severity low
: ---
: ---
Assigned To: Anaconda Maintenance Team
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-11-25 08:49 EST by Mike Chambers
Modified: 2010-05-18 06:47 EDT (History)
24 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-05-14 11:13:04 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Mike Chambers 2009-11-25 08:49:47 EST
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.
Comment 1 Karel Volný 2009-11-25 09:50:26 EST
I vote for this change - my BIOS seems to "eat" some early keypresses, so the Shift method is not reliable
Comment 2 Scott Robbins 2009-11-25 10:14:14 EST
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).
Comment 3 Adam Williamson 2009-11-25 12:00:11 EST
I'm +1 on this, as discussed on the mailing list.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 4 Jóhann B. Guðmundsson 2009-11-25 12:10:31 EST
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
Comment 5 Scott Robbins 2009-11-25 13:01:52 EST
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.
Comment 6 Gilboa Davara 2009-11-25 13:17:15 EST
/+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
Comment 7 Richard Ryniker 2009-11-25 17:32:45 EST
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.
Comment 8 Stewart Adam 2009-11-26 00:16:41 EST
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.
Comment 9 Kevin 2009-11-26 02:13:53 EST
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.
Comment 10 Cia Watson 2009-11-26 02:46:47 EST
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?
Comment 11 leigh scott 2009-11-26 05:14:15 EST
+1 for a 1-2 second delay.
Comment 12 J Gallagher 2009-11-26 06:25:17 EST
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.
Comment 13 Glenn Johnson 2009-11-26 07:00:33 EST
I also say +1 for a 1-2 second delay.
Comment 14 GoinEasy9 2009-11-26 13:49:57 EST
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.
Comment 15 Ky Ryder 2009-11-26 14:08:04 EST
+1 for a 1-2 second delay.
Comment 16 J Gallagher 2009-11-26 15:34:31 EST
Don't forget to vote using the vote link at the top, rather than just posting +1s

:)
Comment 17 Bob Agel 2009-11-26 20:38:52 EST
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.
Comment 18 Alan Bartlett 2009-11-27 08:56:04 EST
(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.
Comment 19 Adam Williamson 2009-11-27 13:25:01 EST
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
Comment 20 Dan Hyatt 2009-11-27 14:12:58 EST
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.
Comment 21 Ned Slider 2009-11-27 15:48:10 EST
+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.
Comment 22 Kevin 2009-11-29 04:35:42 EST
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.
Comment 23 J Gallagher 2009-12-01 15:50:20 EST
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.
Comment 24 Karel Volný 2009-12-02 04:48:32 EST
(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
Comment 25 Ben Stokes 2009-12-15 11:36:05 EST
+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.
Comment 26 Adam Williamson 2009-12-16 19:23:31 EST
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
Comment 27 Mike Chambers 2010-03-14 08:44:30 EDT
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.
Comment 28 Jon Robison 2010-05-11 09:44:48 EDT
+1 on 1-3 seconds. Personally, I'd like 1 second, but a novice would have a hard time catching it in my opinion.
Comment 29 Chris Lumens 2010-05-14 11:13:04 EDT
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.
Comment 30 Mike Chambers 2010-05-14 16:32:48 EDT
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.
Comment 31 Adam Williamson 2010-05-15 10:40:01 EDT
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
Comment 32 Mike Chambers 2010-05-15 11:37:07 EDT
Yes it did work.  I did a test install this morning with dual boot (win 7) system and grub was set for 5 seconds.
Comment 33 Karel Volný 2010-05-18 06:47:36 EDT
(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?

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