From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0; compaq)
Description of problem:
I was attempting to install RH 7.1 on an AMD Athlon-based system on a new
8GB disk (another disk in the system has SuSE 7.1 installed), and it got
through the package installations. A window popped up saying, "Performing
post-install configuration" and it sat there for a few minutes, when the
thermometer reached about 50%, and another box popped up saying, "An
exceptional condition has occurred. This is most likely a bug...." and
gave me some text to report to you (I saved it to a floppy, and will be
attaching that to the report).
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Begin RH 7.1 installation on Athlon system (I only have one avail.)
2.Select packages (custom workstation, most defaults plus a few additional
3.Wait for install to finish
4.Get error, reboot
Actual Results: Installer reports error as above, attempt to boot system
gets nowhere (I just get a blank screen, following the BIOS text).
Expected Results: Successful installation and boot. :)
Created attachment 33921 [details]
Traceback displayed in error box
A co-worker looking into this a day later discovered that if he used DiskDruid
to partition the disk, rather than fdisk (which he and I had both used
initially), the problem goes away, despite using the same partitioning scheme.
Perhaps fdisk is the real culprit here?
I'm doubtful that fdisk is at fault here. When the crash occurs, can you press
<Ctrl><Alt><F3> and <Ctrl><Alt><F4> and see if there are any error messages there?
Well, we're past that hurdle now, since it seemed to like the partitioning
after Disk Druid blessed it. I'd have to start over to re-create the crash,
and I have things I need to get done on that system, now that we have RH 7.1
installed and running. I suppose I could experiment with it after that, if you
think it would be useful.
Well, it depends on if you have the time to test it again. I've done some
investigation here, and some things here appear rather strange. It appears that
fdisk has nothing to do with the problem...it has something to do with the
detection of the hard disk.
The values that the installer was getting for disk size and cylinder size were
so big that they caused and OverflowError in the Python interpreter (the
installer is written in python).
Looking at the traceback, it looks like the value for "size" was 1869506934 and
the value for "sector" was 1701079917. I'm not sure which one of these (or
possibly both) are incorrect since I don't have access to your disk, but if you
try to add those two numbers together in Python, an Overflow Error will occur.
[bfox@bfox RPMS]$ python
Python 1.5.2 (#1, Jul 5 2001, 03:02:19) [GCC 2.96 20000731 (Red Hat Linux 7.1
2 on linux-i386
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> size = 1869506934
>>> sector = 1701079917
>>> sum = size + sector
Traceback (innermost last):
File "<stdin>", line 1, in ?
OverflowError: integer addition
I can't explain why it would work the second time you tried the installer,
however. It seems that the detection worked the second time for some reason.
At any rate, the disk detection and partitioning subsystem of the installer has
been replaced with GNU parted for the next version of Red Hat Linux.
I would be very interested if you could reproduce this with Red Hat Linux 7.2,
which should be available soon. Would you like to retry this with 7.1, or wait
for 7.2, or just chalk up the bug to random weirdness in the disk detection?
Any more info here?
Sorry, no; I haven't had a chance to try to revisit this issue. I think the
idea of chalking it up to random disk weirdness sounds reasonable enough.
Ok, fair enough. Thanks for your report.