From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2)
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):
Steps to Reproduce:
1. boot with kernel 2.6.8-1.541 into a rhgb
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.
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
I verified that I can still use both the USB and the PS2 mouse after
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
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
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.