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): How reproducible: Always 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 ones) 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. :) Additional info:
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. For example: [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.