When I clicked the "Test this configuration" button during the X config (graphical install), I got the test screen. However, after I clicked that the display was okay and I got the installer back, the "Test" button was still depressed. I could not click on anything else (nothing happened when I did). I could get to other consoles with Ctrl-Alt-Fn. I went back to the installer console. It was still the same (clicks did nothing), except that when I clicked on the (still depressed) "Test" button, it did the X test again. I again clicked the okay button, and after I got back to the installer I could not do anything else. The mouse cursor moved around, but clicking did nothing, and the keyboard wouldn't either. I suspect the problem is that I have a Logitech MouseMan+. The installer uses it as a generic PS/2 mouse (since you don't get the option to select your mouse until after you are in X). When the X configuration is tested, it probably uses the selected mouse protocol. The MouseMan+ protocol is incompatible with the regular PS/2 protocol as I understand it, so I guess the problem is that once the mouse is switched into MouseMan+ mode it doesn't automatically go back to PS/2 protocol (this is just from my experience: I know you cannot use gpm on a console talking PS/2 proto and X on another VC talking MM+). A couple of solutions come to mind: 1) Restart X if a different mouse type is selected (kind of ugly, but maybe not a bad idea if the installer guesses wrong and someone uses the keyboard to choose a mouse type). 2) Use the same mouse protocol for the "Test this configuration" button that is already being used by the installer. 3) Even uglier solution: try to probe for mouse type _before_ starting X and allow the user to override.
Greetings- I, too, hit this bug. I also have a Logitch mouse. Not sure of the exact type. Says M-C48 underneath. The installer autodetected the mouse as a PS/2, which is fine. Unlike the original filer, I did _not_ change the type of mouse because it works fine. The installer hanging strikes me as a pretty serious bug - maybe the severity should be bumped up to "high"?
Argh! I hit this again with BETA2 (version updated) Severity updated -> it's a royal pain. Killing the installer is very serious.
Doesn't kill installer for me, but mouse input becomes erratic after X returns (cursor acts spastically along top of screen only). This from using a Logitech Cordless Wheel Mouse with the Intellimouse PS/2 protocol, as usual.
I believe this bug really are 2 bugs: -some people loose mouse cotnrol after testing X, because: -installer X probed a mouse and uses this -user selected different (wheelmouse (imps/2) ) protocol -test X uses different protocol, works -return to installer X -mouse is in new protocol mode -loose mouse control -some people see a complete hang after testing X I belive that the first is a duplicate of bug 12084
This defect is considered MUST-FIX for Winston Beta-5
Does this defect still exist with (on) Winston beta-4?
A fix is in CVS, needs verification
The part of this bug, which was caused by the mouse being in wheelmouse mode after testing is now fixed, see bug 12084
Still affects BETA5 - killed the installer on me :-( To recap - Mouse is detected as"Generic PS/2" - I DON'T change this - Pressing "Test X" button leads to locked interface on return to installer - Mouse moves around OK, but no click gets any response - "Test X" button remains depressed
What kind of video card please?
3dfx Voodoo3 2000 PCI (Mouse is Logitech M-C48)
It's the voodoo that's causing the problem now, I'm almost positive (I've seen this).
Good chance - that's what I have too (Voodoo3 3000). I've also got a Logitech MouseMan+ PS/2 (M-CW47). I haven't had a chance yet to try beta5 (just got the CDs today), but it doesn't look like there will be any difference.
Bill said the fix will not make it into this release. The work-around is to *not* test X during the GUI install.
*** This bug has been marked as a duplicate of 15084 ***