Bug 108454 - up2date hangs, rpm error & tracebvack
up2date hangs, rpm error & tracebvack
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: up2date (Show other bugs)
rawhide
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Adrian Likins
Fanny Augustin
:
: 108205 108498 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-10-29 13:26 EST by Torrey Hoffman
Modified: 2007-11-30 17:10 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-10-30 00:54:27 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Torrey Hoffman 2003-10-29 13:26:16 EST
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,
self.rpmCallback)
  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):
up2date-4.1.12-1

How reproducible:
Sometimes

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 14:08:32 EST
I have narrowed this down to a specific couple of RPMs:

redhat-config-network-1.3.10-1.noarch.rpm
redhat-config-network-tui-1.3.10-1.noarch.rpm

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

Comment 2 Barry K. Nathan 2003-10-29 15:58:04 EST
this is possibly a dupe of bug 108191
Comment 3 d_rosky 2003-10-29 16:47:00 EST
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
redhat-config-network-tui-1.3.10-1.noarch.rpm).

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.

-Dave

Comment 4 Don Himelrick 2003-10-29 21:44:08 EST
I got this same sort of thing with 

redhat-config-network-1.3.10-1.noarch.rpm
redhat-config-network-tui-1.3.10-1.noarch.rpm
libtool-1.5-8.i386.rpm
libtool-libs-1.5-8.i386.rpm
kdebase-devel-3.1.4-6
kdebase-3.1.4-6


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-29 21:57:35 EST
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 00:54:27 EST
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 15:21:40 EST
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 15:22:11 EST
*** Bug 108205 has been marked as a duplicate of this bug. ***
Comment 9 Adrian Likins 2004-08-24 16:40:45 EDT
*** 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.