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.
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 instead? Thanks.
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\* and 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] /var/log/Xorg.0.log # rpm -qa kernel\* kernel-2.6.23-6.fc8 kernel-2.6.23-0.224.rc9.git6.fc8 # rpm -q kernel-$(uname -r) kernel-2.6.23-6.fc8 # rpm -q xorg-x11-drv-ati fedora-release xorg-x11-drv-ati-6.7.195-2.fc8 fedora-release-7.92-2 #
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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
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.