Red Hat Bugzilla – Bug 54787
Anaconda traceback at package read (both text and GUI modes)
Last modified: 2007-04-18 12:37:39 EDT
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):
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.
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.
Created attachment 34381 [details]
Ananconda traceback dump
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?
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 ?
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.