Hide Forgot
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040809 Description of problem: The system mouse is not being found when the Xorg server is loaded when booting from kernel 2.6.8-1.541. Booting from 2.6.8-1.524 runs the X server fine with no other changes. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. boot with kernel 2.6.8-1.541 into a rhgb 2. 3. Actual Results: Screen goes blank after initializing hardware message. Cannot switch to a console using alt+crtl+F*. Login does not fall back to non-graphical mode. Expected Results: Expect to see rhgb start normally or, if there are problems, fail gracefully to a text login prompt or be able to switch to a console. Additional info: ATI 8500 AIW video card I have a KVM switch
Created attachment 103574 [details] X server log when failing while booting kernel 2.6.8-1.541
Created attachment 103575 [details] X server log when sucessfully running with same config but while booting kernel 2.6.8-1.524
What's your xorg.conf? What happens if you change the device from /dev/mouse to /dev/input/mice?
I'm not the original poster, but that fixed it for me. The incompatibilty is present in all kernels after 2.6.8-1.533 Why does X care if it has an pointer device? It certainly shouldn't crash the system just because it can't find one. I'll attach my xorg.conf as it was *before* changing /dev/mouse to /dev/input/mice I verified that I can still use both the USB and the PS2 mouse after the change.
Created attachment 103612 [details] xorg.conf before fix
Created attachment 103619 [details] Here is my xorg.conf ... it already had the /dev/input/mice in from manually editing it long ago when I got by that problem before
Oops ... sorry ... it actually has two sections with /dev/input/mice and /dev/mouse in it ... So does John's in attachment 103612 [details] by the looks of it. I am not sure if this is proper by I am pretty sure I didn't add a whole other section manually. I would have just changed the device name earlier. I will check if changing both instances to /dev/input/mice fixes things.
Try changing the /dev/mouse in your *first* InputDevice to /dev/input/mice. Worked for me.
Changing the first one to /dev/input/mice worked for me also. Thanks! The fail safe drop back to text login didn't work though ... I thought that it used to do that. At least it did when I had X issues in the past. Regardless, I am back on track.
>Why does X care if it has an pointer device? Because the X server must have at least one configured pointer device as per X11 specification. The pointer device needs to be able to be successfully opened. If the device open fails, then the pointer can't be opened, and the X server will refuse to start. If you run pointerless kiosks or similar, the X server manpages describe an option you can use to force the server to start without a pointer device, however that is not the default behaviour (and shouldn't be). >It certainly shouldn't crash the system just because it can't find >one. It doesn't. If the X server can't open the pointer device that is specified in the config file, it will simply display a fatal error to the console and log file indicating the configured pointer device could not be opened, and then exit. This does not and should not crash the system. You should end up in a text mode console, with a running system. Hope this helps.
As mentioned above, the X server requires a single pointer to be configured correctly, and that device must be able to be opened, or you must configure the server to start pointerless manually if you wish to use the X server without any pointer. If the server works with one kernel, and a kernel upgrade causes the server to no longer be able to start, it is either a kernel bug that broke the input driver, or as is the case between 2.4 and 2.6 kernels, you need to use /dev/input/mice. In the latter case, this isn't a bug, but rather a misconfiguration of your X server under a 2.6 kernel, since /dev/psaux no longer exists. Our installer handles this gracefully. Manual upgrades may require manual reconfiguration. Setting status to "NOTABUG".
Would it be worth opening up another bug specifically spelling out the behaviour of the X Server crash recovery never going back to text mode nor letting you switch with the F-keys to a text console? Is failure to cleanly fail when misconfigured a bug that will be fixed? I would guess that this is a problem with the scripts that detect an X Server failure and retry not giving up rather than the X Server itself ... but I don't know where that occurs.