Bug 135867 - X fails to start because it cannot initalise mouse
X fails to start because it cannot initalise mouse
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: system-config-mouse (Show other bugs)
3
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Paul Nasrat
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-10-15 11:22 EDT by Emerson House
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-10-18 12:01:27 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Emerson House 2004-10-15 11:22:50 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20041002
Firefox/0.10.1

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):
xorg-x11-6.8.1

How reproducible:
Always

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.

Additional info:
Comment 1 Mike A. Harris 2004-10-16 04:04:42 EDT
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
suspect.


(Just a note: XFree86 does not exist in Fedora Core anymore, having
 been replaced by xorg-x11 now.)
Comment 2 Paul Nasrat 2004-10-18 00:38:53 EDT
Smells like udev:

Paste in the output of m

mkdir /mnt/dev
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:

http://people.redhat.com/harald/udev.html
Comment 3 Emerson House 2004-10-18 09:34:56 EDT
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
mouse0.

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
mouse1.
Comment 4 Paul Nasrat 2004-10-18 12:01:27 EDT
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.

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