Bug 54787

Summary: Anaconda traceback at package read (both text and GUI modes)
Product: [Retired] Red Hat Linux Reporter: Allen Clarke <allen>
Component: anacondaAssignee: Brent Fox <bfox>
Status: CLOSED WORKSFORME QA Contact: Brock Organ <borgan>
Severity: low Docs Contact:
Priority: medium    
Version: 7.1   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2002-05-01 16:20:12 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Ananconda traceback dump none

Description Allen Clarke 2001-10-18 22:18:22 UTC 
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0b; Windows NT 5.1)

Description of problem:
Trying to upgrade from RH 6.2 to 7.1 I get a trace back from anaconda

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1.attempt to upgrade, repeat a couple of times
2.try again in text mode, repeat (swear)
3.start comparing Redhat to Microsoft :(  (I would never be so unkind)
	

Actual Results:  see attachment

Expected Results:  a happy camper, with a shiny new 7.1 install.

Additional info:

system is AMd K6-2 450, currently with RH6.1 on hda1 (/) (133meg), hda8 
(/usr) (2G), hda9 (/home)(1.1G), hda10 (swap)(256meg).
hda2 is dos c (with win98), hda5 dos f, hda6 dos e, hda7 dosf.
CDROM is on hdb (about time I moved it to the second channel)

Other than being dual boot and having a lot of partitions, it's not 
unusual in any way (and has run 6.1 for a while, with no probs)

As a secondary, my other machine is using an ASUS A7V with the HD on the 
secondary controller (promis ATA 100) with a patched kernal, so that when 
booted it reports itself to be on hda. Trying to upgrade (same 6.1 to 7.1) 
It reports no device on hda. Having a look at bootup when attempting the 
upgrade, the disk is reported as hde. Should I just put it on to the 
onboard (ATA66 max) controller, do (or at least attemp to do...) the 
upgrade and move it back. will I then have the same as I have now with the 
promise controller having hda-hdd and the onboard hde-hdg or will it be 
the otherway round, so that I will need to edit fstab, or modify al the 
dev nodes (yuk!) to change them around.
Comment 1 Allen Clarke 2001-10-18 22:19:19 UTC 
Created attachment 34381 [details]
Ananconda traceback dump
Comment 2 Brent Fox 2001-10-19 21:16:14 UTC 
We have seen this bug before.  It is a dupe of #53550 and #37099, among others.
 Can you try booting back into your 6.2 system, run rpm --rebuilddb, then try
the upgrade again?  Does that help?
Comment 3 Allen Clarke 2001-10-20 11:29:10 UTC 
At the start of the install process I had a message asking to 
change /var/lib/rpm and /tmp to relative sym links, which of course I did.

The rpm --rebuild refused to write the rebuilt db. Until I moved the rpm 
directory into /var/lib (so there was no sym link at all).

This has gotten me a lot further (except now I am about to have a major 
rearrange of my hard disk as I don't have a big enough / and /usr partition and 
I need more inodes on / as well)

Thanks for the info (even if I didn't really need to do the rpm rebuild (maybe, 
maybe not) at least it pointed me to where the problem was)

Any chance of an answer on the second issue, about device IDs on the Asus A7V 
when using the secondary ATA100 based controller ? or would you like it as a 
seperate report ?

Thanks

Allen
Comment 4 Brent Fox 2001-10-23 01:23:47 UTC 
I don't know about the second issue.  It seems more of a kernel issue than an
installer one, so you may want to open a bug against the kernel.