Bug 306861 - installer parameter " resolution=..." ineffective
Summary: installer parameter " resolution=..." ineffective
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-ati (Show other bugs)
(Show other bugs)
Version: 9
Hardware: i686 Linux
Target Milestone: ---
Assignee: Dave Airlie
QA Contact: Fedora Extras Quality Assurance
Keywords: Reopened
Depends On:
TreeView+ depends on / blocked
Reported: 2007-09-26 12:59 UTC by xunilarodef
Modified: 2018-04-11 08:05 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-07-14 17:27:09 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Attached /etc/X11/xorg.conf showing r128 driving a 1600x1200 LCD. (1006 bytes, text/plain)
2007-10-12 12:14 UTC, xunilarodef
no flags 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. (38.80 KB, text/plain)
2007-10-19 12:19 UTC, xunilarodef
no flags Details
/var/log/Xorg.0.log (43.52 KB, text/plain)
2007-10-25 05:25 UTC, xunilarodef
no flags Details

Description xunilarodef 2007-09-26 12:59:49 UTC
Description of problem:
Attempts to use the installer parameter "resolution=1600x1200" 
are ineffective.  

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

How reproducible:
  Solidly.  Has failed every time in tens of attempts.

Steps to Reproduce:
1. Download .../fedora/linux/development/i386/os/images/pxeboot/vmlinuz
   and initrd.img.
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.

Actual results:
With or without this parameter, the installer attempts to show a 
800x600 display.

Expected results:
The installer should configure and use a 1600x1200 display.

Additional info:
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 "resolution=..." parameter should be a solid
alternative when the other automatic assumptions fail.

Comment 1 Chris Lumens 2007-10-09 19:23:13 UTC
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.

Comment 2 xunilarodef 2007-10-11 01:10:11 UTC
(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. 

Comment 3 Chris Lumens 2007-10-11 13:57:36 UTC
What is your video hardware?  Can you attach /etc/X11/xorg.conf to this bug report?

Comment 4 xunilarodef 2007-10-12 12:14:36 UTC
Created attachment 225431 [details]
Attached /etc/X11/xorg.conf showing r128 driving a 1600x1200 LCD.

Comment 5 Chris Lumens 2007-10-19 04:59:04 UTC
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
instead?  Thanks.

Comment 6 xunilarodef 2007-10-19 12:19:02 UTC
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?

Comment 7 Matěj Cepl 2007-10-22 19:13:40 UTC
(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.

Comment 8 xunilarodef 2007-10-25 05:25:30 UTC
Created attachment 237061 [details]

# rpm -qa kernel\*
# rpm -q kernel-$(uname -r)
# rpm -q xorg-x11-drv-ati fedora-release

Comment 9 xunilarodef 2008-01-13 00:07:57 UTC
  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.  

Comment 10 Bug Zapper 2008-05-14 03:16:53 UTC
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:

Comment 11 Bug Zapper 2009-06-09 22:52:39 UTC
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: 

Comment 12 Bug Zapper 2009-07-14 17:27:09 UTC
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.

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