Red Hat Bugzilla – Bug 100874
Mouse moves erratically only while firstboot is run
Last modified: 2007-04-18 12:56:09 EDT
Description of problem:
Mouse moves erratically while firstboot is run, although it works normally
during the graphical install and after firstboot is finished.
Version-Release number of selected component (if applicable):
It happened both times I installed it.
Steps to Reproduce:
1. Install severn beta1
2. Reboot and log in
During configuration the mouse is erratic. I had to use the keys to
navigate, since the pointer kept hopping to the bottom left corner
of the screen.
Pointer would move as the mouse is moved.
The mouse is /dev/psaux, and it works perfectly during the install and
after firstboot. I'm installing this in a virtual machine using VMware,
and this shouldn't make any difference, since the mouse works perfectly
in my other virtual machines. It only has a problem with firstboot.
This issue happens to me also on a normal Workstation install of Severn on a
Dell XPS T550 system. The mouse is impossible to use during firstboot.
jrb, I've started to see numerous reports of wonky mouse and keyboard behavior
in firstboot in the Severn beta that I have not seen in previous releases. My
guess is that there is something strange with rhgb that is causing input devices
to misbehave. I'm changing the component to rhgb although the problem may lie
with X itself.
I've also seen this happen (with a fresh install, no VMware) on a HP Vectra
Same problem here using VMWare 4.01. The mouse jumps to the bottom left corner.
If I move the mouse up or to the right the cursor moves as expected, but if I
move the mouse a little bit to the left or to the bottom it jumps to the bottom
left corner of the screen immediately.
That particular erratic mouse behavior sounds suspiciously like how an IMPS/2
wheel-mouse behaves with 2-button PS/2 mouse protocol. Check the current mouse
protocol when this behavior occurs.
This bug is with real hardware as well.(and I have check the mouse protocol)
HP Pavilion 533c
standard ps/2 mouse
the mouse stays almost stuck in the left-bottem corner of the screen. My guess
iss something with graphical boot+ X and firstboot
forogt to mention I'm using Fedora test2
*** Bug 105627 has been marked as a duplicate of this bug. ***
I have experienced the same problem on the first boot run.
I have noticed this same "mouse jam" happens always during graphical boot
display if you try to move the mouse pointer.
Does it behave sanely if you disable kudzu (chckonfig --level 5 kudzu off)
Disabling kudzu fixed the problem for me.
i would add to this that after using the keyboard to alt-tab and 'ok' around -
the mouse started working (flakey) but i was unable to *INPUT TEXT* in dialogue
boxes about NIS settings or other information.
Assuming kudzu is reenabled, does kudzu-1.1.31-1 or later behave OK for you?
How do you suggest we test this?
I have a severn test 2 system which has been updated to "current" as of 03 Oct
2003. My "plan" is to edit /etc/sysconfig/firstboot and change it be
Will this test things?
rm -f /etc/sysconfig/firstboot
chkconfig --level 5 firstboot on
OK, I see your update and will thry that. I did do the following:
I tried changing /etc/sysconfig/firstboot as described above ... no firstboot
I looked at /etc/init.d/firstboot and saw that a "reconfig" boot parameter
should do it and that /etc/sysconfig/firstboot was not really referenced ...
still no firstboot
I then looked at /etc/init.d/firstboot and saw the file so I "touch
/etc/reconfigSys" ... still no firstboot.
Based on what you said, I assume that firstboot turns itself off once it runs.
What is the purpose of the reconfig and /etc/reconfigSys stuff?
OK, sorry but it is still broken (and a real pain to get though firstboot since
if the mouse is not over the firstboot panel, I cannot even use tabbing to
BTW, I am not sure if this has anything to do with the problem ... I am booting
with the gui bootup. During that bootup, moving the mouse is also a bit erratic.
*** Bug 106497 has been marked as a duplicate of this bug. ***
Installed new rhgb-0.10.2-1.i386.rpm which makes the bootscreen look very nice
but now the mouse behaves like this (returning to lower-left corner) as long as
the bootscreen is showing.
Fixed in kudzu-1.1.32-1.
That fixed it for me, but I'll leave it up to the original reporter to actually
OK, mostly fixed ...
I installed al of the updates as of morning of 9 Oct. I then rebooted. I
figured that the problem was mostly fixed when the cursor stayed after the
I then removed /etc/sysconfig/firstboot and did:
chkconfig --level 5 firstboot on
I then rebooted.
Went throught the rhgb as before and then entered fistboot. AT FIRST, the
cursor skipped around like it did before but after a couple of movements, it
settled down and I was able the the firstboot stuff.
I am going to try one more thing and move the cursor during the gui boot to see
if that makes a difference.
OK, I played with the mouse (actually trackball) during the gui boot. At first
it moved but then disappeared. A bit later it reappeared as an hour-glass
around the middle of the screen. When it got to firstboot, the cursor was no
apparent so I moved it and it appeared in the bottom left (no the corner). This
time it stayed stable and I could get through firstboot OK.
While not perfect, the kudzu fix seems to fix most of the problem. I am not
sure what is going on but it is likely some strange corner case. While there is
higher priority stuff to be fixed, this is likely "good enough" for now. For
compleness and to always "look good", this needs to be fixed someday.
Note that the cursor was intentionally made to disappear as a feature. I have
removed this in the version in CVS and replaced it with a standard cursor.
Red Hat Linux and Red Hat Powertools are currently no longer supported by Red
Hat, Inc. In an effort to clean up bugzilla, we are closing all bugs in MODIFIED
state for these products.
However, we do want to make sure that nothing important slips through the
cracks. If, in fact, these issues are not resolved in a current Fedora Core
Release (such as Fedora Core 5), please open a new issues stating so. Thanks.