Red Hat Bugzilla – Bug 306861
installer parameter " resolution=..." ineffective
Last modified: 2009-07-14 13:27:09 EDT
Description of problem:
Attempts to use the installer parameter "resolution=1600x1200"
Version-Release number of selected component (if applicable):
most recently observed with:
vmlinuz dated 2007-09-23, size 2009728
initrd.img dated 2007-09-23, size 6913571
stage2.img of same vintage (downloaded just after midnight 2007-09-24)
but same behavior witnessed with many previous versions over the
last several months
Solidly. Has failed every time in tens of attempts.
Steps to Reproduce:
1. Download .../fedora/linux/development/i386/os/images/pxeboot/vmlinuz
2. Edit /boot/grub/grub.conf to include a stanza for the rawhide install.
3. Boot, select the entry for this rawhide install on the grub menu,
add "resolution=1600x1200" to the end of the "kernel vmlinuz" line.
With or without this parameter, the installer attempts to show a
The installer should configure and use a 1600x1200 display.
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 "resolution=..." parameter should be a solid
alternative when the other automatic assumptions fail.
I was seeing this problem for a couple weeks, but it seems to have resolved
itself in today's rawhide tree as the resolution= parameter now works again. I
believe it must have been a driver problem as on my test machine, the resolution
provided on the command line was being propagated to the X config file. Also,
it was not displaying anaconda fullscreen at 800x600 as it should have been.
These all appear to be fixed now. If you are still experiencing this problem,
please feel free to reopen this bug.
(In reply to comment #1)
I downloaded the pxeboot files produced on 2007-10-09, namely:
initrd.img of size 6661223
vmlinuz of size 2047456
(Let me know if there is a way to capture a more useful version
number from these files.) As before, while the initial text-mode
questions on language, keyboard, media, and HTTP setup are presented
legibly, once stage2.img has been retrieved and Anaconda starts,
the scrambled screen I see on my hardware remains the same whether or
not I supplied "resolution=1600x1200" on the kernel line. The
format of the scramble is the same that I usually see when an 800x600
video mode is attempted. Thus I reopen the report of this bug.
What is your video hardware? Can you attach /etc/X11/xorg.conf to this bug report?
Created attachment 225431 [details]
Attached /etc/X11/xorg.conf showing r128 driving a 1600x1200 LCD.
It looks like your xorg.conf file has been modified since installation (judging
by the comment at the top). Can you please attach /var/log/anaconda.xlog
Created attachment 232461 [details]
Yes, since 800x600 is unusable on this screen, one must reconfig. Here is /var/log/anaconda.xlog, showing how it mistakenly thinks "(hsync out of range)" for the valid and requested 1600x1200.
Why the usual trial and error probing despite the "resolution=..." parameter?
(In reply to comment #2)
> I downloaded the pxeboot files produced on 2007-10-09, namely:
> initrd.img of size 6661223
> vmlinuz of size 2047456
> (Let me know if there is a way to capture a more useful version
> number from these files.)
rpm -qa kernel\*
rpm -q kernel-$(uname -r)
are much more useful. And if you could add output of the command
rpm -q xorg-x11-drv-ati fedora-release
it would help as well.
Also /var/log/Xorg.0.log attached as an uncompressed attachment to this bug
would help enormously.
Created attachment 237061 [details]
# rpm -qa kernel\*
# rpm -q kernel-$(uname -r)
# rpm -q xorg-x11-drv-ati fedora-release
For this video adapter in this computer system, I have verified that
adding "resolution=1600x1200" to the end of the "linux" boot command line
works correctly (centers the 800x600 graphical install window upon
the 1600x1200 screen, using a video mode where all information is
rendered correctly and legibly) when running the installation CD's for:
Fedora Core 2,
Fedora Core 3,
Fedora Core 4, and
Fedora Core 5.
This regression of not properly switching to the requested video mode
is present when one runs the installation CD's for:
Fedora Core 6
and the more recent Fedora 7 and 8 as reported above. One can see in
/tmp/anaconda.log a line similar to:
adding extra Arg --resolution=1600x1200
as evidence that the left hand is attempting to pass the information to
the right hand.
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9. 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 '9'.
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 9'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 9 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 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 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.