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... :)

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.

Did you boot with graphical boot?

*** Bug 105648 has been marked as a duplicate of this bug. ***

Yes, I did boot with the graphical boot.  The mouse cursor is seen
on the screen but you cannot move it.

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
firstboot.  

I then did another fresh install into separate partitions but the initial boot
was nogui ... mouse behaved properly.

I am assuming in *all* cases here we're talking about PS/2 mice?

In my case, it was the pointing stick on an IBM T30 laptop.  I selected
ps2 3 button mouse during install.

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.

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

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.

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.

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.

notting, does this sound like a rhgb/kudzu interaction problem to you?  It
doesn't seem like firstboot is the correct component.

Click on show details; when does the mouse quit functioning?

It's entirely possible it's an rhgb/gpm interaction.

*** Bug 107230 has been marked as a duplicate of this bug. ***

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 ***

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
downgrade.

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).

Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.