Red Hat Bugzilla – Full Text Bug Listing
|Summary:||Graphical install fails due to bad refresh rates|
|Product:||[Fedora] Fedora||Reporter:||Albert-Jan Yzelman <ajy777>|
|Component:||xorg-x11-drv-ati||Assignee:||Dave Airlie <airlied>|
|Status:||CLOSED WONTFIX||QA Contact:|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2009-12-18 01:06:58 EST||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
Description Albert-Jan Yzelman 2008-04-19 09:39:22 EDT
From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; nl; rv:184.108.40.206) Gecko/20080404 Firefox/220.127.116.11 Description of problem: With the latest Fedora 9 Preview, x86_64 DVD version; choosing graphical install results in a blank screen when entering X mode. Version-Release number of selected component (if applicable): Fedora 9 Preview How reproducible: Always Steps to Reproduce: 1. Boot from CD 2. Select and start graphical installation 3. Press next until anaconda starts booting X Actual Results: A blank screen, while presumably anaconda is not aware of any ill and patiently waits for user input. Expected Results: The anaconda GUI should have shown. Additional info: text-mode install works, but then a blank screen is encountered when booting in fedora 9. Changing to tty (ctrl_alt_f1-8) works, but does not show a login screen, probably due to the first-boot config fedora wants to perform. Hence no chance of manually getting to the x conf file. Booting from DVD in rescue mode simply hangs. Had no problems in Fedora 8 with the exact same setup. Probable cause: somehow X is defaulting to a refresh rate higher than 60Hz, which my monitor apperently (and surprisingly) cannot handle. Possible implications: there may be a whole lot more people with monitors out there which fail on too high refresh rates. Relevant system info: Ati Radeon X1900XTX and X1900CF video cards (primary videocard recognised by anaconda as X1900XT) Samsung SyncMaster 2232BW monitor hooked up with an crossfire cable, with a DVI to DSUB converter (analog mode) Crossfire XPress 3200 (RD580) northbridge chipset
Comment 1 Matěj Cepl 2008-04-21 12:39:55 EDT
Thanks for the bug report. We have reviewed the information you have provided above, and there is some additional information we require that will be helpful in our diagnosis of this issue. Please attach your X server config file (/etc/X11/xorg.conf) and X server log file (/var/log/Xorg.*.log) to the bug report as individual uncompressed file attachments using the bugzilla file attachment link below. Could you please also try to run without any /etc/X11/xorg.conf whatsoever and let X11 autodetect your display and video card? Attach to this bug /var/log/Xorg.0.log from this attempt as well, please. We will review this issue again once you've had a chance to attach this information. Thanks in advance.
Comment 2 Albert-Jan Yzelman 2008-04-21 12:59:53 EDT
Thanks for the reply. I'll be back home in a couple of hours, and will try to boot from some live CD and get the config files; I would have attached them sooner, but I cannot get into a live shell due to this bug (SSH also fails, ethernet connection probably is not started). Also, when I press 'I' for interactive startup after the 'loading nash' thing, it still starts X without asking me. I consider this a flaw as well; should I report this separately or is there a good reason for doing this?
Comment 3 Albert-Jan Yzelman 2008-04-21 15:47:25 EDT
Created attachment 303193 [details] x configuration file after text-mode install
Comment 4 Albert-Jan Yzelman 2008-04-21 15:53:12 EDT
xorg.conf has been submitted. There is no Xorg.*.log in /var/log to be found; not after booting immediately after text-mode install, nor after deleting xorg.conf and rebooting. If X always creates a log file (even if it does not crash), this would mean X is never started and the system sort of hangs before that (although ctrl+alt+f1-8 switching is still possible, albeit does not show a login prompt, and ctrl+alt+del reboots nicely). If this is the case, please advice on how to proceed tracking down the real bug.
Comment 5 Matěj Cepl 2008-04-22 11:05:07 EDT
Sorry, this is an installation issue, so then some logs would be available in /tmp/X* -- when running installation program and it crashes, switch to console (Alt+Ctrl+F2) and then copy content of /tmp somewhere (USB drive, Internet, other computer). X* is the file we are after.
Comment 6 Albert-Jan Yzelman 2008-04-22 15:59:16 EDT
Created attachment 303366 [details] The /tmp/X.log file created by the Anaconda installer Note that Anaconda does *not* crash; the screen is just blank (presumably due to a default too high refresh rate)
Comment 7 Albert-Jan Yzelman 2008-04-22 16:00:05 EDT
Created attachment 303367 [details] The XConfig file generated by X during graphical install
Comment 8 Albert-Jan Yzelman 2008-04-22 16:01:23 EDT
Created attachment 303368 [details] The Anaconda log Note here that the log displays anaconda is at the welcome screen, presumably just waiting, and not crashed in any way.
Comment 9 Albert-Jan Yzelman 2008-04-22 16:04:24 EDT
New info posted. Let me know if more is required.
Comment 10 Jeremy Katz 2008-05-02 12:56:52 EDT
Does booting with 'xdriver=vesa' work around the problem?
Comment 11 Albert-Jan Yzelman 2008-05-02 14:41:10 EDT
Yes, it does!
Comment 12 Jeremy Katz 2008-05-02 16:31:28 EDT
Given the presence of a workaround (... and that we have drivers that require this every release :/), dropping to F9Target
Comment 13 Bug Zapper 2008-05-14 05:43:49 EDT
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
Comment 14 Albert-Jan Yzelman 2008-12-02 16:53:42 EST
A minor update: I have found that this issue persists in Fedora 10.
Comment 15 Albert-Jan Yzelman 2009-02-08 08:54:43 EST
Persists in Fedora 11 Alpha (also on i686).
Comment 16 Bug Zapper 2009-11-18 05:11:37 EST
This message is a reminder that Fedora 10 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 10. 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 '10'. 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 10'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 10 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
Comment 17 Bug Zapper 2009-12-18 01:06:58 EST
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 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.