[解]处理auxpropfunc error no mechanism available错误
[原]putty使用密钥登陆OpenSSH
Nov
16
[原]解决Metadata file does not match checksum错误 
最近发现，在使用yum更新包的时候，常报下面的错误：
有时候当替换了几个镜像后就可以了。但经常也会发现最终是失败的。由于我的系统是依赖yum更新的，若使用国外网络源的时候出这样的问题，影响挺大的。
Google搜索了一下，是一个常见问题，也提供了一些方法。只是后来发现，这些方法要不就是没有说清楚，要不就是误解。经过测试，最终基本可以解决了。
一、原因
从该地址找到一段说明：点击
大概的意思是说：
参考该文章的内容，我们可以看看yum更新下载的数据： /var/cache/yum，根据你定义的repo.d文件内容，会分开多层目录，每层代表一个更新路径。
找到原因，解决就不难了。
二、解决
1、清空缓存
执行：
先把就的缓存数据都去掉。
2、下载metadata和校验数据
先进入yum对应的目录，再下载：
3、校验数据
执行：
对比repomd.xml中的信息：
若数据正确，则说明metadata和校验数据是匹配的。可以使用yum更新了，不会再重新下载metadata。
否则，可以再等待一下，或需要从其他的镜像获取更新咯。
三、建议
因为我们不能控制镜像更新的速度和时间，而我们的工作只是避免了yum可能发生误判的情况，但并不能完全保证上面的工作是成功的。
从尽可能避免该问题的角度出发，有几个建议：
1、选择好的镜像
设置yum.repos.d中baseurl或mirrorlist从好的镜像下载。若知道某个镜像速度快，则干脆用baseurl固定，而不要使用mirrorlist了。
2、排查网络问题
网上提供的方法大部分是转载这里的。其建议使用--cache=off参数（表示不使用服务器中的高速缓存中的数据）。
但实际上，我发现除非网络有问题，否则是否使用该参数拿回来的数据不应该有有区别的。
如：
※primary.xml.gz是使用--cache=off参数的，而primary.xml.gz.1是没有使用该参数的。
所以，如果网络出现问题，是会影响到yum下载数据的完整性的。而使用--cache=off既然没坏，不妨使用咯。
四、参考资料
http://lists.freshrpms.net/pipermail/freshrpms-list/2005-May/013037.html
http://lists.freshrpms.net/pipermail/freshrpms-list/2004-November/011553.html
http://www.fedorachina.cn/index.php?topic=26.0
http://www.linuxsir.org/bbs/printthread.php?t=316600
http://sillyboy422.spaces.live.com/blog/cns!aab0c086212d33cc!195.entry
引用
Reading repository metadata in from local files
primary.xml.gz 100% |=========================| 1.7 MB 02:25
http://www.mirrorservice.org/sites/apt.sw.be/redhat/el4/en/i386/dag/repodata/primary.xml.gz:
[Errno -1] Metadata file does not match checksum
Trying other mirror.
primary.xml.gz 100% |=========================| 1.7 MB 02:25
http://www.mirrorservice.org/sites/apt.sw.be/redhat/el4/en/i386/dag/repodata/primary.xml.gz:
[Errno -1] Metadata file does not match checksum
Trying other mirror.
有时候当替换了几个镜像后就可以了。但经常也会发现最终是失败的。由于我的系统是依赖yum更新的，若使用国外网络源的时候出这样的问题，影响挺大的。
Google搜索了一下，是一个常见问题，也提供了一些方法。只是后来发现，这些方法要不就是没有说清楚，要不就是误解。经过测试，最终基本可以解决了。
一、原因
从该地址找到一段说明：点击
引用
To reduce load, download.fedora.redhat.com (official host) contains the ~1kB checksum for the metadata. The metadata (usually ~1 - 2 MB) is downloaded off mirrors. After downloading metadata, Yum compares the two to make sure they're one and the same.
Now, think of this: download.fedora.redhat.com updates their metadata and checksums, so you're getting the new checksum. The mirror's cronjobs havn't gone yet, therefore no synching and the metadata isn't the newest, it doesn't match.
The solution is not to makecache; Although it may help it will take forever and still not 100% solve the problem. The main problem is not giving the mirrors enough synch time. Typically, cron runs every hour, and give it a bit of time to download the changes, so I'd say try running maybe 10 minutes after an hour and you'll have no problem (eg 3:10, 4:10, 5:10, etc...). If you get closer to :50 (3:50, :50, etc) you'll start seeing more syncing issues.
Again, this too isn't 100% perfect but more of a guideline. There's a lot of guesswork...
Now, think of this: download.fedora.redhat.com updates their metadata and checksums, so you're getting the new checksum. The mirror's cronjobs havn't gone yet, therefore no synching and the metadata isn't the newest, it doesn't match.
The solution is not to makecache; Although it may help it will take forever and still not 100% solve the problem. The main problem is not giving the mirrors enough synch time. Typically, cron runs every hour, and give it a bit of time to download the changes, so I'd say try running maybe 10 minutes after an hour and you'll have no problem (eg 3:10, 4:10, 5:10, etc...). If you get closer to :50 (3:50, :50, etc) you'll start seeing more syncing issues.
Again, this too isn't 100% perfect but more of a guideline. There's a lot of guesswork...
大概的意思是说：
引用
当生成metadata数据的时候，会一同产生校验数据。而传输的时候，会用该校验数据判断metadata是否完整。这时候就会产生一个问题，mirror镜像当从源网络拷贝数据回来时，下载了metadata，但还没下载校验数据（或由定时任务产生校验数据，但这时定时任务还没有执行）。这时，如果刚好你正使用yum从该镜像更新，就会发生Metadata file does not match checksum的问题了。
文中提供的解决方法是，根据大部分的镜像都是每小时进行一次数据同步或生成校验数据的，所以，不要选择接近整点的时候更新数据，而应选择整点过后再更新。但这只是建议，不能保证一定能解决该问题。
文中提供的解决方法是，根据大部分的镜像都是每小时进行一次数据同步或生成校验数据的，所以，不要选择接近整点的时候更新数据，而应选择整点过后再更新。但这只是建议，不能保证一定能解决该问题。
参考该文章的内容，我们可以看看yum更新下载的数据： /var/cache/yum，根据你定义的repo.d文件内容，会分开多层目录，每层代表一个更新路径。
引用
例如：/var/cache/yum/rpmforge
其中，primary.xml.gz、filelists.xml.gz、和other.xml.gz就是metadata信息，而repomd.xml就是校验数据。其使用的是sha1进行校验的。
其中，primary.xml.gz、filelists.xml.gz、和other.xml.gz就是metadata信息，而repomd.xml就是校验数据。其使用的是sha1进行校验的。
找到原因，解决就不难了。
二、解决
1、清空缓存
执行：
# yum clean all
先把就的缓存数据都去掉。
2、下载metadata和校验数据
先进入yum对应的目录，再下载：
# cd /var/cache/yum/rpmforge
# wget --cache=off http://apt.sw.be/redhat/el4/en/i386/dag/repodata/repomd.xml
# wget --cache=off http://apt.sw.be/redhat/el4/en/i386/dag/repodata/primary.xml.gz
# wget --cache=off http://apt.sw.be/redhat/el4/en/i386/dag/repodata/filelists.xml.gz
# wget --cache=off http://apt.sw.be/redhat/el4/en/i386/dag/repodata/other.xml.gz
# wget --cache=off http://apt.sw.be/redhat/el4/en/i386/dag/repodata/repomd.xml
# wget --cache=off http://apt.sw.be/redhat/el4/en/i386/dag/repodata/primary.xml.gz
# wget --cache=off http://apt.sw.be/redhat/el4/en/i386/dag/repodata/filelists.xml.gz
# wget --cache=off http://apt.sw.be/redhat/el4/en/i386/dag/repodata/other.xml.gz
3、校验数据
执行：
引用
# sha1sum other.xml.gz filelists.xml.gz primary.xml.gz
74fcc9f9e218cfdbc1ac2b5ac17ff7d912267bdf other.xml.gz
3f4b2e9a5efc67c0cdf329c69f041daa82a2346c filelists.xml.gz
bd2033e1fd7a7d1f1b92ce7b880919bd685217f8 primary.xml.gz
74fcc9f9e218cfdbc1ac2b5ac17ff7d912267bdf other.xml.gz
3f4b2e9a5efc67c0cdf329c69f041daa82a2346c filelists.xml.gz
bd2033e1fd7a7d1f1b92ce7b880919bd685217f8 primary.xml.gz
对比repomd.xml中的信息：
引用
# cat repomd.xml |grep -w 'checksum'|grep -v 'open-checksum'
<checksum type="sha">74fcc9f9e218cfdbc1ac2b5ac17ff7d912267bdf</checksum>
<checksum type="sha">3f4b2e9a5efc67c0cdf329c69f041daa82a2346c</checksum>
<checksum type="sha">bd2033e1fd7a7d1f1b92ce7b880919bd685217f8</checksum>
<checksum type="sha">74fcc9f9e218cfdbc1ac2b5ac17ff7d912267bdf</checksum>
<checksum type="sha">3f4b2e9a5efc67c0cdf329c69f041daa82a2346c</checksum>
<checksum type="sha">bd2033e1fd7a7d1f1b92ce7b880919bd685217f8</checksum>
若数据正确，则说明metadata和校验数据是匹配的。可以使用yum更新了，不会再重新下载metadata。
否则，可以再等待一下，或需要从其他的镜像获取更新咯。
三、建议
因为我们不能控制镜像更新的速度和时间，而我们的工作只是避免了yum可能发生误判的情况，但并不能完全保证上面的工作是成功的。
从尽可能避免该问题的角度出发，有几个建议：
1、选择好的镜像
设置yum.repos.d中baseurl或mirrorlist从好的镜像下载。若知道某个镜像速度快，则干脆用baseurl固定，而不要使用mirrorlist了。
2、排查网络问题
网上提供的方法大部分是转载这里的。其建议使用--cache=off参数（表示不使用服务器中的高速缓存中的数据）。
但实际上，我发现除非网络有问题，否则是否使用该参数拿回来的数据不应该有有区别的。
如：
引用
# sha1sum primary.xml.gz*
bd2033e1fd7a7d1f1b92ce7b880919bd685217f8 primary.xml.gz
bd2033e1fd7a7d1f1b92ce7b880919bd685217f8 primary.xml.gz.1
bd2033e1fd7a7d1f1b92ce7b880919bd685217f8 primary.xml.gz
bd2033e1fd7a7d1f1b92ce7b880919bd685217f8 primary.xml.gz.1
※primary.xml.gz是使用--cache=off参数的，而primary.xml.gz.1是没有使用该参数的。
所以，如果网络出现问题，是会影响到yum下载数据的完整性的。而使用--cache=off既然没坏，不妨使用咯。
四、参考资料
http://lists.freshrpms.net/pipermail/freshrpms-list/2005-May/013037.html
http://lists.freshrpms.net/pipermail/freshrpms-list/2004-November/011553.html
http://www.fedorachina.cn/index.php?topic=26.0
http://www.linuxsir.org/bbs/printthread.php?t=316600
http://sillyboy422.spaces.live.com/blog/cns!aab0c086212d33cc!195.entry
eagle 
2009/11/16 19:14
非常感谢你的博客，写的很有用，很中肯，比那些胡乱转载的好多了。
遊客
2009/10/29 09:11
文章寫得很有條理，段落分明，非常用心。
bang
2009/02/08 11:25
很强
adison
2008/06/25 04:11
谢谢，你很棒！
分页： 1/1 
1 
1
