Bug 632805 - basic video driver fails in bare metal install (goes into text mode)
Summary: basic video driver fails in bare metal install (goes into text mode)
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-vesa
Version: 14
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Adam Jackson
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedNTH
Depends On:
Blocks: F14-accepted, F14FinalFreezeExcept
TreeView+ depends on / blocked
 
Reported: 2010-09-11 03:59 UTC by Andre Robatino
Modified: 2018-04-11 18:36 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-10-14 20:13:32 UTC


Attachments (Terms of Use)
/tmp/X.log when X startup fails (55.87 KB, text/plain)
2010-09-13 00:02 UTC, Andre Robatino
no flags Details
/tmp/syslog when X startup fails (57.49 KB, text/plain)
2010-09-13 12:25 UTC, Andre Robatino
no flags Details
xorg.conf associated with proprietary nvidia driver from rpmfusion (421 bytes, text/plain)
2010-09-13 13:49 UTC, Andre Robatino
no flags Details
/var/log/Xorg.0.log (30.97 KB, text/plain)
2010-09-13 13:50 UTC, Andre Robatino
no flags Details
/var/log/messages (166.48 KB, text/plain)
2010-09-13 13:52 UTC, Andre Robatino
no flags Details
/etc/X11/xorg.conf after running "nvidia-config-display disable" (322 bytes, text/plain)
2010-09-13 19:52 UTC, Andre Robatino
no flags Details
/var/log/Xorg.0.log (56.19 KB, text/plain)
2010-09-13 19:53 UTC, Andre Robatino
no flags Details
/var/log/messages (601.86 KB, text/plain)
2010-09-13 19:54 UTC, Andre Robatino
no flags Details
/etc/X11/xorg.conf (74 bytes, text/plain)
2010-09-14 09:16 UTC, Andre Robatino
no flags Details
/var/log/Xorg.0.log (56.10 KB, text/plain)
2010-09-14 09:17 UTC, Andre Robatino
no flags Details
/var/log/messages (850.37 KB, text/plain)
2010-09-14 09:18 UTC, Andre Robatino
no flags Details
/etc/X11/xorg.conf (74 bytes, text/plain)
2010-09-17 01:01 UTC, Andre Robatino
no flags Details
/var/log/Xorg.0.log (56.11 KB, text/plain)
2010-09-17 01:01 UTC, Andre Robatino
no flags Details
/var/log/messages (1.10 MB, text/plain)
2010-09-17 01:02 UTC, Andre Robatino
no flags Details
X.log from basic video mode, F14 Final TC1 i386 DVD (75.95 KB, text/plain)
2010-10-14 20:12 UTC, Andre Robatino
no flags Details

Description Andre Robatino 2010-09-11 03:59:48 UTC
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 23:43:28 UTC
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 2 Andre Robatino 2010-09-12 00:52:35 UTC
See also bug 627073.

Comment 3 Adam Williamson 2010-09-12 19:32:03 UTC
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 22:10:38 UTC
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-13 00:02:46 UTC
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-13 00:04:57 UTC
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-13 02:55:21 UTC
(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-13 03:02:33 UTC
Changed the Summary to exclude KVM.

Comment 9 Adam Williamson 2010-09-13 05:51:03 UTC
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 08:28:17 UTC
(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 08:54:00 UTC
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 11:00:58 UTC
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 11:05:50 UTC
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 11:36:21 UTC
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 11:57:09 UTC
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 12:18:03 UTC
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 12:25:47 UTC
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 13:42:22 UTC
(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 13:49:44 UTC
Created attachment 446929 [details]
xorg.conf associated with proprietary nvidia driver from rpmfusion

Comment 20 Andre Robatino 2010-09-13 13:50:57 UTC
Created attachment 446930 [details]
/var/log/Xorg.0.log

Comment 21 Andre Robatino 2010-09-13 13:52:06 UTC
Created attachment 446931 [details]
/var/log/messages

Comment 22 Adam Williamson 2010-09-13 14:35:47 UTC
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 14:54:20 UTC
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 15:40:12 UTC
[    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 18:03:13 UTC
Try this X server build instead:

http://koji.fedoraproject.org/koji/buildinfo?buildID=195152

Comment 26 Andre Robatino 2010-09-13 18:11:17 UTC
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 19:52:13 UTC
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 19:53:13 UTC
Created attachment 447028 [details]
/var/log/Xorg.0.log

Comment 29 Andre Robatino 2010-09-13 19:54:04 UTC
Created attachment 447029 [details]
/var/log/messages

Comment 30 Matěj Cepl 2010-09-14 07:57:25 UTC
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 09:16:55 UTC
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 09:17:30 UTC
Created attachment 447189 [details]
/var/log/Xorg.0.log

Comment 33 Andre Robatino 2010-09-14 09:18:12 UTC
Created attachment 447190 [details]
/var/log/messages

Comment 34 Matěj Cepl 2010-09-14 16:04:46 UTC
[   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 16:35:48 UTC
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 10:03:43 UTC
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 12:19:48 UTC
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 22:45:05 UTC
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-17 01:00:18 UTC
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-17 01:01:04 UTC
Created attachment 447870 [details]
/etc/X11/xorg.conf

Comment 41 Andre Robatino 2010-09-17 01:01:38 UTC
Created attachment 447871 [details]
/var/log/Xorg.0.log

Comment 42 Andre Robatino 2010-09-17 01:02:26 UTC
Created attachment 447872 [details]
/var/log/messages

Comment 43 Adam Williamson 2010-09-28 01:43:26 UTC
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 21:29:20 UTC
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 18:39:27 UTC
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 20:12:13 UTC
Created attachment 453549 [details]
X.log from basic video mode, F14 Final TC1 i386 DVD

Comment 47 Andre Robatino 2010-10-14 20:13:32 UTC
This works now with the F14 Final TC1 i386 DVD. Closing as CURRENTRELEASE.


Note You need to log in before you can comment on or make changes to this bug.