Red Hat Bugzilla – Bug 202865
yum is not consistent
Last modified: 2014-01-21 17:54:56 EST
Description of problem:
On computer #1 Pent III 800 (FC6 Desktop install)
yum development repo,
changed urlbase= to point to a local mirror url
left mirrorlist as was.
Each yum update starts with old primary.xlg list of 2211 size.
Somethimes a yum clean meatdata will cause the new primary.xlg size fo (2223,
2232, 2239 for the last few days of updates.)
This incorrect size causes yum to access the sqllite db for over 15 minutes and
ends with a wrong or old packages list (ussally short and not current.)
For today's Aug 16th updates I #'ed out the mirrorlist to insure getting the
correct primary.xlg size (which it did from the local miror) and proceeded to
download headers and packages as full speed. The update was fine and a reboot
About 40 minutes later on computer #2 Pent IV ht (Desktop Install)
change yum devlopment repo to localmirror and no mirrorlist (same as above)
Yum upadte returned the correct size and began headers download instatly (as
above) BUT on rhe fisrt header it error out as header incomplete and stopped
with no more mirrors.
I tried again with same results. This is the same mirror that worked just 40
minutes ago and the mirror was fully updates with the AUG 16th updates and that
header was download and so was the package.
I then uncomment the yum development repo mirrorlist and tried again,
it again showed the error on the local mirror with incomplete header and
switched to a new mirror and preceeded to download headers and packages, but
Version-Release number of selected component (if applicable):
Steps to Reproduce:
mirror header incomplete on a mirror from Computer #2 after it was correct on
If the header or package on a mirror is written bad it would be bad for all.
If the package was changed from good to bad, then computer #1 s/h failed
(consistently) and computer #2 would have failed consistently until the header
was rewritten as good.
The bad headers and packages have also been the cause of on line installs
crashing in the past.
Incomplete headers is a problem and causes many duplicate yum attemps.
The bad headers and packages are not corrected for long periods of time.
(Usually the only correcting agent is when that package is rebuilt)
These conditions distract from test time, and the over all amount and quality of
This sounds like a bad set of mirrors and/or communication to them is
I'm going to need more info as to what you want me to fix here.
Closing due to inactivity