Almost each time I want to use rpmforge with yum I get a "Metadata file does not meet checksum" error. Yum usually has to try at least five mirrors before it succeeds, sometimes it doesn't find a mirror with a useable file. This is with CentOS 5. Is this a known issue with rpmforge lately?
Kai
On 8/26/07, Kai Schaetzl maillists@conactive.com wrote:
Almost each time I want to use rpmforge with yum I get a "Metadata file does not meet checksum" error. Yum usually has to try at least five mirrors before it succeeds, sometimes it doesn't find a mirror with a useable file. This is with CentOS 5. Is this a known issue with rpmforge lately?
I've only seen this on networks where I (or my providers) use proxies, however you may have better luck asking on the rpmforge user's list.
I've only seen this on networks where I (or my providers) use proxies, however you may have better luck asking on the rpmforge user's list.
Mmmmm... I "sufer" this issue frequently. And I establish the connection from several sites (home, work). Maybe I'm behind a proxy network in my hme connection, but in my job it doesn't.
I will notice Dag about this post.
On Mon, 27 Aug 2007, Jordi Espasa Clofent wrote:
I've only seen this on networks where I (or my providers) use proxies, however you may have better luck asking on the rpmforge user's list.
Mmmmm... I "sufer" this issue frequently. And I establish the connection from several sites (home, work). Maybe I'm behind a proxy network in my hme connection, but in my job it doesn't.
I will notice Dag about this post.
I have no idea why that is and we'll probably need more information to make any sense of this report.
I can tell you that it is not widespread as I would have had reports before.
If you do have problems related to network issues, setting up a local mirror is a good way to control the environment _and_ save ond bandwidth.
Dag Wieers wrote on Mon, 27 Aug 2007 23:33:21 +0200 (CEST):
If you do have problems related to network issues, setting up a local mirror is a good way to control the environment _and_ save ond bandwidth.
It's sure not a network issue. Don't experience it at the moment as yum is still using the cached files. Mirroring rpmforge locally is really not what I want as I don't need 99% of the files and have only a few machines here locally. What can I do for getting more information when it happens next time?
Kai
On Tue, 28 Aug 2007, Kai Schaetzl wrote:
Dag Wieers wrote on Mon, 27 Aug 2007 23:33:21 +0200 (CEST):
If you do have problems related to network issues, setting up a local mirror is a good way to control the environment _and_ save ond bandwidth.
It's sure not a network issue. Don't experience it at the moment as yum is still using the cached files. Mirroring rpmforge locally is really not what I want as I don't need 99% of the files and have only a few machines here locally. What can I do for getting more information when it happens next time?
You could start off with specifying what server you are using and whether you have the same problem with other mirrors.
Dag Wieers wrote on Tue, 28 Aug 2007 02:21:49 +0200 (CEST):
You could start off with specifying what server you are using and whether you have the same problem with other mirrors.
As already said the problem exists with an unspecified number of mirrors. I don't use "a" mirror. I installed your rpmforge repo rpm package. That retrieves the list of mirrors and tries one (at random it seems). The checksum fails, it goes off to the next and so on. It seems to do this about ten times and then stops. Or maybe it was out of mirrors. One time none of them succeeded the checksum check, usually it takes 4, 5 or 6 tries before I get a valid checksum. I didn't write them down as it always seemed to be different ones (but I may be wrong on that) and there's apparently no log which lists the failures. I can either follow-up here or in pm if it happens again. So, is there something I can do when it fails again? For instance, could I do a manual checksum check? If so, how? Is this an md5 check of the primary.xml.gz?
Kai
On Tue, 2007-08-28 at 08:31 +0200, Kai Schaetzl wrote:
As already said the problem exists with an unspecified number of mirrors. I don't use "a" mirror. I installed your rpmforge repo rpm package. That retrieves the list of mirrors and tries one (at random it seems). The checksum fails, it goes off to the next and so on. It seems to do this about ten times and then stops. Or maybe it was out of mirrors. One time none of them succeeded the checksum check, usually it takes 4, 5 or 6 tries before I get a valid checksum.
I also frequently see checksum errors with a similar setup, but seldom more than one or two failures. I also use the fastestmirror plugin which may have some effect on the results. No proxy is involved and results are similar at home and at work.
Phil
On Tuesday 28 August 2007, Phil Schaffner wrote:
On Tue, 2007-08-28 at 08:31 +0200, Kai Schaetzl wrote:
As already said the problem exists with an unspecified number of mirrors. I don't use "a" mirror. I installed your rpmforge repo rpm package. That retrieves the list of mirrors and tries one (at random it seems). The checksum fails, it goes off to the next and so on. It seems to do this about ten times and then stops. Or maybe it was out of mirrors. One time none of them succeeded the checksum check, usually it takes 4, 5 or 6 tries before I get a valid checksum.
I also frequently see checksum errors with a similar setup, but seldom more than one or two failures. I also use the fastestmirror plugin which may have some effect on the results. No proxy is involved and results are similar at home and at work.
We see it too. My assumption is that it has to do with slow mirror sync somehow. It seems a bunch of mirrors typically sit on a old or new version that does not work with the local data (previously pulled from another mirror). My typical fix is to ignore it (either it finds a mirror eventually that's compatible or I try again later...).
/Peter
Phil
Peter Kjellstrom napsal(a):
We see it too. My assumption is that it has to do with slow mirror sync somehow. It seems a bunch of mirrors typically sit on a old or new version that does not work with the local data (previously pulled from another mirror). My typical fix is to ignore it (either it finds a mirror eventually that's compatible or I try again later...).
My fix is 'yum clean all', it helps. David
On Tue, 28 Aug 2007, Phil Schaffner wrote:
On Tue, 2007-08-28 at 08:31 +0200, Kai Schaetzl wrote:
As already said the problem exists with an unspecified number of mirrors. I don't use "a" mirror. I installed your rpmforge repo rpm package. That retrieves the list of mirrors and tries one (at random it seems). The checksum fails, it goes off to the next and so on. It seems to do this about ten times and then stops. Or maybe it was out of mirrors. One time none of them succeeded the checksum check, usually it takes 4, 5 or 6 tries before I get a valid checksum.
I also frequently see checksum errors with a similar setup, but seldom more than one or two failures. I also use the fastestmirror plugin which may have some effect on the results. No proxy is involved and results are similar at home and at work.
I wonder if this could be related to the fact that the metadata and data are synchronized independently and not with the rsync --delay-updates options.
On Thu, 2007-08-30 at 15:21 +0200, Dag Wieers wrote:
I wonder if this could be related to the fact that the metadata and data are synchronized independently and not with the rsync --delay-updates options.
Seems like a reasonable hypothesis. How hard would it be to test it by synchronizing the updates and asking for reports? Would need some time to test and cooperation on reporting as it seems not to be a deterministic problem.
Phil
Dag Wieers wrote on Thu, 30 Aug 2007 15:21:38 +0200 (CEST):
I wonder if this could be related to the fact that the metadata and data are synchronized independently and not with the rsync --delay-updates options.
The error refers to the metadata only it seems. What exactly does this check *do* check? If it is some hash check of the primary.xml.gz the status of the repo should not have any effect on it. If it is a consistency check about the sync status between metadata and data, then, yes, I would expect an error if they don't match.
Kai
Jim Perrin wrote on Sun, 26 Aug 2007 21:18:19 -0400:
I've only seen this on networks where I (or my providers) use proxies, however you may have better luck asking on the rpmforge user's list.
I'm not using a proxy. On first glance it looks to me like the repo gets so frequently updated that the meta data is always out of sync. As I don't know how it works that's probably wrong, but it feels like that :-) I didn't ever (or almost never) notice that with CentOS 4, but I see it frequently happen with both my new CentOS 5 installations. rpmforge has become almost unusable because of this. I thought I'd ask here first, as I'm not subscribed to the rpmforge list and I know that many here are using it. I'll take it over to rpmforge after a bit of waiting here for other replies.
Kai
-
Dag Wieers -
David Hrbáč -
Jim Perrin -
Jordi Espasa Clofent -
Kai Schaetzl -
Peter Kjellstrom -
Phil Schaffner