Bug 13323 - [graphical install] installer doesn't react after a while
Summary: [graphical install] installer doesn't react after a while
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: anaconda   
(Show other bugs)
Version: 7.1
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Brock Organ
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2000-07-02 01:52 UTC by Christian Rose
Modified: 2008-05-01 15:37 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2000-07-21 16:54:55 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Christian Rose 2000-07-02 01:52:40 UTC
After a while using the graphical installer and moving between various
screens, the installer always "locks up" in an interesting way: the mouse
pointer is still moveable, but nothing reacts to mouse clicks or key

This happens every time I use the graphical installer, but not at the same
time every time. The system is as follows:

CPU:    Pentium 233 MMX
Memory: 96 MB
Disk:   650 MB IDE
Cdrom:  16x
Video:  Matrox Mystique   (170 MHz RAMDAC, 4 MB RAM)
NIC:    Intel Etherexpress 100+
Mouse:  Regular two-button PS/2

Could this be related to glitchiness in the X server?

Comment 1 Michael Fulbright 2000-07-05 17:01:40 UTC
If you switch with virtual console 1 (hit alt-cntl-f1) is there any
error messages, like a python traceback?

Comment 2 Christian Rose 2000-07-05 19:24:27 UTC
I can't switch to console, since the system doesn't respond to any keyboard
input whatsoever. The only thing that indicates that the system isn't completely
frozen is that the mouse pointer is still moveable (but nothing responds to
mouse clicks, and some icons for the back and next buttons tend to disappear
when the system behaves this way).

I can't always reproduce it. I can perform a complete install without this
problem, but it can also happen right in the keyboard selection window.
There is no recovery except a hard reboot, since it doesn't react to keyboard

Comment 3 Matt Wilson 2000-07-15 16:00:59 UTC
Does it still happen in beta3?

Comment 4 Christian Rose 2000-07-16 19:12:37 UTC
No, I haven't had this problem yet with beta3 (but I've only performed one
install with beta3, and that worked fine). I'll test it more extensively when
beta4 arrives. If it still works, I'll close this bug.

If this problem was related to X, it might have been solved with 4.0.1 in beta3?
Or am I totally off?

Comment 5 Glen Foster 2000-07-18 19:54:06 UTC
This defect is considered MUST-FIX for Winston Beta-5

Comment 6 Erik Troan 2000-07-21 16:54:53 UTC
Probably an X problem -- calling it fixed.

Comment 7 Christian Rose 2000-07-22 23:44:25 UTC
As I haven't been able to reproduce this in neither beta3 nor beta4, I'm closing
this bug.

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