Prob with yum: [Errno -1] Metadata file does not match checksum Trying other mirro
 

I am posting this because one day yum decided to break down on me, and everything else that I tried from Googling the web failed.

One night I was in the middle of a yum install when I pressed control-C to abort. Ever since then, yum became terribly confused and refused to work any longer: ALL of my repositories returned the following error message:

[Errno -1] Metadata file does not match checksum

I tried all the usual suggestions: yum clean all, yum clean metadata, yum update. I tried entirely deleting the yum cache directories. I tried rebooting. Nothing worked.

I went into the one of the yum cache directories and noticed that even when I clear out the entire directory and download the new information - including the repomd.xml file and primary.xml.gz file, the 'repomd.xml' file was actually date stamped from two weeks earlier.

I opened up repomd.xml and looked at the hash value for the primary.xml.gz file. I then computed a hash in primary.xml.gz using sha1sum. They didn't match.

Hence, I figured that my ISP was serving an older cached version of the repomd.xml file which was out of date and therefore the checksums didn't match.

I went onto IRC and someone kindly suggested doing this: Explicitly export a variable in bash which contains the IP address of your http proxy. So, I went into bash and did something like:

export http_proxy=[full http address here]

(I had to edit that because the forum wouldn't allow me to post an example URL - just be sure to indicate the http protocol and include the port number after the IP using a colon).

where that IP address was the IP address of my proxy (which I obtained from doing an 'env check' at cybersyndrome.net.

Which showed my 'REMOTE_ADDR' (the IP of my proxy - as opposed to 'HTTP_FORWARDED_FOR' which is the IP of my computer)

Anyway, I exported that variable, and yum started working again. I guess it must have been a problem with my ISP's cache servers. I'm sure they would have fixed it eventually, but this was a useful fix in the meantime.

I hope this is of some use to someone who is pulling their hair out about yum after trying everything else out there on the web. :)

Good luck.

I have heard that some people are having this problem when using fastestmirror detection.
supposedly it will get fixed if you
yum -y remove yum-fastestmirror

(However I am not sure how that will work if your yum isn't working)

just a thought, maybe something you haven't tried yet

I have had that problem before. Just do yum clean metadata from the command line. That should take care of it. Not sure why it does that.

I too had the problem after breaking out of yum.

I tried all the above but no luck so then grabbed an (older) copy of the rpms from another computer which had the original install mounted and did a yum localinstall <rpm>

This failed due to a dependency error (doh!), but from then on yum seemed to work fine grabbing from the online repositories.

Hope this helps.
Steve

I had the same problem listed here.
I found that for me, a combination of removing fastestmirror and yum clean metadata resolved the problem.
Performing a yum clean all and yum clean metadata did not get results. I had to also remove fastestmirror as well.
I noticed that fastestmirror caches, and I wonder if that affects things if you halt [CTL Z] the yum process.
I have decided not to use it.

Thanks to all of you who posted answers.
This helped me, and it only took ten minutes.

Thx jdwilder
 

I found jdwilders:

worked for me first try...thx

FC5 & MythTV

I had the same problem:
And this command worked:
I would recommend doing the above clean procedure before changing yum's configuration settings.
In other words, try the above command first then secondly try this command:
-J Tom Moon 79

I am suffering the same problem
 

I am suffering the same problem (with CentOS 4):

[root@linux16 tteswz]# yum update
Setting up Update Process
Setting up repositories
update 100% |=========================| 951 B 00:00
base 100% |=========================| 1.1 kB 00:00
addons 100% |=========================| 951 B 00:00
extras 100% |=========================| 1.1 kB 00:00
Reading repository metadata in from local files
primary.xml.gz 19 kB 00:00
http://mirror.centos.org/centos/4/up...rimary.xml.gz: [Errno -1] Metadata file does not match checksum
Trying other mirror.
Error: failure: repodata/primary.xml.gz from update: [Errno 256] No more mirrors to try.

I have tried all of the following:

1. yum clean all and yum clean metadata
2. yum -y remove yum-fastestmirror
3. export http_proxy=[my actual proxy server]

The only suggestion here that I haven't tried is wakes' of getting rpms manually and doing a localinstall but that's because I don't have these to hand and would not know where to start when it comes downloading them individually.

Anyone got any ideas?

Thanks

Stewart

Yum with Proxy
 

If you use the "export http_proxy=[full http address here]" from above post, you MUST include the following in your /etc/yum.conf:
proxy=[ip address:port]
This did not appear as an issue until I upgraded yum to 3.2.8.
This occurred on CentOS 5. The previous yum version did not seem to have issue.

Disabling the fastestmirror yum plugin
 

While this plugin occasionally causes metadata/checksum issues, it is still valuable for speeding up updates.

Instead of "yum -y remove yum-fastestmirror", do the following:
yum makecache --disableplugin=fastestmirror
yum update []

This allows you to continue using the plugin and work around it, instead of just blowing it away.
(CentOS 5.2 is environment, your paths may differ.)

Similar issue with a repository on a local HD & *not* online!
 

G'day all

First - please note I am on dial-up .. which will 'explain' a few things in the following...


I had the same "checksum" problem after rebuilding my local repository with "createrepo -d" .... tho' I was not online at the time!!
(Yes, I have to keep all my downloads! :-))

Having read the various posts and replies, I suspect it was the cached metadata that was really causing the problem, tho' there was nothing for yum(ex) to actually fetch from the net - as it was all on a HD !!


So.. to my question(s) ... :-))

