Bug 37099 - Anaconda fails during upgrade from 7.0
Summary: Anaconda fails during upgrade from 7.0
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: anaconda (Show other bugs)
(Show other bugs)
Version: 7.1
Hardware: i386 Linux
Target Milestone: ---
Assignee: Brent Fox
QA Contact: Brock Organ
: 49486 53550 54130 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2001-04-22 22:40 UTC by Gene Aulich
Modified: 2007-04-18 16:32 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-05-21 00:11:45 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
This is the complete anaconda dump. (10.19 KB, text/plain)
2001-04-22 22:42 UTC, Gene Aulich
no flags Details

Description Gene Aulich 2001-04-22 22:40:46 UTC
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.

Reproducible: Always
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
    self.icw.run ()
  File "/var/tmp/anaconda-7.1//usr/lib/anaconda/gui.py", line 879, in run
    mainloop ()
  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 ()
  File "/var/tmp/anaconda-7.1//usr/lib/anaconda/iw/upgrade_swap_gui.py",
line 93, in getScreen
    self.todo.upgradeFindPackages ()
  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:
path: /mnt/sysimage/var/lib/anaconda-rebuilddb987951408

Comment 1 Gene Aulich 2001-04-22 22:42:44 UTC
Created attachment 16049 [details]
This is the complete anaconda dump.

Comment 2 Michael Fulbright 2001-04-23 16:13:20 UTC
What are the contents of /var/lib on the system?

Comment 3 Gene Aulich 2001-04-23 17:03:37 UTC
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.

Comment 4 Michael Fulbright 2001-04-24 18:49:23 UTC
Is /var/tmp a symlink?

Comment 5 Gene Aulich 2001-04-24 19:02:02 UTC
No, /var/tmp is not a symlink. ls of /var follows:
total 84
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

Comment 6 Brent Fox 2001-05-09 19:40:52 UTC
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?

Comment 7 abc123 2001-05-09 20:22:58 UTC
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.

Comment 8 Brent Fox 2001-05-09 20:27:30 UTC
Did you verify the md5sums of the ISOs?  The cd could be damaged somehow.

Comment 9 abc123 2001-05-10 15:41:21 UTC
Sorry, I don't know how to 'verify the md5sums of the ISOs'.  Point me to the
HOWTO and I'll do it.

Comment 10 Brent Fox 2001-05-10 20:17:55 UTC
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:
edc2d5e1ab6093e3d486cc38dc12511a  seawolf-i386-SRPMS.iso
596b1575773e88e066326f6741312a6f  seawolf-i386-disc1.iso
f27b912299572a542cd663b712444445  seawolf-i386-disc2.iso
59f3333435378fb1645700731c91bc54  seawolf-i386-powertools.iso

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?

Comment 11 abc123 2001-05-14 19:09:47 UTC
Hmmm...I didn't download an ISO image.  I attempted the install from a CD. 
Sorry.  I guess I'm being much help.

Comment 12 Brent Fox 2001-05-15 01:43:41 UTC
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.

Comment 13 abc123 2001-05-15 18:44:20 UTC
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.

Comment 14 Magnus Svderberg 2001-05-15 19:56:32 UTC
I have the exact same problem on a Compaq Armada 1700 (laptop), except that my
path variable
>Local variables in innermost frame:
>path: /mnt/sysimage/var/lib/anaconda-rebuilddb987951408
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.


Magnus Svderberg

Comment 15 Brent Fox 2001-05-21 00:11:40 UTC
We have a fix for this in cvs. Thanks for your report.

Comment 16 Brent Fox 2001-07-23 19:56:48 UTC
*** Bug 49486 has been marked as a duplicate of this bug. ***

Comment 17 Matt Wilson 2001-09-12 15:51:01 UTC
*** Bug 53550 has been marked as a duplicate of this bug. ***

Comment 18 Brent Fox 2001-09-28 15:58:55 UTC
*** Bug 54130 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.