Bug 108454 - up2date hangs, rpm error & tracebvack
Summary: up2date hangs, rpm error & tracebvack
Alias: None
Product: Fedora
Classification: Fedora
Component: up2date   
(Show other bugs)
Version: rawhide
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Adrian Likins
QA Contact: Fanny Augustin
: 108205 108498 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2003-10-29 18:26 UTC by Torrey Hoffman
Modified: 2007-11-30 22:10 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-10-30 05:54:27 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Torrey Hoffman 2003-10-29 18:26:16 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031027

Description of problem:
Ran up2date, selected just a few components (since selecting all available
updates seemed to hang up2date when I tried it.

As has been the case throughout the Fedora Core test cycle, the updates were
missing signatures, I selected "Yes" install anyway for all of them.

When it got to the "Installing" part, it hung.  Since I had run it from a
console, I got this traceback:
[root@rivendell thoffman]# up2date
Traceback (most recent call last):
  File "/usr/share/rhn/up2date_client/gui.py", line 2070, in doInstallation
    kernelsToInstall = up2date.installPackages(self.selectedPkgList,
  File "/usr/share/rhn/up2date_client/up2date.py", line 604, in installPackages
    hdr = getRealHeader(pkg)
  File "/usr/share/rhn/up2date_client/up2date.py", line 173, in getRealHeader
    hdr = _ts.hdrFromFdno(fd)
rpm.error: public key not trusted

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

How reproducible:

Steps to Reproduce:
1. Run up2date from console
2. select a few packages
3. Start the update

Actual Results:  Up2date hangs with traceback during install

Expected Results:  No hang.  

(gripe = on) And why the heck is up2date so slow?  Even when it eventually works
I sometimes suspect it's hung, as it pauses for so long before starting
installation.  I'm running this on a dual Pentium-III 800 with half a gig of
RAM, and it's painful, even when I already have all the packages downloaded!

Additional info:

Comment 1 Torrey Hoffman 2003-10-29 19:08:32 UTC
I have narrowed this down to a specific couple of RPMs:


If I try to update those, it hangs with the above traceback every time.

Comment 2 Barry K. Nathan 2003-10-29 20:58:04 UTC
this is possibly a dupe of bug 108191

Comment 3 d_rosky 2003-10-29 21:47:00 UTC
I just ran into this problem.  It appears that up2date is not downloading these
two packages properly (redhat-config-network-1.3.10-1.noarch.rpm and

If I look in /var/spool/up2date, these two packages both have a file size of
5896 and they diff identical.  They appear to be HTML text files, not RPMs.  If
I manually download the rpms from the same Red Hat site, I get the proper files
and rpm installs them without any problem.


Comment 4 Don Himelrick 2003-10-30 02:44:08 UTC
I got this same sort of thing with 


The rpms were good, but up2date kept complaining about not being able to read
the headers.

Any idea how to check .hdr files to see if they are bad?

Comment 5 Don Himelrick 2003-10-30 02:57:35 UTC
I take it back, I couldn NOT install the redhat-config-network (and tui) noarch
rpms.  This is what I get:

# rpm -Uvh --nosignature redhat-config-network-1.3.10-1.noarch.rpm
error: open of <!DOCTYPE failed: No such file or directory
error: open of HTML failed: No such file or directory
error: open of PUBLIC failed: No such file or directory

Comment 6 Torrey Hoffman 2003-10-30 05:54:27 UTC
I'm the original reporter, and as of 9:45 pm tonight it worked for me.  I
believe Red Hat must have rebuilt the faulty RPMs and fixed the problem.

Comment 7 Adrian Likins 2004-01-16 20:21:40 UTC
rpms werent faulty, the server. It was spewing html 404's page
but return a 200 error code. Server should be fixed now.

Comment 8 Adrian Likins 2004-01-16 20:22:11 UTC
*** Bug 108205 has been marked as a duplicate of this bug. ***

Comment 9 Adrian Likins 2004-08-24 20:40:45 UTC
*** Bug 108498 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.