Bugzilla – Bug 347236
[feature-request] Please introduce delays into graphical GRUB, improve Serial and KVM
Last modified: 2008-04-25 13:06:08 UTC
Hi, Currently, The Graphical GRUB (aka gfxboot) is loaded immediately after BIOS, which is beautyful and makes positive user experience, but there are cases where it makes a problem. Problems, that gfxboot arises: 1. Serial (COM) port - I would like to be able to work from Serial port. Since it works only in text-mode, it is not compatible with Graphical GRUB. In the future, I would like to be able to install openSUSE via Serial (useful for Headless systems). 2. KVM, The Open-Source Kernel-based Virtual Machine, which is now part of Linux kernel and integrated into openSUSE 10.3. KVM doesn't work with graphical GRUB, because KVM is dependent on Intel's Vanderpool Technology (VT) hardware virtualization extensions, which do not support big real mode. One possible solution is to disable gfxboot, but this will hurt normal users, and overall openSUSE experience. Another possible solution is: that introducing some delay (5 seconds) will be enough for those usecases. That is: after BIOS starts, make a timeout in text-mode. If the user doesn't presses any key during that time perioud, then gfxboot boots, otherwise if the user pressed Enter or Space, then text-mode GRUB will show up. Of course, that delay must be configurable in the GRUB menu config file. Please introduce some delay into default Graphical GRUB bootloader (gfxboot). -Technologov, 10.Dec.2007.
Another corner use-case, in which introducing delays into GFX GRUB will help to solve a real-world problem: 3. TV: most Televisions support 640x480 resolution, so it is very hard to install an OS via GRUB that way, unless you remember all the choices. NOTE: This use case came from: Dominique Leuenberger -Technologov
ad 1) The serial port thing needs a bit work; but I've got similar requests already and it's certainly interesting to do. I'd just need the time. ad 2) It's not big real mode but indeed kvm has a bit of a problem with real mode/protected mode switches as intel's vt makes it really tricky for programmers. gfxboot in 11.0 has a workaround. ad 3) The 640x480 request is really rare. I've only heard of one or two corner cases so far. gfxboot in fact _has_ a 640x480 fallback layout in case 800x600 is not available. So if your BIOS would say that 800x600 is not supported, you'd get the lower res (some onboard graphics that reserve very little video memory in fact do this). Unfortunately the typical Video BIOS doesn't care at all about display capabilities. That said, currently the only way to go straight into text mode is to hold down SHIFT during bootloader startup.
With an openSUSE server, I had a similar problem a few times, because the attached monitor was not able to display the VGA mode the graphics card supported and which was set by GRUB.
>ad 1) The serial port thing needs a bit work; but I've got similar requests >already and it's certainly interesting to do. I'd just need the time. The so-called similar request, was also opened by me. Bug #347240. >ad 2) It's not big real mode but indeed kvm has a bit of a problem >with real mode/protected mode switches as intel's vt makes it really >tricky for programmers. gfxboot in 11.0 has a workaround. Link please, where it explains about the 11.0 workaround. Why "ad" ? "ad" is a short-word for advertisement, while I told only facts, not "ads". This request about delays into GFX GRUB are just an optional solution to the several problems users have with openSUSE 10.3. Better solutions might exist. Bottom line: if all 3 problems can be fixed in better ways, then we might consider closing this bug as WONTFIX. -Technologov, 24.01.2008
You can look the kvm thing up in bug 307194. The meaning of 'ad' depends on what language you have in mind.
BTW, I didn't know about bug 347240. So you are not alone.
Update: As Wolfgang Woehl from the mailing list rightly pointed out, making this delay default can hurt normal user experience of the already long boot process. So I came up with a better idea: introduce the delays only to CD/DVD bootloaders, but the final installed OS on Hard Disk should work the same. (i.e. with GFX bootloader) This way, power users will be able to make custom installation to custom hardware, and will have an option to disable graphical boot during setup for those custom cases. This will have me happy, and will not hurt normal user experience in any way. (except few more second boot from install DVD) -Technologov, 02.02.2008.
I actually think that the (newly learnt by me)option to press SHIFT during grub initialization is enough to solve this. IT should prominently be marked in the wiki/readmes (and printed manual) on possible solutions should the graphical menu fail to start. Then I don't see much reason for a delay in the loader itself.
OK, considering the fact that problem 2 is fixed in GFX GRUB (KVM works now), other problems can be resolved by documenting this "shift" feature. Please close this bug _after_ the necessary documentation was added. but where? - Quick Start guide? or Lessons for Lizards ? -Technologov
update: There is a customer with VIA Eden platform, that GFXboot loads initially into text mode, but unfortunately when he presses enter, GFX GRUB loads, which is incorrect. When GRUB loads into text-mode, there must be an option to load Yast (setup) into Text mode too. -Technologov
This option exists as boot option and is called "textmode=1" ;-) See http://en.opensuse.org/Linuxrc for more boot options.
Hi people ! I have a new usecase: 4. Qemu/KVM has the new option of doing text (ncurses) based rendering of the OS. (it is related to case 2, but not the same) Unfortunately, current openSUSE (10.2/10.3/11.0-Alpha2) always use a graphical GRUB, which makes it impossible to install openSUSE this way. There is no time to press "shift" key. Please make it like Windows XP's five points when booting from CD/DVD: BIOS -> "....." (5 seconds of wait) -> load GFX GRUB (if no key was pressed) -or- -> Load TextMode GRUB (if any key was pressed). It is both much more obvious way than "shift" is(current workaround), plus it works it more corner cases, where "shift" fails.. To reproduce corner case 4, you will need latest Qemu(CVS) or KVM (63+). /usr/local/bin/qemu-system-x86_64 -curses -cdrom /SUSE-11.0-Alpha2.iso -Technologov, 6.3.2008.
Well, qemu shouldn't offer graphics modes, when it can't render them. gfxboot will be skipped automatically then.
Yes, I agree, but it's not that simple, because it emulates standard Cirrus Logic video card. Alternative video card can be developed, but it's complex and long process. But my solution for the bootloader is a real fix that covers a many possible problems + it's more intuitive and user-friendly, than "shift". -Technologov, 6.3.2008.
I'm not convinced about adding a delay. I'll leave it as it is.