Bug 212432
|
Description
quintesse
2006-10-26 19:02:55 UTC
BTW: starting the install with "linux vesa" works. (Tip: maybe this option should be mentioned in the installer options help screens?) Looking at it some more it seems it has something to do with the XOrg -configuration option / auto-detection that doesn't work for my monitor or card (nVidia 6600GT). If I start the installer with "linux vesa" the XConfig.conf file generated by anaconda uses the vesa driver and everything works okay and I can at least install. On first reboot though X refuses to start. Running XOrg -configure from runlevel 3 results in a XOrg.conf that uses "nv" and the monitor will complain about a wrong resolution. If I change the driver in the config to "vesa" or if I use the exact same config that anaconda used the screen blanks and the monitor light starts blinking indicatingthere is no signal. The system is notdead but I have not found a way to get the screen back, killing X does nothing nor can I switch to any VT. In the end it seems this is an XOrg problem. The strabge thing is that the version used by anaconda at least works for vesa while the one installed does nothing at all. I'll try to test some more. I don't have another monitor but I will try to see what happens with another Gfx card. Changing component from "anaconda" to "xorg-x11" because this problem is not related to the installer but to the version of X used by it, the graphical boot and the final X session, in fact I'm not able to get X working at all. I imagine that "vesa" still worked for the installer because the version of X it uses is different form the final system, but I have no idea if that is a possibility. X with this video card worked without problems with the vesa and nvidia's drivers in FC5 or the nv driver after telling it "NoDDC" and "IgnoreEDID". None of that works in FC6. NB: Putting another vido card (an ATI Radeon X300) in the systm works without any problems. The following bug seems to describe a very similar problem: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=212437 Created attachment 139843 [details]
Configuration generated by Xorg -configure
Created attachment 139844 [details]
Xorg log file using default configuration
Created attachment 139845 [details]
Xorg log file after changing configuration to use vesa driver
Only things changed in default configuration is the driver name fro "nv" to
"vesa" and commenting out of modules "dri" and "glx".
Sorry for the flood of changes and for bumping this to "high" (although I don't know if I should "high" for something that will affect only a small precentage of people I guess) but I thought this was like before only an installer problem, but I'm actually unable to get X working in FC6 right now (with this particular Gfx card that is). Created attachment 139852 [details]
Output of dmesg for default configuration
It may be worthy to note that this computer is using -xen kernel. Ok, turned down the priority to normal again because I've found out a way to get things to work. The problem seems to be that the card has 2 DVI ports. They are not marked with any number so there is no way to see if there is a "primary" or something like that. But looking at the Xorg log I saw this: (II) NV(0): Probing for analog device on output A... (--) NV(0): ...can't find one (II) NV(0): Probing for analog device on output B... (--) NV(0): ...found one (II) NV(0): Probing for EDID on I2C bus A... (II) NV(0): I2C device "DDC:ddc2" registered at address 0xA0. (II) NV(0): I2C device "DDC:ddc2" removed. (--) NV(0): DDC detected a CRT: (II) NV(0): Manufacturer: SAM Model: 11f Serial#: 1296707897 etc. So the monitor wasn't conencted to the first output but the second. It seems that for the grub graphical display and for the text-only part of the boot this doesn't matter because the right output is automatically selected, but it seems that the Xorg auto discovery doesn't really like this. I switched the monitor to the other output and the same part of the log now shows this: (II) NV(0): Probing for analog device on output A... (--) NV(0): ...found one (II) NV(0): Probing for analog device on output B... (--) NV(0): ...found one (II) NV(0): Probing for EDID on I2C bus A... (II) NV(0): I2C device "DDC:ddc2" registered at address 0xA0. (II) NV(0): I2C device "DDC:ddc2" removed. (II) NV(0): ... none found (II) NV(0): Probing for EDID on I2C bus B... (II) NV(0): I2C device "DDC:ddc2" registered at address 0xA0. (II) NV(0): I2C device "DDC:ddc2" removed. (--) NV(0): DDC detected a CRT: (II) NV(0): Manufacturer: SAM Model: 11f Serial#: 1296707897 It somehow thinks there are 2 monitors attached? I have no idea but at least now I get a normal picture (instead of my monitor complaining that it can't handle the signal). So, there still is something wrong with the XOrg auto discovery because I think this should work but there is no rush anymore. The original problem (as per the description of this bug report) still exists in Fedora 7. Haven't yet finished the installation so don't know if any of the other problems still persist. Will let you know as soon as I have more information. Reporter, still talking about kernel-xen? fullvirt or paravirt? No, we're talking about the installation here so the kernel is whatever the installation uses. A big improvement is that if I install with "linux vesa" it now also selects vesa for the installed XOrg. So the problem I mentioned in comment #1 is solved at least. (In reply to comment #11) > The original problem (as per the description of this bug report) still exists in > Fedora 7. Haven't yet finished the installation so don't know if any of the > other problems still persist. Will let you know as soon as I have more information. Do you have an X log from the failed startup from F7 yet? See #13, it's not the startup but the installation procedure that fails. If there is a way to get that log while performing the installation let me know and I'll get it for you. Fedora Core 6 is no longer supported, could you please reproduce this with the updated version of the currently supported distribution (Fedora 7, 8, or Rawhide)? If this issue turns out to still be reproducible, please let us know in this bug report. If after a month's time we have not heard back from you, we will have to close this bug as CANTFIX. Setting status to NEEDINFO, and awaiting information from the reporter. [This is mass-filed message to all open Fedora Core 6 bugs related to Xorg or Gecko. If you see any other reason, why this bug shouldn't be closed, please, comment on it here.] The same problem still exists for Fedora 8. The original bug description is still valid: insert DVD, select graphical install and the moment the installer switches to graphical mode the monitor shows colored lines and complains that the signal is out of range. Installing with "linux vesa" does work. Could we get updated information for this bug, please? 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. Created attachment 286321 [details]
The X configuration used/generated by the Fedora 8 installer
Created attachment 286331 [details]
The X log generated by the Fedora 8 installer
Created attachment 286341 [details]
Anaconda lof generated by the Fedora 8 installer
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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping 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. |