Bug 105627 - no mouse on first boot screen
no mouse on first boot screen
Status: CLOSED DUPLICATE of bug 100874
Product: Fedora
Classification: Fedora
Component: firstboot (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Brent Fox
: 105648 107230 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2003-09-26 00:05 EDT by Todd Booher
Modified: 2007-11-30 17:10 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-02-21 13:58:45 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Todd Booher 2003-09-26 00:05:10 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703

Description of problem:
After a clean install of Fedora test 2 on the first boot
screen my mouse did not work (no activity).  The hardware
is an IBM T30 laptop with pointing stick.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.  Do a clean install of fedora test 2
2.  On firstboot screen mouse does not work

Expected Results:  Mouse should work

Additional info:
Comment 1 Eugenia Loli-Queru 2003-09-26 02:10:39 EDT
I concur. On my AthlonXP desktop the mouse is there, but the mouse cursor is
jumping all over the place. I used TABs to move away from the
first-boot-setup-screen (and is difficult to do as the first two screens don't
support TAB movement). After you finish with that screen,  then the mouse is
working. But the first setup screen on your first boot,  does not and that can
be a bit ugly for newcomers... :)
Comment 2 Tom DuVally 2003-09-26 12:03:25 EDT
Same here.  I've seen similiar behavior in X when trying to use an ImPS/2 mouse driver with the wrong mouse.  
The cursor will jump to the bottom left of the screen when the mouse in pulled down, but moving the mouse up or right will (usually) work properly.  Thats is the behavior I see in the firstboot screen.
Comment 3 Bill Nottingham 2003-09-26 15:33:37 EDT
Did you boot with graphical boot?
Comment 4 Bill Nottingham 2003-09-26 15:46:23 EDT
*** Bug 105648 has been marked as a duplicate of this bug. ***
Comment 5 Todd Booher 2003-09-26 16:19:53 EDT
Yes, I did boot with the graphical boot.  The mouse cursor is seen
on the screen but you cannot move it.
Comment 6 Gene Czarcinski 2003-09-26 16:52:16 EDT
Additional info:

On the same hardware and with a wheel mouse (actually Logiteck TrackMan Wheel):

If I install and then bootup with gui boot, the mouse goes screwy during

I then did another fresh install into separate partitions but the initial boot
was nogui ... mouse behaved properly.
Comment 7 Bill Nottingham 2003-09-26 17:06:55 EDT
I am assuming in *all* cases here we're talking about PS/2 mice?
Comment 8 Todd Booher 2003-09-26 17:46:12 EDT
In my case, it was the pointing stick on an IBM T30 laptop.  I selected
ps2 3 button mouse during install.
Comment 9 Anthony Green 2003-09-27 12:03:09 EDT
I see the same thing.  I'm using a ps/2 wheel mouse.

As a work-around, switching to a virtual terminal (CTRL-ALT-F1) and back
(CTRL-ALT-F8) restores mousecular countrol.
Comment 10 Bill Nottingham 2003-09-29 00:00:56 EDT

*** This bug has been marked as a duplicate of 100874 ***
Comment 11 Todd Booher 2003-09-29 10:57:10 EDT
I don't believe this bug is a duplicate of 100874.  In this case, the
mouse did not move at all vs. eratic movement in 100874.

Your call, just thought I would mention that.
Comment 12 Gerry Tool 2003-10-14 14:31:28 EDT
This happened to me on a fresh Test 3 install.  I agree with Additional comment
#11.  This problem is NO mouse cursor exists, not erratic movement.  I have a
PS/2 Wheel mouse.  Previous installs of Test 1 and Test 2 did not exhibit this
problem for me.
Comment 13 Todd Booher 2003-10-14 15:43:46 EDT
Same problem on a fresh install of test 3 on the same thinkpad T30.  Mouse
cursor did not move at all until switching to terminal 1 and then back to
terminal 7.
Comment 14 Brent Fox 2003-10-14 18:15:18 EDT
notting, does this sound like a rhgb/kudzu interaction problem to you?  It
doesn't seem like firstboot is the correct component.
Comment 15 Bill Nottingham 2003-10-14 18:43:05 EDT
Click on show details; when does the mouse quit functioning?

It's entirely possible it's an rhgb/gpm interaction.
Comment 16 Brent Fox 2003-10-15 20:39:34 EDT
*** Bug 107230 has been marked as a duplicate of this bug. ***
Comment 17 Brent Fox 2003-10-15 20:45:35 EDT
I agree with notting's previous assessment of this as a dupe of bug #100874.  If
the updated kudzu-1.1.32-1 doesn't fix the problem, please reopen this bug.

*** This bug has been marked as a duplicate of 100874 ***

*** This bug has been marked as a duplicate of 100874 ***
Comment 18 D. Hugh Redelmeier 2004-01-12 19:59:54 EST
I'm experiencing symptoms like this when installing fedora core1.
Fedora core1 installs kudzu-1.1.36-1 so kudzu-1.1.32-1 would be a

Note: a Red Hat LINUX 9 installation worked fine.

I've installed FC1 twice on this machine:
- eMachine T2341 desktop; Athlon XP 2400+
- 384M of ram; 10G partition for /; 10G for /home; 1G for swap
- S3 ProSavage KM133 integrated video (S3 is a common factor with some
reports of this problem on Thinkpads)
- logitech 3-button PS/2 mouse; PS/2 keyboard
- electronic KVM switch which prevents automatic detection of monitor
model (never switched away during this session)

Both times, installation is smooth until firstboot.  Screen comes up
fine but mouse movement has no effect on mouse pointer.  Keyboard gets
no response either.

I *can* ssh in from another machine!  I'm poking around to see if
anything obvious is botched.

dmesg shows about 350 repetitions of the following line, all in a row:
    pc_keyb: controller jammed (0x39).

I remember that the lights on the keyboard flashed quite a number of
times while FC1 was coming up.  According to
drivers/sbus/char/pcikbd.h, these status bits are:

#define KBD_STAT_OBF            0x01    /* Keyboard output buffer full */
#define KBD_STAT_CMD            0x08    /* Last write was a command
write (0=data) */
#define KBD_STAT_UNLOCKED       0x10    /* Zero if keyboard locked */

#define KBD_STAT_MOUSE_OBF      0x20    /* Mouse output buffer full */

After rebooting (via a "reboot" command issued through ssh), the
behaviour was the same.  I then plugged in a USB mouse (in addition to
the PS/2 mouse) and worked my way through firstboot.  I then changed
inittab so that the initial runlevel would be 3.  I then rebooted.

All appeared well.  startx even worked.  So something was screwed up
until firstboot finished its work (maybe).
Comment 19 Red Hat Bugzilla 2006-02-21 13:58:45 EST
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.

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