Bug 13323

Summary:	[graphical install] installer doesn't react after a while
Product:	[Retired] Red Hat Linux	Reporter:	Christian Rose <menthos>
Component:	anaconda	Assignee:	Brock Organ <borgan>
Status:	CLOSED RAWHIDE	QA Contact:
Severity:	high	Docs Contact:
Priority:	high
Version:	7.1
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2000-07-21 16:54:55 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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

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

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.