David Timms wrote:
Andre Robatino wrote:
Recently, the error "[Errno -1] Metadata file does not match
checksum" often happens repeatedly while trying to download the file
primary.sqlite.bz2 from different servers. It's common for this to
happen around a dozen times or more, which since the file is 3.8M can
add up to 50M just to download metadata to find out whether there are
updates. For those on dialup, this is a major pain. Why is this
happening? For example
Each yum repo has a very small file: repomd.xml [eg < 2kB].
This file is used to determine whether there has been a change to the
repository since the last check {ie yum based tool run - except there
is an option to only check once each x {default 15minutes} seconds}.
If the files pointed to by repomd.xml on your local disk are not the
correct size or md5sum, then yum knows it needs to download each one
mentioned files.
So it uses the live mirrorlist {by default - and customized to your
country -if more than two in country mirrors seem OK, otherwise the
general all mirrorlist}, connects at random to one of the mirrors, and
downloads the apparently ~out of date~ metadata file.
Now, either the mirror that it retrieved repomd.xml from could
actually be out of date, or all the other mirrors metadata could be
out of date; I'm guessing the first. This leads to every good mirror
providing a perfectly good metadata file, but since it doesn't match
the repomd.xml it is trashed, and the next mirror tried.
In general this shouldn't happen because:
- the ~live~ mirror list provides only mirrors that are up2date.
- the local metadata cache is considered stale and rechecked after 15
minutes {this speeds up things if you do sequential commands with yum
based tools.}
In your case something extra is occurring: for the first two mirrors,
each primary.sqlite.bz2 download is retrieved twice from the same
mirror, I haven't seen that before. Also, two of the mirrors are
randomly chosen again. This may be a bug, and I need mire information:
To further fault find this:
1. What is the contents of /etc/yum.repos.d/fedora-updates.repo ?
2. In the [updates] section, what is the mirrorlist= value ?
3. Open your web browser:
4. Copy/paste the mirrorlist url
5. Modify the $releasever to be your fedora version
6. Modify the $basearch to be your fedora architecture
7. Hit go/enter to download the mirrorlist. What does that say ?
Please reply just to the list, thanks,
DaveT.
I haven't edited /etc/yum.repos.d/fedora-updates.repo, as verified by
"rpm -V fedora-release-7-3", the package the file belongs to. In the
[updates] section,
mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=updates-released-source-f$releasever&arch=$basearch
and accessing the URL
http://mirrors.fedoraproject.org/mirrorlist?repo=updates-released-f7&arch=i386
gives
# repo = updates-released-f7 arch = i386 country = US country = US
http://kdeforge.unl.edu/mirrors/fedora/linux/updates/7/i386
http://ftp.linux.ncsu.edu/pub/fedora/linux/updates/7/i386
http://mirror.newnanutilities.org/pub/fedora/linux/updates/7/i386
http://ftp.usf.edu/pub/fedora/linux/updates/7/i386
http://mirrors.kernel.org/fedora/updates/7/i386
http://mirror.stanford.edu/fedora/linux/updates/7/i386
http://www.gtlib.gatech.edu/pub/fedora.redhat/linux/updates/7/i386
http://mirror.steadfast.net/fedora/updates/7/i386
http://mirror.cc.vt.edu/pub/fedora/linux/updates/7/i386
http://mirrors.cat.pdx.edu/fedora/linux/updates/7/i386
ftp://ftp.uci.edu/mirrors/fedora/linux/updates/7/i386
http://srl.cs.jhu.edu/YUM/fedora/updates/7/i386
http://mirror.web-ster.com/fedora/updates/7/i386
http://mirror.cogentco.com/pub/linux/fedora/linux/updates/7/i386
http://linux.nssl.noaa.gov/fedora/linux/updates/7/i386
http://mirror.nuvio.com/pub/fedora/linux/updates/7/i386
ftp://mirror.cs.princeton.edu/pub/mirrors/fedora/linux/updates/7/i386
http://mirrors.usc.edu/pub/linux/distributions/fedora/linux/updates/7/i386
http://mirror.hiwaay.net/pub/fedora/linux/updates/7/i386
http://mirrors.tummy.com/pub/fedora.redhat.com/fedora/linux/updates/7/i386
http://mirror.anl.gov/pub/fedora/linux/updates/7/i386
ftp://ftp.cse.buffalo.edu/pub/Linux/fedora/linux/updates/7/i386
I just discovered the metadata_expire option in /etc/yum.conf, which
is set at 1800 (30 minutes) by default. Increasing this should make
life more bearable for dialup users, though it doesn't fix the
underlying problem. It would be nice if the concept behind Presto could
be applied to metadata as well, since only a small fraction of all
packages are updated at any one time. Please continue to cc: my email
address, as I currently have fedora-list mail delivery disabled, due to
the extremely high volume.
