[CentOS] Broken repo / mirrors?
R P Herrold
herrold at owlriver.com
Sat May 29 05:53:47 UTC 2010
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
More information about the CentOS
mailing list