Red Hat Bugzilla – Bug 135867
X fails to start because it cannot initalise mouse
Last modified: 2007-11-30 17:10:52 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20041002
Description of problem:
Upgrade FC2 to FC3T3. X fails to start, reporting failure to
initialise a mouse. X will start configuration program in text mode
allowing manual configuration of mouse. Mouse will work in text mode
and during attempts to start X. Multiple aternate manual selections
of mouse configuration may be tried. X continues to fail to start.
An examination of /dev reveals the existence of /dev/mouse0, but no
/dev/mouse. Manual editing of xorg.conf to replace reference to mouse
with mouse0 fixes the problem - X starts normally.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Upgrade FC2 with FC3T3
2.Boot machine runlevel 5 fails. Reboot any number of times.
3.Run init 5 manually any number of time, X fails to start.
4.Run GDM any number of times, X fails to start.
Actual Results: Exit to runlevel 3
Expected Results: Successful start of runlevel 5. Successful start of X.
The X server just tries to open what it's configured to open, which
of course has to be properly configured first. If the system is not
configured properly, or has device nodes missing, etc. then the
X server will fail to start which is the correct thing.
This must either be a local system misconfiguration issue, or a bug
in our config tool or something else.
Reassinging to the mouse configuration tool which is the most likely
(Just a note: XFree86 does not exist in Fedora Core anymore, having
been replaced by xorg-x11 now.)
Smells like udev:
Paste in the output of m
mount --move /dev /mnt/dev
ls -al /dev/mouse*
mount --move /mnt/dev /dev
Does system-config-display --reconfig generate a working X configuration?
Did you ever edit your FC2 Xorg.conf, was it an upgrade from an
earlier version - we should be using /dev/input/mice in FC 2 as the
pointer which should exist. The lack of /dev/mouse is likely to be
dev->udev migration, as /dev is now a tmpfs mount rather than a fs,
for persistent changes see the udev docs:
Yes, I suspect udev as well because that changed during the upgrade.
Yes xorg.conf was edited manually to add vnc native x support for :0.
Also this is an upgrade (originally FC1T3 upgraded to FC1, Upgraded to
FC2, upgraded to FC3T3.
I do have a working X configuration due to manual editing of
xorg.conf. I was automatically sent to reconfiguring X after X
display initialization failure and any number of manual configurations
of the mouse failed to start X until xorg.conf was manually changed to
ls -al /dev/mouse*
lrwxrwxrwx 1 root root 10 Jul 2 18:04 /dev/mouse -> input/mice
lrwxrwxrwx 1 root root 15 Jul 2 18:04 /dev/mouse1 -> /dev/input/mice
This confuses me a bit because I only got /dev/mouse0 when I was
checking this earlier (albeit in runlevel 3). Also I don't remember a
symlink, just a device. My xorg.conf now uses mouse0, not mouse or
Yes this is as the old symlinks in /dev are still around on the /
filesystem but we mount tmpfs on /dev. The mount --move temporarily
moved the tmpfs /dev out of the way so we can see the old symlinks.
You should really have had Option "Device" "/dev/input/mice", in
your Mouse0 section if it had been generated. It's hard to tell at
this stage if this is just an artefact of editing or as you updated
from a Test Release -> Production -> test release, which isn't a
"supported" upgrade path.
FC 2 should have had /dev/input/mice as the mouse device, as should
have FC 1 (just checked the rhpl.xhwstate module). Your options are to
create a udev rule to generate the symlink, use /dev/input/mice which
is the recommended option.
The udev upgrade is going to be more brittle on custom config files
referencing /dev, as nodes may not be present and we don't mess with
config files on upgrade. It's not really a s-c-mouse bug, as upgrades
of FC1->FC2->FC3 should work fine as they all use /dev/input/mice.
As such I'm going to close this as NOTABUG. Though I'll check to see
if the release notes emphasise this can happen with non-standard
configs and udev.