Red Hat Bugzilla – Bug 458576
No grub on multi-os/boot systems
Last modified: 2008-10-29 13:34:37 EDT
Description of problem:
So I upgraded to F10 via a clean install and I left Windows Vista alone (whats wrong with a couple of neat games and errr wanting to pass university eh?), but I noticed on boot & reboots that grub is dead (don't worry, the "Kernel is alive"). I am told that to get grub I need to press the Ctrl key, but this is a regression to a feature that Microsoft implemented with great displeasure back in the 1990s, and it's an ugly hack to make the process appear better to end users.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Boot Fedora 10 Alpha from a dual boot system
2. Go straight to jail^WFedora without a choice
A choice between Fedora and *
Please please _PLEASE_ fix this, it's driving me insane.
Yeah that behavior is just BROKEN .. please revert it.
I know its part of the "flicker free boot" experience, but it's not worth to make life harder for users.
Image the situation A dualboots between fedora and windows. He updates to F10 and wonders how to boot windows ... he is used to be prompted for what he wants to boot (which makes sense).
Or user B upgraded the kernel, but due to a stupid bug the new kernel does not boot on his box. No problem we keep two kernels installed by default for such cases .. oh wait user B does not know anything about the magic key "ctrl" he is supposed to press now.
I can extend the list with other scenarios, but I think this shows how broken that is.
What do we gain?
Nothing .... oh wait one screen flicker that don't really bother users is gone.....
(In reply to comment #1)
> What do we gain?
> Nothing .... oh wait one screen flicker that don't really bother users is
Exactly, and need I add that neither Windows (and I'm pretty sure Mac) isn't completely flicker free.
I don't know much about the actual feature, I'd think it would be reasonably easy to configure the new system to behave as desired.
At least I am using the first boot option 99 % of the time. I would have no problem pressing ctrl or F8 the few times I want to boot the Rawhide partition. If I didn't use Rawhide, I wouldn't need even that.
In the cases where Windows has automatically been added to the boot menu, it would probably be useful to automatically show the menu to the users, since a new user may otherwise miss the usefulness of the automatically added Grub entry if he can't find it.
I would appreciate the one less flicker at boot and the five seconds less boot time, but I understand the Grub manu may be essential to some users. But can't there be a reasonable middle ground? Maybe make the feature not used as default, but easy to opt in?
Even Windows Vista automatically shows it's (ugly) boot menu when there is more than one option available.
So you may want to do the same as a "fairer" default, or you can just ask in anaconda and let the user decide.
Flickerfree Boot: GRUB MENU OPTIONS
[ ] Silent (the Grub menu is not shown)
[*] Auto (the Grub menu is shown when there's more than one choice)
[ ] Verbose (Always show the Grub menu)
NOTE: ** press CTRL while booting to show the GRUB menu
(In reply to comment #4)
> Even Windows Vista automatically shows it's (ugly) boot menu when there is more
> than one option available.
> So you may want to do the same as a "fairer" default, or you can just ask in
> anaconda and let the user decide.
No we don't need any questions in anaconda that might confuse users.
We should simply default to "Auto" but it's pointless because after the first kernel update everyone will have 2 entries so just go back to how it was in F9 (always show).
(In reply to comment #4)
> Anaconda mockup:
> Flickerfree Boot: GRUB MENU OPTIONS
> [ ] Silent (the Grub menu is not shown)
> [*] Auto (the Grub menu is shown when there's more than one choice)
> [ ] Verbose (Always show the Grub menu)
(In reply to comment #5)
> No we don't need any questions in anaconda that might confuse users.
> We should simply default to "Auto" but it's pointless because after the first
> kernel update everyone will have 2 entries so just go back to how it was in F9
> (always show).
I actually like the mockup, but it'd be something for the "Advanced Options" screen not a default question.
I use dual-boot and love the fact that GRUB always asks me which OS, or Kernel to boot into. We should still be presenting this choice as the _default_. If anyone wants to get rid of the modest delay, make it easy to do so you don't have to edit grub.conf manually.
I really hope you change this behaviour.
Before someone starts talking about "you only have to press a key" here (like done in the blog posts / comments).
How is the user supposed to know about that?
Google for it after having a non booting kernel?
Find it out after reinstalling windows and loosing all his data, because he thought fedora just killed it? (which also will let said user stay away from linux ...)
We already had the hiddenmenu by default where it says "booting foo in X seconds, press any key to change" which is fine ... but removing this is to much.
All those who love to be asked by grub every time can just configure it ask.
(In reply to comment #9)
> All those who love to be asked by grub every time can just configure it ask.
Its about the default behavior not what can be configured see #1
Okay, a few questions
1) Can you attach your /etc/grub.conf ? What's the timeout value?
2) to get grub you don't need to press the ctrl key, you can press any key. ctrl (or shift or alt, etc) are convenient keys because you can normally hold them down at the bios screen instead of plying "guess the exact moment to hit the key" game that. But really any key (escape, space bar, enter, whatever) should work.
3) The intention was to prevent showing a screen that only matters in exceptional cases. Obviously in the dual boot case it does matter, so we may need to rethink things. One idea is to change the behavior if any the boot entries are chain loading.
4) I don't understand why this is assigned to plymouth. This is grub bug, so i'm reassigning.
I'll grab Peter and Kristian today if they're around and we can figure out how much work this will be to fix or revert.
(setting to NEEDINFO for the grub.conf)
I've added a TODO item to https://fedoraproject.org/wiki/Features/BetterStartup :
* Make sure grub patch doesn't mess up multi-os environments. See bug 458576. In particular we should probably add a new chain loader timeout config option with a reasonably high value (say 30 seconds) and use that timeout if there are any items in the configuration that chain load. The idea being we should always show the menu in that case.
If any one wants to jump in and work on the patch, help would be appreciated.
Otherwise, it's on the F10 TODO list and I'll work on it when it gets to the top of the list.
Created attachment 314315 [details]
Attached is the default grub.conf as generated by anaconda for my system.
So this highlights a couple of problems
1) we aren't defaulting to timeout=0
2) timeout=5 works like timeout=0 is supposed to work
Adding to F10Blocker because both the multi OS and the timeout bug are clearly regressions that should be fixed in F10.
Oh also: Ctrl is a really bad key to use for this sort of stuff in my experience, there are a few KVMs out there that have it set if you press Ctrl twice (or the keyboard is partly broken as well) it'll switch to a different machine. But yeah, not that important, but just thought I'd add that note.
we don't actually use ctrl. we use any key. (ctrl is just a convenient one since it doesn't fill up the keyboard buffer if you hold it down, you can use alt or shift or escape or whatever)
Would you consider it a similar issue when a new install to a multi-boot system writes a new grub.conf and fails to append, so the ability to multi-boot is lost until the grub.conf is edited?
Created attachment 318087 [details]
force menu if using chainloader
This forces the menu to show up if any of the entries in the file use the chainloader option.
attachment 318087 [details] also adds a "chaintimeout" analog to the "timeout" option which is used instead of timeout in the event that there are chain loading entries.
Created attachment 318088 [details]
Fix boot message
The other mentioned problem about timeout=5 being ignored was actually just a buglet in what got printed.
It was waiting 5 seconds, but wasn't letting the user know they could press any key to see the menu.
I believe anaconda writes out the default grub config, so I've cloned this bug as bug 464800 to address part 1 of comment 14
Created attachment 318127 [details]
Fix both boot messages
Matthias did a drive by patch review and noticed I missed a message in attachment 318088 [details].
This patches includes both messages if necessary.
Fixed in grub-0.36-1 .
Maintainer has this marked as fixed, if this still occurs in the Preview, please reopen.