Red Hat Bugzilla – Bug 37099
Anaconda fails during upgrade from 7.0
Last modified: 2007-04-18 12:32:47 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.76 [en] (X11; U; Linux 2.2.17-14 i686)
I am trying to upgrade from RedHat 7.0 to 7.1. During the package search
phase anaconda fails with an Error 2, file not found.
Steps to Reproduce:
1.Boot from CD.
2.Select Upgrade option.
Actual Results: Anaconda fails.
Expected Results: Upgrade should continue.
My machine is 900MHZ Thunderbird, 256MB memory, Iwill KV200R Mobo, 2 Maxtor
30GB, 1 Quantum 30GB. I have installed 7.1 on one of the Maxtors which is a
raid drive. The Quantum is in a removable IDE case and holds the version
7.0 which I want to upgrade. It eventually goes to another machine. The
text from anaconda follows:
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 500, in
self.setScreen (self.currentScreen, self.nextClicked)
File "/var/tmp/anaconda-7.1//usr/lib/anaconda/gui.py", line 610, in
new_screen = screen.getScreen ()
line 93, in getScreen
File "/var/tmp/anaconda-7.1//usr/lib/anaconda/todo.py", line 1240, in
iutil.rmrf (self.instPath + "/var/lib/anaconda-rebuilddb"
File "/var/tmp/anaconda-7.1//usr/lib/anaconda/iutil.py", line 294, in
files = os.listdir (path)
OSError: [Errno 2] No such file or directory
Local variables in innermost frame:
Created attachment 16049 [details]
This is the complete anaconda dump.
What are the contents of /var/lib on the system?
The overall contents are:
cddb games logrotate.status misc mysql nfs rpm slocate xdm xkb
If you need all the underlying files, let me know.
Is /var/tmp a symlink?
No, /var/tmp is not a symlink. ls of /var follows:
drwxr-xr-x 21 root root 4096 Feb 26 18:00 .
drwxr-xr-x 21 root root 4096 Apr 22 15:03 ..
drwxr-xr-x 2 root root 4096 Sep 28 2000 arpwatch
drwxr-xr-x 4 root root 4096 Mar 28 15:59 cache
drwxr-xr-x 2 root root 4096 Sep 28 2000 db
drwxr-xr-x 6 root root 4096 Sep 28 2000 ftp
drwxr-x--- 2 gdm gdm 4096 Oct 4 2000 gdm
drwxr-xr-x 11 root root 4096 Nov 30 18:08 lib
drwxr-xr-x 2 root root 4096 Feb 6 1996 local
drwxrwxr-x 5 root uucp 4096 Apr 24 04:02 lock
drwxr-xr-x 5 root root 4096 Apr 22 04:02 log
lrwxrwxrwx 1 root root 10 Sep 28 2000 mail -> spool/mail
drwxr-xr-x 2 root root 4096 Feb 6 1996 nis
drwxr-xr-x 2 root root 4096 Apr 13 2000 opt
drwxr-xr-x 2 root root 4096 Feb 6 1996 preserve
drwxr-xr-x 4 root root 4096 Apr 23 03:38 run
drwxr-xr-x 11 root root 4096 Sep 28 2000 spool
drwxrwxrwt 2 root root 4096 Apr 5 18:48 tmp
drwxr-xr-x 2 root root 4096 Oct 24 2000 webmin
drwxrwxr-x 15 bin bin 4096 Apr 22 15:03 win4lin
drwxr-xr-x 6 apache apache 4096 Mar 22 20:33 www
drwxr-xr-x 3 root root 4096 Sep 28 2000 yp
I can't really explain why this is happening. I just tried an upgrade on my
test machine from 7.0 to 7.1 and could not reproduce it. Have you had any luck
finding a workaround?
I've experienced this same problem except that the upgrade failed on a different
package (tetex). I also tried a clean install and it still crapped out. My
hardware is a Compaq 500 Mhz Pentium III with 128 Mb RAM. Linux gets about 4 Gb
on the hard drive.
Did you verify the md5sums of the ISOs? The cd could be damaged somehow.
Sorry, I don't know how to 'verify the md5sums of the ISOs'. Point me to the
HOWTO and I'll do it.
On a Linux system, run the md5sum command on the iso image. For example:
'md5sum seawolf-i386-disc1.iso'. This will take a long time, but eventually a
number will be output. If the number matches the md5sum posted on the ftp site
for disc 1, then the download completed successfully. If they don't match, then
something was corrupted.
The md5sums for the seawolf iso images are as follows:
If you don't have a Linux system available and the isos are on a Windows
machine, try downloading MD5sumer, which is a freeware Windows md5sum utility.
It can be found at
Can you post the md5sum of the disc1 ISO that you downloaded?
Hmmm...I didn't download an ISO image. I attempted the install from a CD.
Sorry. I guess I'm being much help.
Ok, I'm reopening the bug. Are these cd's that you burned yourself? If not,
are they from the retail boxed set or somewhere else? The reason I ask is that
we see *tons* of bug reports that are from people who have bad cd's...usually
because something went wrong during the download of the ISO images before they
burned the CDs.
I am using a couple of CDs that were burned by a friend of mine. He made them
from original RedHat CDs. I just learned that he has already submitted a bug
report for the same problem. That bugzilla number is 40351. He apparently had
the same problems as I but he was using the originals.
I have the exact same problem on a Compaq Armada 1700 (laptop), except that my
>Local variables in innermost frame:
ends with a different number, and the floppy I put my anaconda log on just
crashed, believe it or not, so I can't supply that number right now.
Isn't that kind of a suspicious-looking path by the way? I wouldn't expect such
a unique path in an install script.
My CDs were also home-burned, but those CDs updated mine and my boss' computers
earlier today, so I think it is safe to trust the CDs. I'm trying to update from
RH6.1 and the same were true for my office computer.
The only thing I can think of that is not straight-forward on my computer is the
partition table, that looks like this:
Disk /dev/hda: 240 heads, 63 sectors, 1299 cylinders
Units = cylinders of 15120 * 512 bytes
Device Boot Start End Blocks Id System
/dev/hda1 * 1 339 2562808+ b Win95 FAT32
/dev/hda2 340 1299 7257600 5 Extended
/dev/hda5 340 340 7528+ 83 Linux
/dev/hda6 341 462 922288+ 83 Linux
/dev/hda7 463 516 408208+ 82 Linux swap
/dev/hda8 557 1299 5617048+ 83 Linux
wheree /dev/hda8 is the partition to install onto. Whether that has anything to
do with the problems I have no idea, but that was the only thing I could come up
with that I know differ.
Let me know if there is anything else I can provide to help solve the bug.
We have a fix for this in cvs. Thanks for your report.
*** Bug 49486 has been marked as a duplicate of this bug. ***
*** Bug 53550 has been marked as a duplicate of this bug. ***
*** Bug 54130 has been marked as a duplicate of this bug. ***