Yum: the dreaded metadata disease

Michael Schwendt mschwendt at gmail.com
Tue Dec 18 18:44:26 UTC 2007


On 18/12/2007, Claude Jones <cjones at levitjames.com> wrote:
>
> When a new package is
> uploaded to a repository, that list must be updated. All these actions
> occur in time. On occasion, it is possible to get a list that's not been
> fully updated after a new package has been uploaded. You've arrived at
> the repository at an in-between time between when the new package has
> been uploaded, and when the file list has been updated to reflect that
> change.

I don't think this is true. Metadata files like "primary.sqlite.bz2"
for F8 updates are less than 1 MiB in size. Compared with package
sizes, it doesn't take long to sync. And tools like rsync don't
corrupt the live files while downloading the new data to a temporary
file. How likely is it that you encounter a dozen mirrors (from a list
handed out by Mirror Manager) which offer a repomd.xml file that
doesn't match the metadata files?

What I've experienced multiple times is mirror 'A' giving a repomd.xml
from three days ago while mirror 'B' was offering up-to-date repodata
contents. And Yum had started with mirror 'A' and subsequently
compared A's repomd.xml checksums with B's metadata files. Obviously,
"yum clean metadata" helps as soon as you find a stable connection to
a single mirror without yum switching through the entire mirror-list.

Any time you see the metadata checksum error, interrupt yum and
examine the remote "repodata" directories of the first few mirrors
manually. The mirror-list is in
/var/cache/yum/updates/mirrorlist.txt and you only need to add
"/repodata" to the urls within that file to visit them with your
favourite browser (or to copy the entire repodata dir before you
examine it).




More information about the fedora-list mailing list