Red Hat Bugzilla – Bug 69718
mozilla install hangs causing anaconda to fail.
Last modified: 2007-04-18 12:44:27 EDT
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.
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.
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.
This install fails on installs with 2.66 and 2.8 processor speeds. Slower processors install fine so far.
This was just seen today on a PowerEdge 4600 with 2.8 GHz Xeon processors.
Needs fix for Hampton in Dell's factory install procedure. RH says it's fixed in Milan already.
Matt: Is Robert Hentosh's fix sufficient for 7.3?
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.
(restricting back to beta team for now)
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?
Chris: Please verify as well that Mozilla has this problem corrected as well.
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.
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.
This is now in the 1.0.1-17 build.
Confirmed Fixed.