(1) Is there a way to force the rebuild of the cached metadata as (BHG_2008 suggested) - *but* avoiding the (re)fetching of data from the various online repositories? (...I'm on dial-up remember)
ie: just so I can rebuild the cached metadata relevant to my local repo on HD, if this should happen again?

...or (2) does it always (need to) rebuild the cache for *all* repositories regardless of whether it is from a local HD or from an online source?
(..I do hope not ... this would really be a nuisance!)
If it is so...(3) what would happen if I did a "yum makecache" when *not* online? Would it then stuff up the cached metadata completely (for the (unavailable) online repositories)?

NB: I have rebuilt the local HD repo quite a few times previously - without any issues ... It makes you wonder why ditching or disabling the fastest-mirror plugin is (suddenly) relevant .. tho' it does seem to be so.

It does tend to suggest there is a bug lurking in the fastest-mirror plugin somewhere...... (4) Any ideas where?

Many thanks
Barry Day

i was able to relive the problem also,
 

thank for the advice, i was able to relive the probelem and keep fastmirror yum plugin

i ran these commands


then i was all cool
BTW i'm running RHEL 5.2 x86_64

I found that running the "yum -y remove yum-fastestmirror" removed "yum" based on depedancies on my CentOS 5.2 x86_64 server! Doh!

It was easier to run "vi /etc/yum/pluginconf.d/fastestmirror.conf" and set "enable=0"

@bday:

1. if the system seems corrupt, you can try rpm --rebuilddb, as yum is a layer over rpm. This rebuilds the local rpm db based on what you've got installed. Not often reqd unless you ctrl-c or crash during an rpm op.

2. from the man page, it seems pretty clear that yum makecache updates the local cache against all the repos you've got registered. That's its reason for existing... You could temporarily move repo definition files somewhere else for non-local repos and do yum makecache.

I agree with Whistl. The command "yum -y remove yum-fastestmirror" is dangerous and should not be used as it could un-install some of your working applications. I learned it the hard way...

I had the same problem. I am using CentOS 5.2 behind a proxy. The above advice fixed the issue.

Using "yum -y remove yum-fastestmirror" also removed yum with it (dependency!) which wasn't exactly good.

none of those are working
 

So far i tried
yum clean all
but no go.
yum clean metadata
but no go.
yum -y remove fastest-mirror
but no go

I have found that sometimes the upstream mirror has a corrupt metadata file, possibly caused by running buildrepo while files were still being updated or something like that. The only solution then seems to be to wait 4-24 hours and try again.

Another solution, and one I've since done, is to build your own repository. You just need a web server with ~5 GB free space per version+architecture combination you use, an upstream repo to mirror from (I asked and got permission from GA Tech) and a couple of shell scripts (there are links on centos.org you can read more about this). Then you just modify the /etc/yum.repos.d/CentOS-Base.repo file on each of your servers to point to your repo instead of using the default mirror list for the Base, Updates, Extras and Addons repos, and you're in charge of your own fate.

Updates and kickstarts go a LOT faster when you have your own repository. And if your bosses agree (mine didn't), you can give back to the community by making your repo available over the Internet to other users.

Made the bonehead mistake and tried to uninstall yum-fastestmirror and it also removed yum-updatesd, yum-fastestmirror, yum, and pirut.

For anyone else who made this mistake here is the fix.

cat /etc/redhat-release (Will tell you what version your running)

Web to http://vault.centos.org/5.3/os/i386/CentOS/ (change the centos ver #)

Look for yum & yum-fastestmirror and copy and paste the link to wget

==Download rpm files to local hdd==
wget http://vault.centos.org/5.3/os/i386/...tos.noarch.rpm
wget http://vault.centos.org/5.3/os/i386/...tos.noarch.rpm

==Install Yum==
rpm -ivh yum-3.2.19-18.el5.centos.noarch.rpm yum-fastestmirror-1.1.16-13.el5.centos.noarch.rpm

==Disable Fastest Mirror==
/etc/yum/pluginconf.d/fastestmirror.conf
enabled=0 <--Disabled Fastest Mirror

==Test yum==
yum clean all
yum clean metadata
yum update

http caching
 

I know this thread is a bit old, but I just ran across it as I was searching for an answer and wanted to add to the collective knowledge of what worked for me.

It appears that this issue is likely to be caused by http caching on the server (repo) side. The reason that "yum clean all" won't fix the problem immediately is because yum will just download the cached out of date metadata file again. Until the repo http server's cache times out and caches the new metadata file, you'll keep getting the old metadata file and yum will keep complaining.

You can instruct yum not to use http caching, however. To do so globally, just add this option under the [main] section in /etc/yum.conf:

Now run yum clean all and yum check-update and you should be good to go!

I haven't tested it, but I would assume that you could also specify this option at a repo level instead of globally if you prefer.

All credit goes to this excellent article:
http://plone.lucidsolutions.co.nz/li...match-checksum

Thanks Gato Azul. You are a savior.

I tried all the previous options, including
-> vi /etc/yum/pluginconf.d/fastestmirror.conf & set enabled=0
-> yum clean all
-> rpm --rebuilddb
even the one with adverse side effects
-> yum -y remove yum-fastestmirror
The above command removed yum. I used the CD I used to install the OS, and the following commands to get it back
-> cd /media/CDROM/CentOS
-> rpm -Uvh yum-3.2.19*.rpm yum-fastestmirror-*.rpm

Finally, what worked was as you mention in your post.
-> vi /etc/yum.conf (add the line http_caching=none under section [main])
-> yum clean all

I stumbled upon this thread while searching for "yum metadata file does not match checksum" online.
I would like to add some useful recon to this thread:

Root cause of problem:
I had a Scientific Linux 5.3 test server that I backed up to a local tar file, upgraded to 5.7 and then restored the backup to take it back down to 5.3 (testing rollback prior to patching production servers).
After rolling back to 5.3, I then reinitiated an upgrade and ran into this problem. yum returned the "metadata file does not match checksum" error.

Solution:
Following that, I was able to proceed with a full upgrade to 5.7 as normal.

Thank you, LinuxQuestions.org and its community, yet again, for hosting good information and showing up with high relevance in search results.

In my case running 'yum clean all' or 'rm -r /var/cache/yum' did not fix the error. Yum was checking some old data elsewhere:

[solved]
 

I'm writing my result here hoping to be able to help others. I got this same error while creating a Red Hat 5.9 YUM Repository on a Red Hat 6.3 server. The problem appears because 6.3 uses the SHA256 checksum by default when creating the primary.xml.gz file; and 5.9 uses the old SHA1.

Solution (follow the logic):

On the YUM Repository server run:

# cd pub/rhel/5.9/os/x86_64
# createrepo -d -s sha -g repodata/comps-rhel5-server-core.xml .

On the YUM source host run:

# yum clean all
# yum repolist

My "yum update"-based upgrade from CentOS 5.8 to 5.9 was failing due to the issue above. Ramses's answer proved to solve this, as it was a local/custom repository failing its checksums what made the whole process to abort every time. Now I split my createrepo-based script in two according to the CentOS branch (5.x or 6.x) and all seems to work just fine now. Thanks !

I know this is a pretty old thread, but I came to it when I was researching this problem for myself. 'yum clean metadata' and 'yum clean all' did not fix the problem for me. Interestingly, though, simply running 'yum update' got everything back into order. This was with Fedora 19.

I know this is a pretty old thread, but I wanted to share the solution which worked for me.

I got the same error on a CentOS 5.8 box which was registered to a spacewalk server having the latest packages from CentOS 5.11 (and checksum as well). I found this link and is what did the magic for me.

Hope this helps someone.