Bug 138485

Summary: Anaconda upgrade (FC1-> FC3) fails during 'finding packages to upgrade'
Product: [Fedora] Fedora Reporter: Michael Ben-Gershon <mybg>
Component: anacondaAssignee: Paul Nasrat <nobody+pnasrat>
Status: CLOSED RAWHIDE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 3CC: axel.thimm, greggwolf, jackmason, jcarlosdg, j.lang.ac, nobody+pnasrat, picomp314, smettorre, softfailur, sp, wgraham
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-02-24 09:13:43 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
Anaconda dump (gzipped text file)
none
anaconda dump (gzipped)
none
Anaconda dump (gzipped text file) none

Description Michael Ben-Gershon 2004-11-09 15:45:22 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3)
Gecko/20041017

Description of problem:
I am trying to upgrade FC1 to FC3. Anaconda fails during the 'finding
packages to upgrade' stage. I have tried running with updates, using
the severn-t3-updates.img mentioned in bugzilla but that does not help
either.

I get the following displayed:

Traceback (most recent call last):
  File "/usr/src/build/475969-i386/install//usr/lib/anaconda/gui.py",
line 789,
in nextClicked
    self.dispatch.gotoNext()
  File
"/usr/src/build/475969-i386/install//usr/lib/anaconda/dispatch.py", line
171, in gotoNext
    self.moveStep()
  File
"/usr/src/build/475969-i386/install//usr/lib/anaconda/dispatch.py", line
239, in moveStep
    rc = apply(func, self.bindArgs(args))
  File "/tmp/updates/upgrade.py", line 388, in upgradeFindPackages
    instPath)
  File
"/usr/src/build/475969-i386/install//usr/lib/anaconda/findpackageset.py",
line 149, in findpackageset
    val =
rpm.labelCompare(oevr,(epoch,h[rpm.RPMTAG_VERSION],h[rpm.RPMTAG_RELEASE]))
TypeError: argument 1, item 0 must be string or None, not long


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


How reproducible:
Always

Steps to Reproduce:
1. Boot off FC3 CD-ROM
2. Choose upgrade current installation
3. Watch it get an exception!
    

Additional info:

Comment 1 Michael Ben-Gershon 2004-11-09 15:49:26 UTC
Created attachment 106350 [details]
Anaconda dump (gzipped text file)

Comment 2 Michael Ben-Gershon 2004-11-09 16:24:38 UTC
'Need Real Name' - Michael Ben-Gershon


Comment 3 Paul Nasrat 2004-11-09 18:16:31 UTC
Can you test with the updates image:

http://people.redhat.com/pnasrat/updates-138485.img

Make a floppy of the above image using dd and boot passing the updates
option eg:

linux updates



Comment 4 Michael Ben-Gershon 2004-11-09 20:17:15 UTC
Created attachment 106370 [details]
anaconda dump (gzipped)

Failed again at the same point. New dump is attached.

Comment 5 Paul Nasrat 2004-11-09 20:36:56 UTC
It doesn't seem to have picked up the updated file.  Can you check
your update floppy, note the stack still has labelCompare being used
at the same line where I've changed it to use compareEVR and done some
sanity checking.

What method of install are you doing - cd/nfs/nfsiso?

Comment 6 Michael Ben-Gershon 2004-11-09 20:50:09 UTC
Well, I shall try it again, but it did give all the messages about the
update - asked which device to load it from, and the floppy then made
all kinds of noises.

Comment 7 Paul Nasrat 2004-11-09 21:05:58 UTC
Thanks, I can see why it's failing and I'm pretty sure I have the
correct fix.

You can also provide it via nfs iso by putting updates.img parallel to
the iso images.

Comment 8 Michael Ben-Gershon 2004-11-09 21:16:45 UTC
Created attachment 106375 [details]
Anaconda dump (gzipped text file)

Well, I think I loaded the old fix again by mistake last time. Sorry! This time
it also failed, but with a different message. I am attaching the new dump. It
is significantly different.

Comment 9 Paul Nasrat 2004-11-09 21:22:52 UTC
OK that's a thinko on my part:

Can you mount the disk on a running linux system and edit
findpackageset.py

under the line

import string

add

import types

Comment 10 Michael Ben-Gershon 2004-11-10 15:31:33 UTC
It worked! Many thanks.
However, I have not managed to get FC3 running properly on my system,
even though the upgrade installation worked. I wonder if it might be
advisable to go from FC1 to FC2 first, and then to FC3?

Comment 11 Paul Nasrat 2004-11-11 15:40:10 UTC
Commited on HEAD and rhel4-branch

Comment 12 John Degenstein 2004-11-13 18:58:29 UTC
"Thanks, I can see why it's failing and I'm pretty sure I have the
correct fix.

