Red Hat Bugzilla – Bug 145038
Serial Mouse not recognized - ever.
Last modified: 2015-01-04 17:15:29 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2)
Gecko/20040804 Netscape/7.2 (ax)
Description of problem:
Pentium II. Installed Fedora Core 3.0 - Built/Distributed/Released
11/3/04. Upgrade from Redhat 6.1
Mice didn't work during installation, nor after installation. Had to
login with the failsafe terminal since I wasn't able to access
anything at all (I'm really surprised and disappointed that I couldn't
use tab and alt-tab to get around the various windows/menus).
Logitech Clearcase mouse and also a "Space Walker" mouse. Both are
quite old and work just fine on Windoze. Both are 3 button serial
mice. install.log.syslog contained nothing about a mouse.
Tried running sysconfig-mouse by hand, first window came up and I was
amazed that I was actually able to use cursor keys to move around.
Selected 3-button mouse, tried to select the serial port and a second
window popped up but I was unable to do anything further - it just
hung. Finally gave up and hit the power button.
Went through the same process a second time, however instead of trying
to select the serial port, I simply selected 3 button serial mouse and
hit OK. That worked better. It first tried to shutdown the console
mouse which failed, but then it brought up the console mouse and I was
able to move the mouse around - sort of. The mouse was confined to
the left hand side of the screen - maybe about 1/4 of the left side -
at least most of the time. Occasionally it would touch the terminal
window, but I really had very little control over the placement of the
mouse cursor. So, I was unable to get back to the terminal window and
had to hit the power button again. The 3 finger salute simply doesn't
work. There really should be a way to move to a window even if the
mouse is non-functional so that I can at least try to shut down
cleanly (or ideally, run whatever other command I choose).
Unrelated, it failed to figure out I have a ViewMate monitor but did
detect an S3 Virge. Clearly the hardware detection routines need work.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Install Fedora Core 3
Actual Results: No reaction from mouse
Expected Results: Mouse movement
I'm marking this as "high severity", because the system is unusable
without a mouse. I'm unable to setup the network so I can't even
telnet into it, nor can I do anything useful.
Upgrading to Fedora Core at the recommendation of a coworker, turned a
system that was functioning perfectly well into an unusable paper
weight. This is a major embarrassment because as a consultant I
recommend my corporate clients install Linux. When my personal
experiences are this poor, I'm forced to adjust my recommendations.
Corporate clients frequently have older hardware they'd like to make
use of, recommending they spend hundreds of thousands of dollars on
new hardware so they can run Linux doesn't make a good case for
justifying installing Linux in place of Solaris, HP, AIX or Windoze.
Serial mouse configuration is currently not done in anaconda.
Windows/buttons not being navigable with a keyboard is a separate
issue; please file that against whatever program isn't navigable.
What happens if you boot in text mode and configure the serial mouse
Please re-read the report. I supplied a fair amount of detail, and
already answered your question. You'll also notice I specified
KUDZU, not Anaconda. Please read it slowly and carefully.
As you stated:
> Mice didn't work during installation, nor after installation.
and I simply told you that serial mouse configuration is not done in
the installer, so this is expected.
The other question still remains.
Clearly Bill Nottingham is brain dead and can't read.
Obviously I need to advise my corporate clients that redhat/fedora
isn't worth the trouble, the personnel they have working there are
Time to try the next distribution. It couldn't be any worse.
Somehow he can't seem to see "Mice didn't work during installation,
NOR AFTER INSTALLATION".
"Had to login with the failsafe terminal since I wasn't able to
access anything at all" "Tried running sysconfig-mouse by hand, first
window came up...Selected 3-button mouse, tried to select the serial
port and a second window popped up but I was unable to do anything
further - it just hung."
"Went through the same process a second time, however instead of
trying to select the serial port, I simply selected 3 button serial
mouse and hit OK. That worked better. It first tried to shutdown
the console mouse which failed, but then it brought up the console
mouse and I was able to move the mouse around - sort of. The mouse
was confined to the left hand side of the screen - maybe about 1/4 of
the left side - at least most of the time. Occasionally it would
touch the terminal window, but I really had very little control over
the placement of the mouse cursor. So, I was unable to get back to
the terminal window and had to hit the power button again."
Maybe there's someone over there able to read English... best to pass
it on to them Bill, clearly you're in over your head.
An answer of "serial mouse installation isn't done in the installer"
isn't an answer at all. That's known as "passing the buck", which is
typical of people who have no idea what they're doing.
Well where IS serial mouse installation done, Bill? Obviously it's
not done in sysconfig-mouse either; no thanks for the clue. Should I
buy some magic beans - maybe that will help?
Jeez. If you were my employee you'd be looking for a new job.
Because serial mouse configuration isn't done in the installer, it's
more or less a given that it won't work after install without
You've attemped in both cases to run the mouse configuration tool from
X windows; as I asked the first time, what happens if you run the
configuration tool from text mode? Unfortunately, in some cases, X
does not respond well to the mouse being changed under it.
If the answer I've given isn't sufficient to answer your question,
then isn't it obvious that I need additional details so that I can do
what it is you're requesting? To the best of my knowledge, I've done
as you've asked, and supplied that information on the very first go
round. Does it make you feel superior to spar with me? Why don't
you give me step by step details as to HOW to run the configuration
tool from text mode if you don't think that's what I've already done?
(ie. how do I get into text mode - specifically? IS the
configuration tool sysconfig-mouse? If not, what's it called?
What's the full path?) Contrary to popular thought, I can't read
I also support clients/users. The difference is, I give them clear
instruction as to how to perform whatever action it is I'm requesting
they do. At worst I might say something like "You need to change
your oil. If you don't know how to change your oil, please ask so I
can give you detailed instructions". Then at least I can say "gee, I
thought I did when I entered the fail-safe terminal. If that's not
text mode, then ok please give me detailed instructions."
And, if it becomes obvious they're not getting it, I say things
like "First, you need a jack. If you don't know what a jack is,
please ask so I can explain it. Then, jack up your car. Slide
under, find the oil filter. The oil filter is round. Twist the oil
filter in a counter-clockwise direction..." Ya follow? No, I'm not
a mechanic, it was an example that almost anyone can understand.
OK, so there are two different ways you can log in; graphical mode
(AKA X Windows); this is the default, and it's what you get with
the GUI login screen that says Fedora Core, no matter what session
There's also the text (or console) mode. To get to that, there
are two ways:
From the bootloader, select 'e' to edit your boot entry. On the line
that says 'kernel /boot/vmlinuz....', edit it so that the last
thing on the line is '3':
Instead of, for example:
root=LABEL=/ rhgb quiet
it should be:
root=LABEL=/ rhgb quiet 3
2: Log in graphically as root (as normal), and then open a terminal,
However, if the mouse isn't working, this may be difficult,
In either case, you should get to a text screen with a login prompt.
Then you can log in as root there, and run system-config-mouse. This
will start a different version of the same config tool. After it's
done running, you can restart the graphical login by running
Hopefully, it will work better that way.
If it does not work, attaching /etc/sysconfig/mouse. Most likely,
it's an issue with either:
a) the config tool writing out the config incorrectly
b) the serial redirector to the input layer not working
c) X not reading /dev/input/mice right
Assigning to system-config-mouse, for the first of those cases.
Thank you. Much better. Now that you've spelled it out, I
understand what you were saying.
I tried option 2 - "init 3", unfortunately that froze at "starting
anacron" so I ended up modifying the boot entry.
Booted up in text mode as you requested, and ran /usr/bin/system-
config-mouse However, before running that, I took a look
at /etc/sysconfig/mouse, and it had /dev/ttyS0 as my mouse device.
So I tried cat < /dev/ttyS0 and it said "device busy" (obviously some
process already had the device open). So I tried the same thing with
ttyS1 and I got better results, it opened the device, however when I
rolled the mouse around, instead of getting random garbage characters
equivalent to line noise as I would of expected, I got what I assume
were control characters, as it moved the cursor around and
highlighted parts of the screen. So, that was kind of odd.
Anyway I ran system-config-mouse, selected ttyS0 and changed levels
with init 5. Long story short, I tried both S0 and S1 with both
generic MS compatible serial mouse, and Logitech C7 serial mouse.
Although I got various results, the bottom line is nothing truly
I notice /usr/sbin/inputattach and gpm are both running, at least in
text mode (not sure about X). Is that correct? In text mode, the
mouse cursor moves, but only in the last column and the last 3 or 4
rows. So it's limited to a small vertical line of movement - in text
I killed both processes, and tried the cat < again, this time ttyS0
seemed to be the only one responding - although the characters coming
back seemed wrong to me - this implies the driver isn't right in some
way, shape or form. This could possibly point to item B in your list
Based on your debugging it looks as if it may be the input layer - can you try
with the most recent FC3 update kernel.
Reassigning to kernel
An update has been released for Fedora Core 3 (kernel-2.6.12-1.1372_FC3) which
may contain a fix for your problem. Please update to this new kernel, and
report whether or not it fixes your problem.
If you have updated to Fedora Core 4 since this bug was opened, and the problem
still occurs with the latest updates for that release, please change the version
field of this bug to 'fc4'.
This bug has been automatically closed as part of a mass update.
It had been in NEEDINFO state since July 2005.
If this bug still exists in current errata kernels, please reopen this bug.
There are a large number of inactive bugs in the database, and this is the only
way to purge them.