Red Hat Bugzilla – Bug 632805
basic video driver fails in bare metal install (goes into text mode)
Last modified: 2010-10-14 16:13:32 EDT
Description of problem: If the basic video driver option is chosen in the boot menu for 14 Beta TC1, then at the point where stage2 should start, there is a black screen and 0% CPU. This happens in both i386 and x86_64. Version-Release number of selected component (if applicable): xorg-x11-drv-vesa-2.3.0-1.fc14 How reproducible: always Steps to Reproduce: 1. Boot from 14 Beta TC1 DVD (either i386 or x86_64). 2. Choose basic video driver. Actual results: Black screen when stage 2 is supposed to start. Installer appears dead. Expected results: stage2 should start Additional info: Installs attempted in KVM. Don't know if it happens on bare metal.
Tested a 14 Beta TC1 i386 DVD in 3 bare metal machines, with 3 different results. Verified disc with mediacheck on all 3 boxes. 1) 11-year old eMachines 333cs, behaves exactly the same as in KVM - black screen when stage2 is supposed to start, appears dead. Smolt URL: http://www.smolts.org/client/show/pub_49b32bf0-4174-4537-bd84-37fc4aa1c614 2) 4-year old Dell Dimension B110, brings up stage2 properly. Smolt URL: http://www.smolts.org/client/show/pub_892dc725-d358-4022-ab79-6047ccd42aa1 3) 2-year old Compaq SR5431WM, when stage2 is supposed to start, get message "X startup failed, falling back to text mode" and it comes up in text mode. Smolt URL: http://www.smolts.org/client/show/pub_d6319293-2126-4966-a8dc-7ab64a6fed17 Changed the component to anaconda since bug 577312 which looks similar to this was assigned to that component.
See also bug 627073.
No. It's not 627073. It's just a known bug with qemu VMs. vesa does not work with the qemu 'graphics card'. I've mentioned this to ajax before, but I'm not sure a bug report exists, so I'll leave this open for now. ajax, do we have a report of this already? this isn't a big problem, because there's no reason to use vesa with a qemu vm. so it doesn't worry us particularly. vesa failing on a real card is more of a problem when it happens. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
But then why does it affect 2 out of 3 of my bare metal machines as well (as described in comment 1)?
Created attachment 446809 [details] /tmp/X.log when X startup fails After X startup failed, I went to VT2 and copied all the logfiles in /tmp to a thumb drive. Let me know if any of the other files would help.
Should have mentioned that this is the Compaq SR5431WM. Since the eMachines 333cs would be totally unresponsive at this point, I can't get the logs for that.
(In reply to comment #3) > No. It's not 627073. It's just a known bug with qemu VMs. vesa does not work > with the qemu 'graphics card'. I've mentioned this to ajax before, but I'm not > sure a bug report exists, so I'll leave this open for now. ajax, do we have a > report of this already? I filed this bug during alpha testing: bug#623956
Changed the Summary to exclude KVM.
I'd guess there's at least three bugs here, given the different graphics adapters and behaviours involved. As I mentioned, the qemu cirrus 'card' case is known. Your other cases involve a very old ATI card (Rage II) and a fairly old NVIDIA card (nForce 430). They behave differently. I *doubt* they're the same bug. It may be best to separate them. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
(In reply to comment #9) > I'd guess there's at least three bugs here, given the different graphics > adapters and behaviours involved. As I mentioned, the qemu cirrus 'card' case > is known. Your other cases involve a very old ATI card (Rage II) and a fairly > old NVIDIA card (nForce 430). They behave differently. I *doubt* they're the > same bug. It may be best to separate them. Yes, please, and file for each also * your X server config file (/etc/X11/xorg.conf, if available), * X server log file (/var/log/Xorg.*.log), and * system log (/var/log/messages) to the bug report as individual uncompressed file attachments. Thanks in advance.
I'm a little confused - do you want the log files generated by the install attempt (what I would expect), or those associated with the existing Fedora installation on each of these machines (which should have nothing to do with this problem)? Also, there is only one machine which both has the problem, and fails in such a way as to allow me to save log files (the Compaq). I already attached the X.log generated by the install attempt for that machine. The other files for that machine in /tmp when X startup failed are anaconda.log anaconda-yum.conf libuser.62tklY program.log storage.log syslog X.log (already attached) Do you need any of these as well?
We need an X log from the failure to start, if there is one. You could install in text mode, then try to start X with vesa as the configured driver, reboot to runlevel 3, and see if there's a /var/log/Xorg.0.log . -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
I already provided the X log in comment 5 (from the only machine where the problem exists and the log can be obtained).
then edit this bug to be about that case, provide /var/log/messages from the same machine, and open a new bug for the other machine. I'm not sure you've tried the above for the other machine yet. It may work, try it. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
I opened bug 633247 for the eMachines 333cs. In this case, is there a file /var/log/messages available at the time X startup fails? I'm pretty sure I checked for one and didn't find it last time, and could only find log files in /tmp. I saved all of those and listed them in comment 11, and will attach any of them that may be useful.
matej's instructions are for an installed system. 'syslog' would probably be what we'd need. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Created attachment 446907 [details] /tmp/syslog when X startup fails /tmp/syslog from the same failed install attempt as the previous attachment
(In reply to comment #11) > I'm a little confused - do you want the log files generated by the install > attempt (what I would expect), or those associated with the existing Fedora > installation on each of these machines (which should have nothing to do with > this problem)? Also, there is only one machine which both has the problem, and > fails in such a way as to allow me to save log files (the Compaq). I already > attached the X.log generated by the install attempt for that machine. The other > files for that machine in /tmp when X startup failed are My point was that if it is not possible to get logs from installation (e.g., see comment 6) the second best thing we can get for Xorg is to get logs from autoconfiguration on already installed system. Which is what I was explaining in the comment 10. Matěj
Created attachment 446929 [details] xorg.conf associated with proprietary nvidia driver from rpmfusion
Created attachment 446930 [details] /var/log/Xorg.0.log
Created attachment 446931 [details] /var/log/messages
it fails with vesa, it doesn't fail with nvidia. we need you to try with vesa and provide the logs of it failing. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Just tested with the F12 x86_64 DVD and the F13 x86_64 DVD. It fails the same way with both, so it's not a regression and I've taken this off the blocker list.
[ 41.015] (II) VESA(0): PanelID returned panel resolution -494x-29972 ha ha ha ha ha ha ha (depression)
Try this X server build instead: http://koji.fedoraproject.org/koji/buildinfo?buildID=195152
This is my main working machine and it has a F13 install that I'm not willing to wipe, sorry. I'll try to find out how to delete/disable the rpmfusion nvidia driver and temporarily enable vesa to provide the logs for vesa failing in F13.
Created attachment 447027 [details] /etc/X11/xorg.conf after running "nvidia-config-display disable" I rebooted without the boot options "rdblacklist=nouveau nomodeset", then ran "nvidia-config-display disable", then restarted the X server with Ctrl-Alt-Backspace to get the vesa driver while running F13. It failed, again (flashes a while, then gives up, but I can go to a VT). These log files should be the right ones.
Created attachment 447028 [details] /var/log/Xorg.0.log
Created attachment 447029 [details] /var/log/messages
Could you please remove everything from your /etc/X11/xorg.conf except of these three lines? (There isn't AIGLX or compositing with VESA driver, besides nvidia's OpenGL stuff is incompatible with open-source drivers): Section "Device" Driver "vesa" EndSection I am not certain whether loaded Composition and AIGLX modules don't interfere with the rest of the system. Thank you
Created attachment 447188 [details] /etc/X11/xorg.conf I had to include the Identifier line, otherwise Xorg.0.log said "This section must have an Identifier line.".
Created attachment 447189 [details] /var/log/Xorg.0.log
Created attachment 447190 [details] /var/log/messages
[ 127.418] (EE) VESA(0): No valid modes [ 127.418] (II) UnloadModule: "vesa" [ 127.418] (II) UnloadModule: "int10" [ 127.418] (II) Unloading /usr/lib64/xorg/modules/libint10.so [ 127.418] (II) UnloadModule: "vbe" [ 127.418] (II) Unloading /usr/lib64/xorg/modules/libvbe.so [ 127.418] (EE) Screen(s) found, but none have a usable configuration. [ 127.418] Fatal server error: [ 127.418] no screens found [ 127.418] OK, now I feel persuaded. Passing the bug to developers.
propose for F14 Beta NTH list (new system for tracking bugs that aren't blockers but for which we'll accept fixes through the freeze)
This proposed update: https://admin.fedoraproject.org/updates/xorg-x11-server-1.9.0-9.fc14 has a fix for this bug, although it's not listed in the update's list of fixed bugs (by mistake I guess). Can you please try it? It doesn't need to be in an install, all you need to do is try using the vesa driver in an installed system - with the previous X server package it should fail in much the same way, with this X server package it should succeed. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Can this update be applied in my existing F13 install on this machine? If not, I'll have to wait until the next RC that includes it. If that's RC1, it'll be today or tomorrow.
no, you'll need an F14 install, and the update is unlikely to go into a Beta compose without being tested beforehand.
I noticed there is a F13 build that claims to have the same fix: https://admin.fedoraproject.org/updates/xorg-x11-server-1.8.2-4.fc13 so I updated to xorg-x11-server-common-1.8.2-4.fc13.x86_64 xorg-x11-server-Xorg-1.8.2-4.fc13.x86_64 and went through the same procedure as above, with the same results (screen flashes for a while, then gives up). Log files attached below.
Created attachment 447870 [details] /etc/X11/xorg.conf
Created attachment 447871 [details] /var/log/Xorg.0.log
Created attachment 447872 [details] /var/log/messages
Beta's now out, so moving from Beta nice-to-have list to Final nice-to-have list. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
This was discussed at the 2010-10-01 blocker / NTH review meeting, and accepted as a nice-to-have.
The bodhi comments for the update in comment #39 are misleading, the vbe fix was not included there.
Created attachment 453549 [details] X.log from basic video mode, F14 Final TC1 i386 DVD
This works now with the F14 Final TC1 i386 DVD. Closing as CURRENTRELEASE.