You can also provide it via nfs iso by putting updates.img parallel to
the iso images."

do you think it is possible to add upgrade.img to the directory for a
 hard-drive install as well??




Comment 13 John Degenstein 2004-11-14 03:03:41 UTC
Never mind, i just did it the old fashioned way and installed a floppy
drive and edited the updates-* img, it worked well, thanks alot for that.

Comment 14 Jeremy Katz 2004-11-15 15:35:35 UTC
*** Bug 139313 has been marked as a duplicate of this bug. ***

Comment 15 Jeremy Katz 2004-11-15 16:12:04 UTC
*** Bug 139362 has been marked as a duplicate of this bug. ***

Comment 16 John Gregg 2004-11-15 16:45:55 UTC
I opened 139313, a duplicate of this bug. Going through the comments
in chronological order, I'm finding it hard to figure out exactly what
I should do to fix or work around this bug. I have the 4 FC3 CDs burned.
I create a floppy from
http://people.redhat.com/pnasrat/updates-138485.img?
But didn't Paul say there was a problem with that in comment #7?
And what should I do about comment #9? Does this refer to the
floppy disk? Do I still need to edit findpackageset.py?
Thanks.



Comment 17 Paul Nasrat 2004-11-15 16:52:52 UTC
For your convenience I've uploaded the fixed updates image to
people.redhat.com - please redownload and use linux updates to work
around.

Comment 18 Bill Graham 2004-11-15 19:30:28 UTC
I find a static page with a logo and a typed URL at people.redhat.com 
with nothing else.  I was installing from ISO images I downloadeed 
and burned to CD's when I encountered this issue. please provide a 
more detailed description of how to work around this problem from 
that scenario, even if it is as simple as waiting to download a new 
ISO image.  Thank you.    

Comment 19 Paul Nasrat 2004-11-15 19:37:27 UTC
Insert floppy:

wget http://people.redhat.com/pnasrat/updates-138485.img
dd if=updates-138485.img of=/dev/fd0

Boot installer with:

linux updates

Comment 20 Jeremy Katz 2004-11-15 20:00:15 UTC
*** Bug 138868 has been marked as a duplicate of this bug. ***

Comment 21 Bill Graham 2004-11-15 20:45:41 UTC
Is there a method to do this on a laptop with no floppy drive? 

Comment 22 Paul Nasrat 2004-11-15 21:21:28 UTC
Yes, do an nfs iso install - (export a dir with Just the FC3 isos in
via nfs, create a RedHat/base and put the image as updates.img in the
base dir.  Boot with cd 1 "linux askmethod"

Other options are described in installation-methods doc in anaconda

Comment 23 Robert Gadsdon 2004-11-16 00:23:03 UTC
(follow on from original problem reported under bug #138868) 
I downloaded the updates-138485.img floppy image mentioned in comment
#3 and then modified findpackageset.py on the floppy as in comment #9,
booted the DVD with 'linux updates', and the FC2>FC3 update worked
fine.  Many Thanks.

Comment 24 Bill Graham 2004-11-19 18:12:18 UTC
For an nfs install (per comment #22), where should the RedHat/base
directory be created to place the updates.img file?  If it is under
the directory with the ISOs, it does not pick up the updates.img file
and results in the same error message.

Comment 25 Bill Graham 2004-11-19 18:50:23 UTC
Reference comment #24 - I found documentation and put updates-138485
as updates.img in same exported directory as ISOs. Encountered a new
error message.
The last two lines are:

File"/tmp/updates/findpackageset.py", line 158, in rpmOutToStr
  if type(arg)!=types.StringType:
NameError: global name 'types' is not defined

  

Comment 26 Paul Nasrat 2004-11-20 14:52:18 UTC
Please remove your copies of the updates.img and redownload - this was
fixed as per comment #17 - you may have an older version.  I double
checked and the image is correct.

Comment 27 Bill Graham 2004-11-20 16:44:26 UTC
Deleted copy of updates-138485.img (downloaded 11/19) and
re-downloaded.  It worked.  Thank you for your help.

Comment 28 Jeremy Katz 2004-11-22 16:11:41 UTC
*** Bug 140251 has been marked as a duplicate of this bug. ***

Comment 29 Paul Nasrat 2004-12-18 13:48:53 UTC
*** Bug 143297 has been marked as a duplicate of this bug. ***

Comment 30 Paul Nasrat 2004-12-29 22:16:00 UTC
*** Bug 143844 has been marked as a duplicate of this bug. ***

Comment 31 Paul Nasrat 2005-03-04 09:07:02 UTC
*** Bug 150243 has been marked as a duplicate of this bug. ***

Comment 32 Jeremy Katz 2005-03-14 18:28:15 UTC
*** Bug 150819 has been marked as a duplicate of this bug. ***