Red Hat Bugzilla – Bug 308371
f8t3 LiveCD " vga=..." boot loader parameter failure
Last modified: 2009-01-08 23:54:48 EST
Description of problem: Display resolution remains 800x600 pixels
instead of reconfiguring to the requested resolution.
Version-Release number of selected component (if applicable):
also, the network install version of Rawhide of 2007-09-23
vmlinuz of size 2009728, dated 2007-09-23
and many previous kernels over the past several months
Solidly. Has failed every time in tens of attempts.
Steps to Reproduce:
1. Boot, in the grub menu select the entry for "Run from image",
add "vga=0x799" to the end of the "kernel vmlinuz" line.
2. Observe how the desktop or installer screens are still rendered at
800x600 resolution, instead of the requested 1600x1200.
The f8t2 LiveCD responds to an attempt to use the boot loader parameter
vga=0x799 (via using the [TAB] key on the initial boot choice screen
to edit the "Run from image" entry to add this parameter to the end of
vmlinuz initrd=initrd.img ro quiet
root=CDLABEL=Fedora-8-Test-2-Live-i686 rootfstype=iso9660 liveimg
- - -
Undefined video mode number 799
Press <ENTER> to see video modes available, <SPACE> to continue, or wait 30 sec
[<ENTER> displays something similar to: ]
0 0F00 80x25 VGA
1 0F01 80x50 VGA
2 0F02 80x43 VGA
3 0F03 80x28 VGA
4 0F05 80x30 VGA
5 0F06 80x39 VGA
6 0F07 80x60 VGA
[... selecting a choice to scan for additional modes merely made the
screen flash for a couple of minutes, but no additional choices were
- - -
If one tries vga=799, the only difference is "Undefined video mode number 31f"
This choice of modes is quite different from those shown on e.g.:
and other places VESA video modes (or VGA codes) are documented.
Configure the display as documented, i.e. to 1600x1200 32-bit color,
rather than starting X / running Anaconda in 800 x 600 resolution.
After installing the kernel-doc.noarch package, one can read in:
<mode> here is either an integer (in C notation, either
decimal, octal, or hexadecimal) or one of the strings
"normal" (meaning 0xFFFF), "ext" (meaning 0xFFFE) or "ask"
(meaning 0xFFFD). This value should be entered into the
vid_mode field, as it is used by the kernel before the command
line is parsed.
Messageboxes with fixed position cannot be dragged into a screen
location where they can be read, navigating to command buttons that
are not displayed in a visible screen location ranges from high-risk
to impossible, etc. when other bugs
interfere. The "vga=..." parameter should be a solid
alternative when the other automatic assumptions fail.
See report of reproducing this failure in:
Multiple bugs in video detection were fixed recently. Please retest when test3
is released and report back.
(In reply to comment #1)
There is no improvement, no change in symptoms for this failure
(In reply to comment #0)
> Description of problem: Display resolution remains 800x600 pixels
> instead of reconfiguring to the requested resolution.
> This choice of modes is quite different from those shown on e.g.:
> and other places VESA video modes (or VGA codes) are documented.
That document says "796"
Did older versions od Fedora work at 1600x1200?
(In reply to comment #3)
My understanding is that vga=796 requests 1600x1200 256 color mode, while
vga=799 requests 1600x1200 24-bit color mode. See e.g.:
Among the several different Fedora 7 versions that I tried, silent failure was
the usual response. This "Undefined video mode number" failure I first noticed
with Fedora 8.
Did it ever work with any version of Linux using mode 799?
Your VESA BIOS may not support that even if the hardware can.
I felt like I was in a shoe repair shop in Texas seeing so many
boots. While I have recently and exhaustingly booted more than 7
versions of Fedora on several systems (each with a different video
adapter) with many different vga=__ parameter values, I have not
exhaustively tested all possibilities. But I detect enough patterns
to respond to comment #5.
> Did it ever work with any version of Linux using mode 799?
> Your VESA BIOS may not support that even if the hardware can.
I have not yet found a version between Fedora Core 2 and Fedora 8
where this video adapter responded as expected to "vga=799". (Is
there any hunch that another distribution of Linux handled video modes
differently?) So I cannot differ with your hypothesis that the VESA
BIOS of this adapter may not support this mode, even though it does
respond to many of the other 32+ vga modes with implied resolutions
smaller than 1600x1200.
It does seem the error message cited in comment #1 (Undefined video
mode number 799) fails to distinguish between "undefined" and
"unimplemented". To be precise, I think the intended meaning of
"vga=799" is defined , but it just happens to not be implemented by
the hardware/BIOS of the moment. Note also that many other values
(e.g. "vga=dead") are swallowed silently with no message.
 Well, the definitions offered at:
were incomplete, and I have attempted to improve them. Please correct
any mis-impressions I seem to spread with these changes. The biggest
insight is that even when one selects a VGA VESA mode which is
expressed in pixels (as contrasted with columns x rows of characters),
this choice may only briefly change the display of text and have no
effect on the X session that is eventually started. This choice for
the size of the screen in pixels is NOT communicated to the running
system, or more precisely, the video mode will likely be reset at
least once or twice more before the system startup completes. The
vga=_ parameter only affects the presentation of the initial console
text lines on the screen and in the virtual terminals. Once an
install or normal boot progresses to its graphical phase, or a Live CD
progresses to the graphical boot progress screen or login greeter
screen or the desktop, the appearance is unaffected by whatever value
was passed via vga=_.
If you are able to find a version that is bootable with that parameter it would
be worth investigating however I'm not sure that there is any evidence to say
your hardware does support this mode. I'm tempted to close NOTABUG but will
leave open for a few days. If you are able to add any further information please
This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '8'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 8's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 8 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here:
Fedora 8 changed to end-of-life (EOL) status on 2009-01-07. Fedora 8 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.
Thank you for reporting this bug and we are sorry it could not be fixed.