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:
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.
this is possibly a dupe of bug 108191
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
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?
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
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.
rpms werent faulty, the server. It was spewing html 404's page but return a 200 error code. Server should be fixed now.
*** Bug 108205 has been marked as a duplicate of this bug. ***
*** Bug 108498 has been marked as a duplicate of this bug. ***