Created attachment 359219 [details]
Description of problem:
X crashes on start with nouveau (GeForce 9100). Can boot into runlevel 3 with nouveau.modeset=0 kernel parameter. Must create xorg.conf with Driver=vesa to use X
Version-Release number of selected component (if applicable):
I'm running the nightly Rawhide lxde spin dated 27Aug
100% of the time
Steps to Reproduce:
1. Insert CD
LXDE in all its glory
smolt profile: http://www.smolts.org/client/show/pub_336b7a02-a02a-4df7-bc74-9dac08eec9a4
FWIW, nvidia driver doesn't work with this version of Xorg either (I know, not your problem). However, nvidia driver does work with X from Fedora 11, whereas nouveau does not (same problem I'm having here). Xorg.0.log of failed startup (from runlevel 3) is attached
I need to see your /var/log/messages also please.
Created attachment 359248 [details]
Created attachment 359249 [details]
xorg.conf copied from working Rawhide installation on my hard drive; allows me to use X with the live CD.
Any updates here? I don't see nouveau mentioned in your /var/log/messages at all, it looks like the module isn't even loaded (which is what the X driver is complaining about).. If everything's installed correctly, X would be able to load the module automatically
No updates -I've been away from my desktop PC for a couple of weeks (and won't be back to it until this ccming Thursday or Friday). Shouldn't the nouveau driver load automatically from the Live CD? If not, what is the proper syntax on the kernel line in grub.conf to get the nouveau driver loaded at boot time?
Yes, it should. Can you give the test day livecd a try and report back, it's linked from https://fedoraproject.org/wiki/Test_Day:2009-09-10.
Just tried the test day livecd. No go. At some point in the boot process, even in runlevel 3, the screen goes blank and stays blank.
Tried again, this time with the desktop-x86_64-20090915.15.iso (the latest of the nightly composes). Cannot get into X. With nouveau.modeset=0 on the grub kernel line, I can boot into runlevel 3, but running startx gives a blank screen and locks the system. Similarly, booting into runlevel 5 results in a system lockup even with nouveau.modeset=0 (with or without xdriver=vesa) gives me the blank screen and a locked system.
Have you got an install by any chance? If so (or when/if you do do an install) can you:
1. Boot into runlevel 3 with modesetting left on
2. Reboot (CTRL+ALT+DEL will do since you can't see the screen)
3. Start in runlevel 3 with modesetting off, and save /var/log/messages so you can upload it here.
Created attachment 361405 [details]
added kernel params for most recent boot: nouveau.modeset=0 3
possible added kernel params for next most recent boot: 3 modeset=0
added kernel for 3rd-most recent boot: 3
No better luck with latest nightly builds. Am I the only person experiencing this bug?
Since this bugzilla report was filed, there have been several major updates in various components of the Xorg system, which may have resolved this issue. Users who have experienced this problem are encouraged to upgrade their system to the latest version of their packages (at least F12Beta, but even better if the very latest versions).
Please, if you experience this problem on the up-to-date system, let us now in the comment for this bug, or whether the upgraded system works for you.
If you won't be able to reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you.
[This is a bulk message for all open Fedora Rawhide Xorg-related bugs. I'm adding myself to the CC list for each bug, so I'll see any comments you make after this and do my best to make sure every issue gets proper attention.]
Created attachment 367685 [details]
/var/log/Xorg.0.log; startx from runlevel3 with Xorg -configure generated xorg.conf.new
With current (4 Nov) nightly compose on a 1GB USB stick with a 128MB overlay, the bug persists. I tried several work-arounds; none of which seemed to work:
1. Straight Boot
a. no signal to screen
2. Add nomodeset kernel parameter
a. saw white and blue bars at bottom of screen during inital boot phase, after which
(when X starts?) screen apparently getting a signal, but stays dark
3. Add nomodeset vga=795 3 as kernel parameters
a. Boots fine in text mode
b. Logged in as root
c. lsmod shows nouveau driver loaded
d. startx gives color in top 1/4 of screen, then screen goes dark as in #2 above; cannot
switch back to tty1 (Ctl-Alt-Backspace has no effect)
4. Repeat #3a-3c
d. Xorg -configure gives the /root/xorg.conf.new file; partial contents below (no
device options selected, so that portion not included:
VendorName "nVidia Corporation"
BoardName "Unknown Board"
e. startx gives color at top 1/4 of screen as in #3 above, then goes dark, but
Ctl-Alt-Backspace breaks out
Attached Xorg.0.log from attempt #4
Created attachment 367940 [details]
xorg.conf that actually works with nouveau driver
With nightly compose desktop-x86_64-20091106.16.iso:
1. Created bootable USB stick and booted as-is
a. same lockup as previous attempt
2. Rebooted into runlevel 3 and logged in as root
a. Ran Xorg -configure. Returned an xorg.conf.new specifying nv driver
b. Ran startx. dark screen - Ctl-Alt-Backspace to exit
3. Actually a continuation of #2
c. Copied working xorg.conf from hard drive to /etc/X11.
d. Changed driver from nvidia (which works fine) to nouveau.
e. Ran startx. X comes up and seems to work just as it should.
FWIW, working xorg.conf is attached.
What happens without an xorg.conf ?
Created attachment 368039 [details]
Working xorg.conf for Nov 8
Without xorg.conf the system locks up with a dark screen (screen still apparently receiving a signal). Have to reboot to get out.
Repeated yesterday's effort, but screen locked up instead of taking me into my gnome session. Kept rebooting and modifying my working (with the nvidia driver) xorg.conf to try to make it work with the 20091106 nightly compose. The attached xorg.conf file worked for me today.
Created attachment 368040 [details]
xorg log for working nouveau driver - goes with 368039
Just tried to start X using the working xorg.conf file from comment #16. No go - system locks up. I hate it when an experiment doesn't yield reproducible results.
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.
More information and reason for this action is here:
What behaviour do you see if you update to kernel-188.8.131.52-58.fc12 (http://koji.fedoraproject.org/koji/buildinfo?buildID=157041) ?
Booting without xorg.conf: gray screen
Booting with xorg.conf: broken-up mini version of my desktop but on a black background
In both cases the system locks up and must be power-cycled to reboot.
NVIDIA-Linux-x86_64-beta-195.30-pkg2.run works fine with the new kernel, if that's any consolation.
Just tried nightly compose desktop-x86_64-20100123.19, which includes kernel 2.6.33-0.20.rc5.git0.fc13.x86_64. It's been siting on my hard drive for a while; I just hadn't tried it. Put it on a 1GB USB stick, and booted twice, both times with selinux turned off. The first time, I just let it boot - no signal to screen when X started. The second time, I booted with nomodeset into runlevel 3, ran startx, and up came X. Will try the latest nightly compose to see if it works.
Created attachment 395610 [details]
Xorg log file; for corresponding xorg.conf see comment
We've regressed. Current nightly compose (desktop-x86_64-20100221.16.iso) will not permit starting X with the nouveau driver; tried with and without nomodeset and both runlevels 3 and 5. Also tried generating an xorg.conf file, reproduced below. No go.
Identifier "X.org Configured"
Screen 0 "Screen0" 0 0
InputDevice "Mouse0" "CorePointer"
InputDevice "Keyboard0" "CoreKeyboard"
Option "Protocol" "auto"
Option "Device" "/dev/input/mice"
Option "ZAxisMapping" "4 5 6 7"
VendorName "Monitor Vendor"
ModelName "Monitor Model"
### Available Driver options are:-
### Values: <i>: integer, <f>: float, <bool>: "True"/"False",
### <string>: "String", <freq>: "<f> Hz/kHz/MHz"
### [arg]: arg optional
#Option "SWcursor" # [<bool>]
#Option "HWcursor" # [<bool>]
#Option "NoAccel" # [<bool>]
#Option "ShadowFB" # [<bool>]
#Option "VideoKey" # <i>
#Option "EXAPixmaps" # [<bool>]
VendorName "nVidia Corporation"
BoardName "Unknown Board"
Viewport 0 0
Modes "1600x1200" "1280x1024" "1024x768"
The nightly compose likely has mismatched nouveau components. The log from trying without "nomodeset" would tell for sure, but, F13 no longer supports "nomodeset" with nouveau so that's expected to fail.
As far as I'm concerned, this bug can be closed; fixed in F13
Okay, since you're the only reporter, will close as WONTFIX for F12.