Bug 69718

Summary:	mozilla install hangs causing anaconda to fail.
Product:	[Retired] Red Hat Linux	Reporter:	Robert Hentosh <robert_hentosh>
Component:	anaconda	Assignee:	Michael Fulbright <msf>
Status:	CLOSED RAWHIDE	QA Contact:	Brock Organ <borgan>
Severity:	high	Docs Contact:
Priority:	medium
Version:	7.3	CC:	blizzard, john_hull, pbrown
Target Milestone:	---
Target Release:	---
Hardware:	i686
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2002-09-26 16:19:43 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 Robert Hentosh 2002-07-24 19:35:43 UTC

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3)
Gecko/20020523

Description of problem:
Anaconda crashes with "resource busy" error when it goes to eject the cdrom for
the next CD during the install.  Switching to console 2 and using lsof I can see
that "regchrome" from the mozilla install has fd's open to /mnt/source
preventing umount'ing.

There is a perl script that was created due to bugzilla #60726.  The script does
a kill -9 of regchrome, if the process doesn't finish within 1 min.  There are
still threads/procs afterwards.  Doing a 'killall regchrome' (SIGTERM) gets rid
of them and permits the install to continue past the media change.

Version-Release number of selected component (if applicable):


How reproducible:
Sometimes

Steps to Reproduce:
1. Install RedHat 7.3 via CDROM media and select "Custom install" and then
"Everything" on the package list.  It appears more frequently when "Everything"
is selected. And disappears at when fewer packages are installed.  
2. Wait for media change.

At a failed install, one can kill off regchrome and run it manual from the 2nd
console and regchrome will fail in approximately 1 out of 5 times.


Actual Results:  Anaconda crashes with "resource busy".

Expected Results:  Install continues on to the second CD.

Additional info:

regchrome is also execued during the second CD when mozilla-chat rpm is installed.

I have modified umount proc in isys.py file to include a os.system( "killall
regchrome" ) and sleep before the umount so as to patch the install without
modifying the media that would be required to change the perl script in the
mozilla rpm. This patches the problem.

Comment 1 Michael Fulbright 2002-08-02 18:57:38 UTC

This is the first report of this problem - we'll keep it open in case we get more.

We have some code in our current tree that might make this affects of this less
drastic (it will be able to eject the CD), but the real problem is mozilla's
postscript is not exitting.

Comment 2 Robert Hentosh 2002-08-09 21:59:31 UTC

We are now seeing this on another platform (A workstation) after rev'ing the
processor speed higher.  I do not have the details on the configuration, yet.

Comment 3 Robert Hentosh 2002-08-12 22:09:11 UTC

This install fails on installs with 2.66 and 2.8 processor speeds.  Slower
processors install fine so far.

Comment 4 John A. Hull 2002-08-12 22:20:46 UTC

This was just seen today on a PowerEdge 4600 with 2.8 GHz Xeon processors.

Comment 5 Matt Domsch 2002-08-13 18:23:57 UTC

Needs fix for Hampton in Dell's factory install procedure.  RH says it's fixed 
in Milan already.

Comment 6 Preston Brown 2002-08-20 15:52:08 UTC

Matt: Is Robert Hentosh's fix sufficient for 7.3?

Comment 7 Matt Domsch 2002-08-20 18:12:08 UTC

We're testing the 'killall regchrome' workaround in our Hampton FI process 
right now - hope to have results back this afternoon.

While we haven't yet seen this fail in Milan, we're not convinced that a) we 
know what the root cause is, therefore b) that it's been fixed in that release.

Comment 8 Matt Domsch 2002-08-20 18:13:48 UTC

(restricting back to beta team for now)

Comment 9 Robert Hentosh 2002-08-20 19:27:57 UTC

We have a work around in progress for our factory.  But two issues remain.

 - The customers can see this when installing 7.3 by hand.

 - Although we have not seen the problem in Milan.  The mozilla-rebuild-
databases.pl script is the same.   Has this problem been root-caused so that it 
can be determined if it will appear in the 1.0.1 version of Mozilla in Milan?

Comment 10 Preston Brown 2002-08-20 20:23:46 UTC

Chris:  Please verify as well that Mozilla has this problem corrected as well.

Comment 11 Robert Hentosh 2002-08-20 22:21:56 UTC

To solve the problem of customers installing this by hand, an anaconda update 
diskette from Red Hat is needed to work around the issue.

Flipping to the F2 console or skipping the mozilla install isn't that nice of a 
work around.

Comment 12 Christopher Blizzard 2002-08-21 16:25:09 UTC

This is the first report of problems like this that I've seen in Milan or 7.3.

Just a little background here - I added the kill in 7.3 for a few reasons:

o People had added unsupported modules into their components directory and since
upgrades of Mozilla sometimes change internal module interfaces, re-registering
would cause hangs.

o Sometimes, even on a fresh install I would get a hang.

I haven't seen this hang on any 1.0.x Mozilla installs and I know there were
some bug fixes related to leaks and hangs during registration since the 0.9.9
release.  Lots of them, in fact.

The real problem here is that kill -9 leaves threads hanging around.  I can add
a 'killall regxpcom' and 'killall regchrome' to the rebuild-databases script but
I don't think that's something that can be added to a driver disk for 7.3.

Thanks a lot for the bug report.  I'll add this to the script for the next
Mozilla rebuild.

Comment 13 Christopher Blizzard 2002-08-22 15:28:07 UTC

This is now in the 1.0.1-17 build.

Comment 14 John A. Hull 2002-09-26 16:19:37 UTC

Confirmed Fixed.