From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2.1) Gecko/20010901 Description of problem: up2date fails to install several rpms. rpms downloaded to /var/spool/up2date have invalid checksums and gpg signatures. It looks that up2dates fails only on rpms bigger than approx 2MB. I am not sure whether this bug is in up2date itself or kernel or whatever, but it looks up2date is the only program that downloads incorrect files. rsync, ftp, wget all appear to work correctly on large files. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: I am trying to upgrade to a new ghostcript and then it fails with invalid gpg signature. Actual Results: I click <Abort> and looked at the rpm file, indeed it was broken. $ rpm -Kvv ghostscript-6.51-16.i386.rpm results D: Expected size: 7062010 = lead(96)+sigs(149)+pad(3)+data(7061762) D: Actual size: 7062010 ghostscript-6.51-16.i386.rpm: MD5 sum mismatch Expected: affb80920802a93a121b49220759b1db Saw : 8a8aa377bf43d1bd3f4af576e75063c9 gpg: Warning: using insecure memory! gpg: Signature made Wed 31 Oct 2001 10:13:55 PM CET using DSA key ID DB42A60E gpg: BAD signature from "Red Hat, Inc <security>" $ md5sum ghostscript-6.51-16.i386.rpm e4ff3344e3e5abb6e7d6cf736e33cf71 ghostscript-6.51-16.i386.rpm Additional info: I have left a copy of the buggy ghostscript file (the ghostscript is an example, actually any big rpm comes that way, including glibc and kernel). If you have a local copy of ghostscript-6.51-16.i386.rpm then the preferred method is rsync, because the file differs from the original few bytes. You can rsync the file using: rsync alec.camk.edu.pl::bugzilla/ghostscript-6.51-16.i386.rpm or you can wget it from: http://pingwin.icm.edu.pl/~chris/ghostscript-6.51-16.i386.rpm I have been using Redhat 7.1 since June 2001 and everything was ok. The up2date problems started 4 days ago, when I upgraded to RH 7.2. I have upgraded my system simply by inserting the RH7.2 CD and chosing upgrade.
I've seen two reports of this, but so far have been unable to reproduce it locally. I have some suspicions on what is is, but havent found it yet.
This looks like a server/network issue to me, and seems to have been a temporary issue, so I'm closing this bug out. If this is still an issue, please reopen this bug report.