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