Bug 103434

*** Bug 103456 has been marked as a duplicate of this bug. ***

can you try this with up2date-3.9.21 from
http://people.redhat.com/alikins/up2date/severn/RPMS/

I belive this is fixed now (it seems to be
a variation of #103405).

I think I'm seeing the same traceback, with anaconda-product, even with up2date
3.9.22. FWIW I've reconfigured up2date to download source RPMs as well. I can
reproduce this 100% of the time, even if I 'rm /var/spool/up2date/*'. This
traceback happens *only* on anaconda-product, and this is an i386 Everything
install of WS beta 2. I haven't tried testing with AS beta 2 yet.

[root@localhost root]# up2date anaconda-product
                                                                                
Fetching package list for channel: rhel3-beta1-ws-i386...
########################################
                                                                                
Fetching Obsoletes list for channel: rhel3-beta1-ws-i386...
                                                                                
Fetching rpm headers...
########################################
                                                                                
Testing package set / solving RPM inter-dependencies...
########################################
anaconda-product-2.9.5-3WS. ########################## Done.
Traceback (most recent call last):
  File "/usr/sbin/up2date", line 1150, in ?
    sys.exit(main() or 0)
  File "/usr/sbin/up2date", line 748, in main
    fullUpdate, dryRun=options.dry_run))
  File "/usr/sbin/up2date", line 1015, in batchRun
    batch.run()
  File "/usr/share/rhn/up2date_client/up2dateBatch.py", line 73, in run
    self.__getPackages()
  File "/usr/share/rhn/up2date_client/up2dateBatch.py", line 139, in __getPackages
    up2date.getPackage(pkg, wrapperUtils.printPkg, wrapperUtils.printRetrieveHash)
  File "/usr/share/rhn/up2date_client/up2date.py", line 327, in getPackage
    progressCallback)
  File "/usr/share/rhn/up2date_client/rpcServer.py", line 160, in doCall
    pkgName = "%s-%s-%s.%s" % (pkg[0], pkg[1], pkg[2], pkg[4])
  File "/usr/share/rhn/up2date_client/rhnChannel.py", line 50, in __getitem__
    return self.dict[item]
KeyError: 0

(By "happens only on anaconda-product" I mean no other package in the channel
appears to cause this traceback)

I'm still getting my traceback with up2date 3.9.23-1 (the previous version I
tried was 3.9.22-2, just to clarify).

Hmm, not having much luck reproducing this myself.

Seemed to work for me on an x86 and an iSeries box
subscribed to current taroon channels without any
problems.

I'll have a 3.9.24 up soon to test. (thats the
code I'm testing with)

If I do it (try to update anaconda-product) graphically, I get a shorter traceback:

Traceback (most recent call last):
  File "/usr/share/rhn/up2date_client/gui.py", line 1861, in doRetrieval
    self.setRetrievalProgress)
  File "/usr/share/rhn/up2date_client/up2date.py", line 327, in getPackage
    progressCallback)
  File "/usr/share/rhn/up2date_client/rpcServer.py", line 160, in doCall
    pkgName = "%s-%s-%s.%s" % (pkg[0], pkg[1], pkg[2], pkg[4])
  File "/usr/share/rhn/up2date_client/rhnChannel.py", line 50, in __getitem__
    return self.dict[item]
KeyError: 0

This is with 3.9.24-1. 100% reproducible for me.

I did some more testing and it turns out that for my case at least,
"retrieveSource" ***MUST*** be set to 1, not 0, for the bug to happen. This is
an i386 (more specifically, i686) box.

If you still cannot reproduce the bug, let me know.

retrieveSource being in /etc/sysconfig/rhn/up2date (ugh, forgot to mention that
in my last post, sorry)

Created attachment 94223 [details]
/var/log/up2date from one failed attempt (from command line)

up2date --get-source anaconda-product
appears to be the fastest way to get this traceback to happen.

The log I've attached is what was saved after running:
up2date -vvvvvvvvv --get-source anaconda-product
(probably overkill on the v's, but whatever)
with debug set to 1 in /etc/sysconfig/rhn/up2date

It's a fresh log file (I deleted /var/log/up2date right before running
up2date), so there's no data from other up2date runs mixed into that file.

I hope this additional info sheds some more light on whatever's going on...

I've sort of reproduced this now, but still kind of scratching my head.
As you mention, only the anaconda-product package seems to cause this.

Looks like it's somehow more prone to having the headed get corrupted,
but I'm not sure why at the moment. still investigating...

this might be just the package missing on the server, 
as per #103771

when 3.9.28 lands (today hopefully, try it out with
that and see if still breaks it)

It will be 1-3 more days before I can test 3.9.28, due to both the latest SSH
hole (need to patch all of my production systems) and to a family emergency.

Ok, I've test 3.9.28. Here's what happens now:

[root@localhost root]# up2date --get-source anaconda-product
 
Fetching all package list for channel: rhel3-beta1-ws-i386...
########################################
 
Fetching package list for channel: rhel3-beta1-ws-i386...
########################################
File Not Found:
File Not Found: anaconda-product-2.9.5-3WS.src.rpm
 
Error Message:
    Invalid RPM package anaconda-product-2.9.5-3WS.src.rpm requested
Error Class Code: 17
Error Class Info: File not found.
Explanation:
     An error has occurred while processing your request. If this problem
     persists please enter a bug report at bugzilla.redhat.com.
     If you choose to submit the bug report, please be sure to include
     details of what you were trying to do when this error occurred and
     details on how to reproduce this problem.


This is FAR better than previous up2date 3.9.xx releases. I'm guessing there's
no longer a bug in up2date itself?

AFAICT (from a user's point of view) this bug no longer exists in RHEL
3. Unless I'm missing something, this bug should be closed.