[CentOS] Broken repo / mirrors?

Sat May 29 05:53:47 UTC 2010
R P Herrold <herrold at owlriver.com>

On Sat, 29 May 2010, David wrote:

> Now I'm able to update device-mapper on i386 machine, BTW please find
> this post..
>
> "[CentOS] metadata cache corruption: cleared -> fixing in progress"

Thank you for pointing people at a solution that should 
largely (mod residual mirror skew and local 'dinking' on yum 
configurations) work at this point, David

The information relayed through the day in IRC and on the main 
mailing list reflected what was known as it was known, what 
was likely, and how it was being approached.

In back control channels, the CentOS team was studying the 
matter, testing retrievals, passing updates to public facing 
parts of the group, and updating findings and possible fixes 
(and thus eta to convergences). This was available and passed 
along to public facing team members as the earth rotated 
through the day.  Let's consider it an unplanned trial shift 
in approach toward more openness on matters which have 
historically been less visible, and see how it worked out


There were at most handful of 'non-insider' posters today 
(Heller, Roth, Cox, Nichols, Charm) and I think three relevant 
bugs, which bugs should all be addressed by now.  As one 
person noted: 'The world was not coming to an end' but I see:
 	16:58:06 UTC Heller
 		"*ALL* of the public mirrors are broken"

 	later 01:39:51 UTC next UTC day:
 		"*I* never claimed it was the end of the
 	world.  Just noticed a problem and posted a question to the
 	list about it"

<dryly>and this knowledge of ALL mirrors with just a dial-up 
connection</>  That is sure not how I read his Chicken Little 
assertion;  I see a cry of 'Wolf' and alarmism as a reward

 	21:30:22 UTC Byrne (broken threading)
 		"Does not work"

 	with a repository selection that looks VERY skewed to 
only one: centos.mirror.iweb.ca

That single mirror from our dispatch code is possible, but 
pretty unlilkely; if in a bug I might run down what is in play 
to have produced it.  It MAY indicate that the 'staleness' was 
noted by the scripts that update the dispatcher, from the 
known skew, as the scripts noted the matter as well and 
dialled back repository archives handed out.  But there should 
have been more than just one show up ... if that one is so 
overwhelming close that it 'always wins', there is a design 
problem because one loses the diversity needed to recover from 
one stale mirror [interrupting the pulls with a ^C to force a 
failover can help there, but no-one reads that part of the 
doco ;) ]


If in IRC, a couple seconds check would tell the tale 
about the 'pristine' or other nature of the yum configuration 
in play; if a bug were filed, a similar result because I'd 
drop the same questions back on the reporter to get a 
reproducer and visibility into their configuration changes, if 
any, from stock.

Instead, we get the drive by complaint and the load in an 
intentionally non-synchronous medium [email].  This is a venue 
where it just does not make sense to respond to 'noise'

No win there

My $0.02

-- Russ herrold