Bug 308371 - f8t3 LiveCD " vga=..." boot loader parameter failure [NEEDINFO]
f8t3 LiveCD " vga=..." boot loader parameter failure
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
i686 Linux
low Severity high
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2007-09-27 03:21 EDT by xunilarodef
Modified: 2009-01-08 23:54 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-01-08 23:54:48 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
snecklifter: needinfo? (xunilarodef)

Attachments (Terms of Use)

  None (edit)
Description xunilarodef 2007-09-27 03:21:52 EDT
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

How reproducible:
  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.   

Actual results:
  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

line) with:
- - -
Undefined video mode number 799
Press <ENTER> to see video modes available, <SPACE> to continue, or wait 30 sec
[<ENTER> displays something similar to: ]
Mode:    COLSxROWS:
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.

Expected results:
  Configure the display as documented, i.e. to 1600x1200 32-bit color,
rather than starting X / running Anaconda in 800 x 600 resolution.

Additional info:
  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
(e.g. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=231113)
interfere.  The "vga=..." parameter should be a solid
alternative when the other automatic assumptions fail.

  See report of reproducing this failure in:

Comment 1 Chuck Ebbert 2007-09-27 14:52:55 EDT
Multiple bugs in video detection were fixed recently. Please retest when test3
is released and report back.
Comment 2 xunilarodef 2007-10-08 07:41:46 EDT
(In reply to comment #1)
  There is no improvement, no change in symptoms for this failure
in f8t3.

Comment 3 Chuck Ebbert 2007-10-08 17:31:54 EDT
(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?
Comment 4 xunilarodef 2007-10-09 08:13:13 EDT
(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.
Comment 5 Chuck Ebbert 2007-12-06 18:55:31 EST
Did it ever work with any version of Linux using mode 799?
Your VESA BIOS may not support that even if the hardware can.
Comment 6 xunilarodef 2008-01-10 08:41:52 EST
  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 [1], 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. 

[1] 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=_.
Comment 7 Christopher Brown 2008-02-03 17:28:26 EST
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
do so.
Comment 8 Bug Zapper 2008-11-26 02:51:31 EST
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: 
Comment 9 Bug Zapper 2009-01-08 23:54:48 EST
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.

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