Red Hat Bugzilla – Bug 45168
Get fatal errors when upgrading from 6.1 to 7.1
Last modified: 2007-04-18 12:33:46 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.61 [en] (Win98; U)
Description of problem:
install with lowres switch, gets past the query of the kind of install I'd like, then crashes
Steps to Reproduce:
1.start 'er up with "lowres" at boot prompt
2.go through the motions
3.watch the fireworks
Actual Results: Error dialog box with option to save to floppy.
Expected Results: smooth install
THIS IS THE ERROR MESSAGE I WAS ABLE TO CAPTURE ON FLOPPY:
Traceback (innermost last):
File "/usr/bin/anaconda", line 520, in ?
intf.run(todo, test = test)
File "/var/tmp/anaconda-7.1//usr/lib/anaconda/gui.py", line 391, in run
File "/var/tmp/anaconda-7.1//usr/lib/anaconda/gui.py", line 879, in run
File "/usr/lib/python1.5/site-packages/gtk.py", line 2554, in mainloop
File "/usr/lib/python1.5/site-packages/gtk.py", line 125, in __call__
ret = apply(self.func, a)
File "/var/tmp/anaconda-7.1//usr/lib/anaconda/gui.py", line 481, in nextClicked
next = self.currentScreen.getNext ()
File "/var/tmp/anaconda-7.1//usr/lib/anaconda/iw/examine_gui.py", line 19, in getNext
File "/var/tmp/anaconda-7.1//usr/lib/anaconda/todo.py", line 1187, in upgradeMountFilesystems
allowDirty = 0)
File "/var/tmp/anaconda-7.1//usr/lib/anaconda/upgrade.py", line 88, in mountRootPartition
fstab.readFstab(instPath + '/etc/fstab', theFstab)
File "/var/tmp/anaconda-7.1//usr/lib/anaconda/fstab.py", line 1196, in readFstab
Local variables in innermost frame:
fstab: <fstab.GuiFstab instance at 8481eb0>
line: /dev/md0 /home ext2 defaults 1 2
lines: ['/dev/hda6 / ext2 defaults 1 1\012', '/dev/hda1 /boot ext2 defaults
1 2\012', '/dev/md0 /home ext2 defaults 1 2\012', '/dev/cdrom /mnt/cdrom iso9660
noauto,owner,ro 0 0\012', '/dev/hda5 swap swap defaults 0 0\012', '/dev/fd0 /mnt/floppy
ext2 noauto,owner 0 0\012', 'none /proc proc defaults 0 0\012', 'none
/dev/pts devpts gid=5,mode=620 0 0\012']
fields: ['/dev/md0', '/home', 'ext2', 'defaults', '1', '2']
f: <open file '/mnt/sysimage/etc/fstab', mode 'r' at 84acad0>
tsS'Arabic (Libyan Arab Jamahiriya)'
tsS'English (South Africa)'
tsS'Korean (Republic of Korea)'
tsS'Spanish (El Salvador)'
tsS'Spanish (Costa Rica)'
[MANY SPACES BETWEEN THESE TWO TEXT BLOCKS -TOM SPARKS]
tsS'English (Hong Kong)'
tsS'Spanish (Puerto Rico)'
tsS'Manx Gaelic (Britain)'
Can you attach your /etc/fstab file?
/dev/hda6 / ext2 defaults 1 1
/dev/hda1 /boot ext2 defaults 1 2
/dev/md0 /home ext2 defaults 1 2
/dev/cdrom /mnt/cdrom iso9660 noauto,owner,ro 0 0
/dev/hda5 swap swap defaults 0 0
/dev/fd0 /mnt/floppy ext2 noauto,owner 0 0
none /proc proc defaults 0 0
none /dev/pts devpts gid=5,mode=620 0 0
The above /etc/fstab file is from my current RH6.1 installation.
I should say, to get my machine to boot to the point where the upgrade failed, I had to disconnect the two drives that make up the /dev/md0.
These drives are two 20GB Quantum Fireball Plus LMs connected to a Highpoint366 ATA/66 controller that RH7.1 seems to have trouble
probing. (SEE BUG 45154)
Tried install again and used the following kernel directive after reattaching the drives to the secondary controller:
and it worked. Not sure why this would make a difference, but it did.
I got these numbers from the Gentus Linux "dmesg" boot log.
Total time of upgrade took about 10 hours. It seemed to hang for extended periods at various times.
Not impressed with RedHat 7.1's stability. At boot time, it will randomly hang upon starting various services like sendmail or apache.
I often have to start these services manually as starting these things at boot time fail. Often have to boot several times to acheive a successful boot.
Gentus Linux was rock stable on this Abit BP6. RedHat Linux 7.1 doesn't seem stable at all. It is frighteningly unpredictable on this machine.
I'm sorry now that I upgraded.
Do you have IDE disks connected to the HPT controller on the BP6?
Could you try booting with either "ide=nodma" or "noapic" on the lilo kernel
My earlier doubts about RedHat 7.1's stability may have been misplaced. RH7.1 DOES seem stable. I noticed that if I booted the machine
cold, (8 or 9 hours since running it last) that it booted normally, even swiftly. But rebooting hot yielded unpredictable results.
I suspected a heat problem. I cleaned the case's inlet air filter, cleaned all fan grills (there are two130mm fans and one 92mm fan just in
the enclosure in addition to the four fans on the processors, and the fan in the power supply.) Cleaned the BX chip's heat sink. Removed the
processors and heat sinks to look for accumulations of dust. Sure enough, there was significant dust on the heat sinks.
Vacuumed them off and ran the machine. Booted fine, rebooted hot, booted fine.
RedHat 7.1 seems every bit as stable as Gentus Linux. I apologize for even thinking there was a stability problem with RH7.1.
As a further precaution, I redirected air-conditioned air from other areas to the host's area.
There are two drives connected to the HPT366: a pair of Quantum Fireball Plus LM's of 20GB size, arranged in a RAID0 array and
mounted at /home.
No need to try the ide=nodma or noapic stuff. All seems well.
I suspect the problems with Anaconda were probably also due to the heat problem.
One question remains: Why would heat suddenly be an issue with RH7.1? Is the 2.4 kernel more sensitive to timing issues than 2.2?
I'll keep looking at this machine over the next few weeks and I'll let you know how things go.
"Is the 2.4 kernel more sensitive to timing issues than 2.2?"
For one, 2.4 using DMA on IDE disks, which means the chipset is getting used
harder (the speed is much higher, so the chipset has to do more work)....
Several other areas have performance-improvements, which therefore mean the
hardware is loaded higher.
It appears I was premature in saying the problem was ONLY heat related. It does have some relationship to heat, but heat is only an
aggravating factor. There seem to be other stability problems.
Booting cold, (Really cold, computer in A/C'd room overnight, chipset, and CPU's cool to the touch.) will hang the system on the geometry query
of the boot process. Repeated booting can get it past this point although not predictably.
Rebooting hot can cause the boot process to hang as above but will also hang on starting sendmail.
Once it is up and running it usually works OK, but I have had to reboot to shake off some flakiness.