Bug 244945

Are you pointing explicitly at a mirror or just using the default mirrorlist setup?

I have had precisely the same problem with no updates since 26JUN07 until this
morning after doing "yum clean all".  I suspect the fastestmirror plugin as
/var/cache/yum/timedhosts.txt is also deleted by "yum clean all".  If the
fastest mirror was not being synced correctly that may explain this behaviour. 
I have not, however, tried the selinux relable as the problem has not yet
recurred.  

Robert, do you have the fastestmirror plugin installed?
$ rpm -q yum-fastestmirror
yum-fastestmirror-1.1.5-1.fc7

I have also had the same problem. I'm using the default mirrorlist setup, and I
have the fastestmirror plugin installed. A "yum clean all" usually, but not
always, solves the problem. Sometimes, I had to do a "yum clean all" followed by
a "yum --noplugins update" to actually get any updates.

It sounds like you could be hitting an out of sync mirror each time..  Try
applying the following patch to /usr/lib/yum-plugins/fastestmirror.py

--- a/plugins/fastestmirror/fastestmirror.py
+++ b/plugins/fastestmirror/fastestmirror.py
@@ -82,6 +82,7 @@ def postreposetup_hook(conduit):
         repo.failovermethod = 'priority'
         repo.check()
         repo.setupGrab()
+        print "repomirrors[%s] = %s" % (str(repo), repomirrors[str(repo)])
     if not loadcache:
         write_timedhosts()
 
This will make fastestmirror spit out the mirrorlist for each repository.  This
way you'll be able to see which mirror you are hitting, and will then be able to
determine if it is out of sync or not.

Other than an out of sync mirror, I can't think of anything that fastestmirror
is doing that would prevent you from getting updates.

I added the line to fastestmirror.py, but it outputs a very long list of
mirrors. Should I manually check if they are out of sync when the problem occurs
next time? That would take an entire day, time that I may have to spare.

Or is there a way to check mirror sync using some automated tool?

The first entry of each list is the mirror that your client uses *first*, which
is possibly out of sync.  You could check by hand if that mirror contains the
updates you are looking for, or look at the repodata.

I've been thinking about it, and it could also be that the mirrormanager is
sending you a list of mirrors (lets say mirror A is out-of-sync and has been
removed from this list).  Fastestmirror doesn't care and just loads the cached
hosts file as it is, even if A is at the top of the list.  I think if
fastestmirror somehow was able to prune out non-existent mirrorlist entries from
the cache, it may fix some problems -- considering the mirrormanager goes out of
it's way to keep things in check.

Today, when updating my system, the problem occurred again. The complaint was
about missing dependency kernel-xyz-85.fc7 (xyz = the details are irrelevant)
for kmod-ntfs-xyz-85.fc7. The problem was that the latest kernel was xyz.91.fc7
while the latest kmod-ntfs was xyz.85.fc7. I checked the first mirror
(mirror.atrpms.net), and sure, it hadn't got the latest kmod-ntfs.

Then I decided to do a "yum clean all" to see if fastestmirror would select
another mirror, and it did. This mirror had the latest kmod-ntfs, and the update
worked as expected.

Note though that in this case, the failing mirror was for livna, which don't use
a mirrormanager, but rather a static list of mirrors in the repo file.

Unless I'm misreading this sounds like notabug. Out-of-sync mirrors are pretty
much impossible to fix in fastest-mirror.