Hi list,
Trying to upgrade someone's workstation here to 5.2 (was installed from a 5.0 DVD I think).
The RPMs on our internal mirror are in-tact and pass a 'rpm -- checksig' test, yet when I run a 'yum upgrade' a large portion of them are corrupted and fail the GPG check.
This seems to be isolated to yum, as downloading the RPM directly via FTP with wget or lftpget provides an RPM that *does* pass the GPG check.
I have upgraded key packages to the latest version (eg. yum upgrade 'yum*') and tried again to no avail.
Anyone seen this before?
Thanks, Tom
-- Tom Lanyon Systems Administrator NetSpot Pty Ltd
On Sun, Aug 24, 2008 at 7:24 PM, Tom Lanyon tom@netspot.com.au wrote:
Hi list,
Trying to upgrade someone's workstation here to 5.2 (was installed from a 5.0 DVD I think).
The RPMs on our internal mirror are in-tact and pass a 'rpm --checksig' test, yet when I run a 'yum upgrade' a large portion of them are corrupted and fail the GPG check.
This seems to be isolated to yum, as downloading the RPM directly via FTP with wget or lftpget provides an RPM that *does* pass the GPG check.
I have upgraded key packages to the latest version (eg. yum upgrade 'yum*') and tried again to no avail.
Anyone seen this before?
The only time I have seen it is where there is a bad HTTP proxy in between you and the server. It caches a bad rpm and then keeps it til hell freezes over.
On Mon, Aug 25, 2008 at 10:54:05AM +0930, Tom Lanyon wrote:
Hi list,
Trying to upgrade someone's workstation here to 5.2 (was installed from a 5.0 DVD I think).
The RPMs on our internal mirror are in-tact and pass a 'rpm --checksig' test, yet when I run a 'yum upgrade' a large portion of them are corrupted and fail the GPG check.
This seems to be isolated to yum, as downloading the RPM directly via FTP with wget or lftpget provides an RPM that *does* pass the GPG check.
I have upgraded key packages to the latest version (eg. yum upgrade 'yum*') and tried again to no avail.
Anyone seen this before?
How are you sync'ing the RPM's on your internal mirror? Do you run createrepo locally to generate the metadata yourself or just rely on the mirror's information?
Ray
On 25/08/2008, at 11:37 AM, Ray Van Dolson wrote:
How are you sync'ing the RPM's on your internal mirror? Do you run createrepo locally to generate the metadata yourself or just rely on the mirror's information?
We just sync 1:1 and rely on the mirror's metadata. As far as I know, there should be no issue with this... or am I missing something?
Tom
On Mon, Aug 25, 2008 at 11:42:14AM +0930, Tom Lanyon wrote:
On 25/08/2008, at 11:37 AM, Ray Van Dolson wrote:
How are you sync'ing the RPM's on your internal mirror? Do you run createrepo locally to generate the metadata yourself or just rely on the mirror's information?
We just sync 1:1 and rely on the mirror's metadata. As far as I know, there should be no issue with this... or am I missing something?
I think that should be fine. I only ask because I recently ran into a similar issue which ended up being the fault of the older version of createrepo we were running.
But if you're not running it, this won't help you. :)
Ray
On 25/08/2008, at 10:54 AM, Tom Lanyon wrote:
Hi list,
Trying to upgrade someone's workstation here to 5.2 (was installed from a 5.0 DVD I think).
The RPMs on our internal mirror are in-tact and pass a 'rpm -- checksig' test, yet when I run a 'yum upgrade' a large portion of them are corrupted and fail the GPG check.
This seems to be isolated to yum, as downloading the RPM directly via FTP with wget or lftpget provides an RPM that *does* pass the GPG check.
I have upgraded key packages to the latest version (eg. yum upgrade 'yum*') and tried again to no avail.
Anyone seen this before?
Thanks, Tom
There's no proxy server in between these machines; nothing seems to corrupt the download when downloading manually via FTP.
Also, yum seems to use the python URLGrabber module to download its RPMs. I just wrote a quick python test script to download some problematic RPMs using the URLGrabber module and they also passed the RPM GPG check!
Yum is doing something crazy internally with the RPMs its downloading into memory, I think.
On Mon, Aug 25, 2008 at 12:10:25PM +0930, Tom Lanyon wrote:
On 25/08/2008, at 10:54 AM, Tom Lanyon wrote:
Hi list,
Trying to upgrade someone's workstation here to 5.2 (was installed from a 5.0 DVD I think).
The RPMs on our internal mirror are in-tact and pass a 'rpm --checksig' test, yet when I run a 'yum upgrade' a large portion of them are corrupted and fail the GPG check.
This seems to be isolated to yum, as downloading the RPM directly via FTP with wget or lftpget provides an RPM that *does* pass the GPG check.
I have upgraded key packages to the latest version (eg. yum upgrade 'yum*') and tried again to no avail.
Anyone seen this before?
Thanks, Tom
There's no proxy server in between these machines; nothing seems to corrupt the download when downloading manually via FTP.
Also, yum seems to use the python URLGrabber module to download its RPMs. I just wrote a quick python test script to download some problematic RPMs using the URLGrabber module and they also passed the RPM GPG check!
Yum is doing something crazy internally with the RPMs its downloading into memory, I think.
What's the exact error you get from yum? One thing you can do is to check the output of sha1sum against the RPM in the Yum cache on the client machine and compare that against the checksum value stored in the primary.xml.gz file for one of the bad packages.
Ray
On 25/08/2008, at 12:17 PM, Ray Van Dolson wrote:
What's the exact error you get from yum? One thing you can do is to check the output of sha1sum against the RPM in the Yum cache on the client machine and compare that against the checksum value stored in the primary.xml.gz file for one of the bad packages.
Ray
Ray,
Thanks, I was just checking the SHA sums using sha1sum and yum's misc.checksum() and I couldn't get either to match what's in the primary.xml.gz metadata.
Further investigation seems to indicate the upstream mirror we're syncing from is corrupt. Whoops, who looks silly now. :)
Thanks all, Tom
On Aug 24, 2008, at 9:25 PM, "Tom Lanyon" tom@netspot.com.au wrote:
Hi list,
Trying to upgrade someone's workstation here to 5.2 (was installed from a 5.0 DVD I think).
The RPMs on our internal mirror are in-tact and pass a 'rpm -- checksig' test, yet when I run a 'yum upgrade' a large portion of them are corrupted and fail the GPG check.
This seems to be isolated to yum, as downloading the RPM directly via FTP with wget or lftpget provides an RPM that *does* pass the GPG check.
I have upgraded key packages to the latest version (eg. yum upgrade 'yum*') and tried again to no avail.
Anyone seen this before?
Make sure the mime type for .rpm files is text/plain and not x- application/octet-stream.
-Ross
______________________________________________________________________ This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender and permanently delete the original and any copy or printout thereof.
On Sun, Aug 24, 2008 at 6:24 PM, Tom Lanyon tom@netspot.com.au wrote:
Hi list,
Trying to upgrade someone's workstation here to 5.2 (was installed from a 5.0 DVD I think).
The RPMs on our internal mirror are in-tact and pass a 'rpm --checksig' test, yet when I run a 'yum upgrade' a large portion of them are corrupted and fail the GPG check.
Since yum has a local cache you may need to invoke one of the "clean" flags for yum. * clean [ packages | headers | metadata | dbcache | all ]
If you do a clean all we will not know which of the set is bogus... My bet is the dbcache.... with metadata to show.
Given what we now know, it might be good to copy the cache of packages and do a local compare of any that are freshly downloaded.
Since yum depends on RPM you should be able to download individual packages and then inspect each with RPM tools as you are doing...
-
NiftyClusters Mitch -
Ray Van Dolson -
Ross S. W. Walker -
Stephen John Smoogen -
Tom Lanyon