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): firstboot-1.2.1-1 How reproducible: Always Steps to Reproduce: 1. Do a clean install of fedora test 2 2. On firstboot screen mouse does not work 3. Expected Results: Mouse should work Additional info:
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.