Submitted by admin on Tue, 11/18/2008 - 22:02
有時候當替換了幾個鏡像後就可以了。但經常也會發現最終是失敗的。由於我的系統是依賴yum更新的，若使用國外網絡源的時候出這樣的問題，影響挺大的。
Google搜索了一下，是一個常見問題，也提供了一些方法。只是後來發現，這些方法要不就是沒有說清楚，要不就是誤解。經過測試，最終基本可以解決了。
大概的意思是說：
參考該文章的內容，我們可以看看yum更新下載的數據： /var/cache/yum，根據你定義的repo.d文件內容，會分開多層目錄，每層代表一個更新路徑。
找到原因，解決就不難了。
先把舊的緩存數據都去掉。
對比repomd.xml中的信息：
若數據正確，則說明metadata和校驗數據是匹配的。可以使用yum更新了，不會再重新下載metadata。
否則，可以再等待一下，或需要從其他的鏡像獲取更新咯。
※primary.xml.gz是使用--cache=off參數的，而primary.xml.gz.1是沒有使用該參數的。
所以，如果網絡出現問題，是會影響到yum下載數據的完整性的。而使用--cache=off既然沒壞，不妨使用咯。
來源地址： http://www.linuxfly.org/read.php?174
最近發現，在使用yum更新包的時候，常報下面的錯誤：
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.有時候當替換了幾個鏡像後就可以了。但經常也會發現最終是失敗的。由於我的系統是依賴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...大概的意思是說：
當生成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進行校驗的。找到原因，解決就不難了。
二、解決
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
3、校驗數據
執行：
# sha1sum other.xml.gz filelists.xml.gz 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>若數據正確，則說明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※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...
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