Red Hat Bugzilla – Full Text Bug Listing
|Summary:||basic video driver fails in bare metal install (goes into text mode)|
|Product:||[Fedora] Fedora||Reporter:||Andre Robatino <robatino>|
|Component:||xorg-x11-drv-vesa||Assignee:||Adam Jackson <ajax>|
|Status:||CLOSED CURRENTRELEASE||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||14||CC:||awilliam, jonathan, mishu, rhe, vanmeeuwen+fedora, xgl-maint|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2010-10-14 16:13:32 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
Description Andre Robatino 2010-09-10 23:59:48 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.
Comment 1 Andre Robatino 2010-09-11 19:43:28 EDT
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.
Comment 3 Adam Williamson 2010-09-12 15:32:03 EDT
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
Comment 4 Andre Robatino 2010-09-12 18:10:38 EDT
But then why does it affect 2 out of 3 of my bare metal machines as well (as described in comment 1)?
Comment 5 Andre Robatino 2010-09-12 20:02:46 EDT
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.
Comment 6 Andre Robatino 2010-09-12 20:04:57 EDT
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.
Comment 7 He Rui 2010-09-12 22:55:21 EDT
(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
Comment 8 Andre Robatino 2010-09-12 23:02:33 EDT
Changed the Summary to exclude KVM.
Comment 9 Adam Williamson 2010-09-13 01:51:03 EDT
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
Comment 10 Matěj Cepl 2010-09-13 04:28:17 EDT
(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.
Comment 11 Andre Robatino 2010-09-13 04:54:00 EDT
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?
Comment 12 Adam Williamson 2010-09-13 07:00:58 EDT
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
Comment 13 Andre Robatino 2010-09-13 07:05:50 EDT
I already provided the X log in comment 5 (from the only machine where the problem exists and the log can be obtained).
Comment 14 Adam Williamson 2010-09-13 07:36:21 EDT
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
Comment 15 Andre Robatino 2010-09-13 07:57:09 EDT
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.
Comment 16 Adam Williamson 2010-09-13 08:18:03 EDT
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
Comment 17 Andre Robatino 2010-09-13 08:25:47 EDT
Created attachment 446907 [details] /tmp/syslog when X startup fails /tmp/syslog from the same failed install attempt as the previous attachment
Comment 18 Matěj Cepl 2010-09-13 09:42:22 EDT
(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
Comment 19 Andre Robatino 2010-09-13 09:49:44 EDT
Created attachment 446929 [details] xorg.conf associated with proprietary nvidia driver from rpmfusion
Comment 20 Andre Robatino 2010-09-13 09:50:57 EDT
Created attachment 446930 [details] /var/log/Xorg.0.log
Comment 21 Andre Robatino 2010-09-13 09:52:06 EDT
Created attachment 446931 [details] /var/log/messages
Comment 22 Adam Williamson 2010-09-13 10:35:47 EDT
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
Comment 23 Andre Robatino 2010-09-13 10:54:20 EDT
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.
Comment 24 Adam Jackson 2010-09-13 11:40:12 EDT
[ 41.015] (II) VESA(0): PanelID returned panel resolution -494x-29972 ha ha ha ha ha ha ha (depression)
Comment 25 Adam Jackson 2010-09-13 14:03:13 EDT
Try this X server build instead: http://koji.fedoraproject.org/koji/buildinfo?buildID=195152
Comment 26 Andre Robatino 2010-09-13 14:11:17 EDT
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.
Comment 27 Andre Robatino 2010-09-13 15:52:13 EDT
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.
Comment 28 Andre Robatino 2010-09-13 15:53:13 EDT
Created attachment 447028 [details] /var/log/Xorg.0.log
Comment 29 Andre Robatino 2010-09-13 15:54:04 EDT
Created attachment 447029 [details] /var/log/messages
Comment 30 Matěj Cepl 2010-09-14 03:57:25 EDT
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
Comment 31 Andre Robatino 2010-09-14 05:16:55 EDT
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.".
Comment 32 Andre Robatino 2010-09-14 05:17:30 EDT
Created attachment 447189 [details] /var/log/Xorg.0.log
Comment 33 Andre Robatino 2010-09-14 05:18:12 EDT
Created attachment 447190 [details] /var/log/messages
Comment 34 Matěj Cepl 2010-09-14 12:04:46 EDT
[ 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.
Comment 35 Adam Williamson 2010-09-15 12:35:48 EDT
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)
Comment 36 Adam Williamson 2010-09-16 06:03:43 EDT
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
Comment 37 Andre Robatino 2010-09-16 08:19:48 EDT
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.
Comment 38 Adam Williamson 2010-09-16 18:45:05 EDT
no, you'll need an F14 install, and the update is unlikely to go into a Beta compose without being tested beforehand.
Comment 39 Andre Robatino 2010-09-16 21:00:18 EDT
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.
Comment 40 Andre Robatino 2010-09-16 21:01:04 EDT
Created attachment 447870 [details] /etc/X11/xorg.conf
Comment 41 Andre Robatino 2010-09-16 21:01:38 EDT
Created attachment 447871 [details] /var/log/Xorg.0.log
Comment 42 Andre Robatino 2010-09-16 21:02:26 EDT
Created attachment 447872 [details] /var/log/messages
Comment 43 Adam Williamson 2010-09-27 21:43:26 EDT
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
Comment 44 Adam Williamson 2010-10-01 17:29:20 EDT
This was discussed at the 2010-10-01 blocker / NTH review meeting, and accepted as a nice-to-have.
Comment 45 Adam Jackson 2010-10-04 14:39:27 EDT
The bodhi comments for the update in comment #39 are misleading, the vbe fix was not included there.
Comment 46 Andre Robatino 2010-10-14 16:12:13 EDT
Created attachment 453549 [details] X.log from basic video mode, F14 Final TC1 i386 DVD
Comment 47 Andre Robatino 2010-10-14 16:13:32 EDT
This works now with the F14 Final TC1 i386 DVD. Closing as CURRENTRELEASE.