=============================================================================== Description of problem: Installation terminates abnormally on first HDD write attempt (package installation). =============================================================================== Version-Release number of selected component (if applicable): =============================================================================== How reproducible: Every Time. =============================================================================== Steps to Reproduce: During a clean install (clean drives, no other OS), I used defaults throughout the install with the following exceptions: 1) install everything 2) set up as a server There was nothing abnormal in the partitioning section. Following package selection however, just as write to disk launches, I get the message: "Error informing the kernel about modifications to partition /dev/sda2 - Invalid argument. This means that Linux won't know about any changes you made to /dev/sda2 until you reboot, so you shouldn't mount it or use it in any way nefore restarting." This is followed by related messages, including an identical complaint about sda3. Rebooting and going back through the install process results in the same problem. My system employs a 3ware 7506-8 RAID controller. I have 8 160GB drives in RAID5 (1.1TB), and the array is built. Everything else is rather basic. All hardware appears to be functioning normally. I've tried reducing the partition size on the root, and also using LILO as the boot loader since I read that those can be factors. Still no resolution, so I think it's the software. =============================================================================== Actual results: Installation terminates with error messages. =============================================================================== Expected results: Packages would be written to disk =============================================================================== Additional info: Here is an excerpt the log (anacdump)..... Traceback (most recent call last): File "/usr/lib/anaconda/gui.py", line 936, in handleRenderCallback self.currentWindow.renderCallback() File "/usr/lib/anaconda/iw/progress_gui.py", line 155, in renderCallback self.intf.icw.nextClicked() File "/usr/lib/anaconda/gui.py", line 761, in nextClicked self.dispatch.gotoNext() File "/usr/lib/anaconda/dispatch.py", line 157, in gotoNext self.moveStep() File "/usr/lib/anaconda/dispatch.py", line 225, in moveStep rc = apply(func, self.bindArgs(args)) File "/usr/lib/anaconda/packages.py", line 462, in turnOnFilesystems diskset.savePartitions () File "/usr/lib/anaconda/partedUtils.py", line 595, in savePartitions disk.commit() error: Error: Error adding partition 3: Success Local variables in innermost frame: self: <partedUtils.DiskSet instance at 0x88a6ba4> disk: <PedDisk object at 0x8375208>
Created attachment 94130 [details] anaconda dump immedately following errors/termination
Exception Occured ================= An unhandled exception has occured. This is most likely a bug. yadda yadda yadda... file a detailed bug report against anaconda... ... install exited abnormally sending termination signals...done. . . you may safely reboot your system
Matt could this be a 3ware/parted interaction?
Michael and Matt- I just checked partition status, and found something interesting... Following the crash described above, the partitions are actually recognized as having been created, but not formatted. How this was determined: <Step 1> I ran through an install session all the way to termination as described, but used some very customized (non-default) partition settings. <Step 2> I then came and did another install as a second pass, but selected to partition manually; Disk Druid was then used to inspect the results. The partition configuration was there, and it simply asked if I'd like to format my swap partition as such since it was not formatted. This happens to be my last partition if that's of any significance.
Guys- Please help. I'm at a dead end and will have to switch to SuSE if I don't get resolution. Thanks, Roy
SuSE is no good, so I've decided to stick with RedHat. Any ideas yet why the install is crashing? Is it a parted problem? No response from Michael yet, and it's been a full week. Thanks.
No problems with Red Hat 8.0. The install went flawlessly. This confirms that Red Hat 9.0 is broken. When are you guys going to *at least* comment? I've been at this 2 weeks.
Ug-QfVvE
Hi, I met the same problem while I tried to install it in a PII computer, it has a onboard video card (not work), another S3 vedio card, and got follwing error, alway failed: Traceback (most recent call last): File "/usr/lib/anaconda/gui.py", line 936, in handleRenderCallback self.currentWindow.renderCallback() File "/usr/lib/anaconda/iw/progress_gui.py", line 155, in renderCallback self.intf.icw.nextClicked() File "/usr/lib/anaconda/gui.py", line 761, in nextClicked self.dispatch.gotoNext() File "/usr/lib/anaconda/dispatch.py", line 157, in gotoNext self.moveStep() File "/usr/lib/anaconda/dispatch.py", line 225, in moveStep rc = apply(func, self.bindArgs(args)) File "/usr/lib/anaconda/packages.py", line 583, in doPreInstall method.mergeFullHeaders(id.hdList) File "/usr/lib/anaconda/image.py", line 50, in mergeFullHeaders hdlist.mergeFullHeaders(self.tree + "/RedHat/base/hdlist2") File "/usr/lib/anaconda/comps.py", line 180, in mergeFullHeaders rpm.mergeHeaderListFromFD(self.hdlist, fd, 1000004) error: match tag mismatch Local variables in innermost frame: self: <comps.HeaderListFromFile instance at 0x8a2a174> fd: 37 file: /mnt/source/RedHat/base/hdlist2
I've got a report from someone here with an IBM ServeRAID controller getting the same thing. (Or similar -- text based install, my slightly modified anaconda but I didn't touch this part.) I'll have him post more details.
This is a parted/kernel bug. Parted makes a call to a kernel ioctl that has a bug in it that blocks partitions at 1TB. There is use of a long when it should be an unsigned long. Please see bug 116289 for the fix. I can state that applying the patch and rebuilding the BOOT kernel used for RHL9 installer (and FC1 installer) resolves this issue and allows parted to create partitions larger than 1TB.
I believe redhat 8 uses fdisk. The fdisk program uses a different (non-broken) ioctl, BLKRRPART; parted uses the broken (but more flexible) ioctl, BLKPG:BLKPG_ADD_PARTITION. When parted attempts to make a partition between 1TB and 2TB, the partition gets written to the partition table on disk, so you'll see it upon a reboot, but the ioctl to inform the kernel about the change returns with an error due to bug 116289. Anaconda sees this error and quits.
This is fixed with the current devel tree.