I fixed my earlier problem with a 'yum clean all', now I am getting this problem:
'Package does not match intended download'
for both device-mapper and net-snmp-libs, for ALL of the mirrors. Log of the output is attached.
On Friday 28 May 2010, Robert Heller wrote:
I fixed my earlier problem with a 'yum clean all', now I am getting this problem:
'Package does not match intended download'
Sounds like the new meta-data you got after your 'yum clean all' was bad (ie. does not match the packages on any other mirror). Try pointing yum to a trusted mirror and re-run the clean all.
It could be something else also but the packages you pull down does not match the checksums in the meta-data. Less likely reasons for this includes an evil proxy, bad RAM, ...
/Peter
for both device-mapper and net-snmp-libs, for ALL of the mirrors. Log of the output is attached.
Peter wrote:
On Friday 28 May 2010, Robert Heller wrote:
I fixed my earlier problem with a 'yum clean all', now I am getting this problem:
'Package does not match intended download'
Sounds like the new meta-data you got after your 'yum clean all' was bad (ie. does not match the packages on any other mirror). Try pointing yum to a trusted mirror and re-run the clean all.
Good thought, to clean metadata, and I tried that, but no joy.
It could be something else also but the packages you pull down does not match the checksums in the meta-data. Less likely reasons for this includes an evil proxy, bad RAM, ...
But I get *exactly* the same problem.
for both device-mapper and net-snmp-libs, for ALL of the mirrors. Log of the output is attached.
I looked closer. Both are *new* sub-subreleases, one el5_5.1, and the other el5_5.2. And I just got, from the RH network, an errata alert on device-mapper. Wonder if someone(s) got it, and are trying to put this new fix into place.
mark
On 05/28/2010 11:51 AM m.roth@5-cent.us wrote:
Peter wrote:
On Friday 28 May 2010, Robert Heller wrote:
But I get *exactly* the same problem.
I had the same problem too... Friday morning, while trying to get myself out of town... so I haven't looked into it much. Just bailed on much of the upgrade.
At Fri, 28 May 2010 16:35:44 +0200 CentOS mailing list centos@centos.org wrote:
On Friday 28 May 2010, Robert Heller wrote:
I fixed my earlier problem with a 'yum clean all', now I am getting this problem:
'Package does not match intended download'
Sounds like the new meta-data you got after your 'yum clean all' was bad (ie. does not match the packages on any other mirror). Try pointing yum to a trusted mirror and re-run the clean all.
*ALL* of the public mirrors are broken WRT these two files. Should I just point at the the *master* CentOS server? (I am not sure if the CentOS team would really like that idea...) *I* am not able to maintain my own mirror (probably a really bad idea over dialup...).
It could be something else also but the packages you pull down does not match the checksums in the meta-data. Less likely reasons for this includes an evil proxy, bad RAM, ...
And it seems *I* am not the only one having problems with these two files, which suggests that bad RAM is unlikely. Esp. since it is specificly repeatable with exactly these two files and if I exclude these two file, yum is happy to do all of the other updates without problems (well, two other packages fail to update due to failed dependencies and are skipped via --skip-broken).
It seems like there is a major snafu somewhere -- it is not just a random mirror here or there not being up-to-date, but more of a wholesale problem -- are we *sure* the metadata on the root server is not broken somehow?
For now, I am just going to exclude device-mapper and net-snmp-libs until I hear that the metadata has been checked / fixed.
/Peter
for both device-mapper and net-snmp-libs, for ALL of the mirrors. Log of the output is attached.
Content-Description: This is a digitally signed message part.
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQBL/9TEWkaLDtAygc8RAmtWAJ9EByVxcdeegnG+ab7ICtcIl2CexgCfWMv/ Jmdi3wPtC90LVZ+/fbvINfA= =85FR -----END PGP SIGNATURE-----
MIME-Version: 1.0
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Robert Heller wrote on 05/28/2010 11:58 AM: ...
For now, I am just going to exclude device-mapper and net-snmp-libs until I hear that the metadata has been checked / fixed.
Just did a successful update including: device-mapper-1.02.39-1.el5_5.2 net-snmp-libs-5.3.2.2-9.el5_5.1
I think it's just a matter of the mirrors being slow syncing all the recent updates.
Phil
At Fri, 28 May 2010 12:14:56 -0400 CentOS mailing list centos@centos.org wrote:
Robert Heller wrote on 05/28/2010 11:58 AM: ...
For now, I am just going to exclude device-mapper and net-snmp-libs until I hear that the metadata has been checked / fixed.
Just did a successful update including: device-mapper-1.02.39-1.el5_5.2 net-snmp-libs-5.3.2.2-9.el5_5.1
I think it's just a matter of the mirrors being slow syncing all the recent updates.
Umm... I just edited my CentOS-Base.repo file to point to http://mirror.centos.org/centos/5/updates/..., did a yum clean metadata and I am *still* getting errors:
http://mirror.centos.org/centos/5/updates/i386/RPMS/device-mapper-1.02.39-1....: [Errno -1] Package does not match intended download http://mirror.centos.org/centos/5/updates/i386/RPMS/net-snmp-libs-5.3.2.2-9....: [Errno -1] Package does not match intended download
Isn't mirror.centos.org the master server? It looks like the metadata (at least for the i386 repo) on the master server is broken...
Phil _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Fri, 2010-05-28 at 11:58 -0400, Robert Heller wrote:
And it seems *I* am not the only one having problems with these two files, which suggests that bad RAM is unlikely.
My updates to x86_64 machines worked fine, but the i386 update gives me the "package does not match intended download" error on device-mapper and net-snmp-libs as well.
So it looks like there's something wrong but only on the i386 side.
On Fri, 2010-05-28 at 11:58 -0400, Robert Heller wrote:
And it seems *I* am not the only one having problems with these two files, which suggests that bad RAM is unlikely.
My updates to x86_64 machines worked fine, but the i386 update gives me the "package does not match intended download" error on device-mapper and net-snmp-libs as well.
So it looks like there's something wrong but only on the i386 side.
I meant to mention that in the last post, also - that does seem to be the problem.
mark
On 05/28/2010 11:17 AM, Frank Cox wrote:
On Fri, 2010-05-28 at 11:58 -0400, Robert Heller wrote:
And it seems *I* am not the only one having problems with these two files, which suggests that bad RAM is unlikely.
My updates to x86_64 machines worked fine, but the i386 update gives me the "package does not match intended download" error on device-mapper and net-snmp-libs as well.
So it looks like there's something wrong but only on the i386 side.
Yes, the i386 updates are broken. Here's what works around the problem for me:
--exclude={net-snmp,net-snmp-devel,net-snmp-libs,device-mapper,device-mapper-event,lvm2}
On Fri, 28 May 2010, Robert Heller wrote:
At Fri, 28 May 2010 16:35:44 +0200 CentOS mailing list centos@centos.org wrote:
On Friday 28 May 2010, Robert Heller wrote:
It seems like there is a major snafu somewhere -- it is not just a random mirror here or there not being up-to-date, but more of a wholesale problem -- are we *sure* the metadata on the root server is not broken somehow?
The distribution repodata usually lags the files the way most mirrors choose to retrieve it (quite properly as that is the most 'automatable' approach); the cascade nature of the mirroring network and the lack of direct control of WHEN a mirror (or more likely, intermediate distribution mirror) BECAUSE CENTOS RELIES ON DONATED RESOURCES causes periodic skew as the system comes back in to coherency. This is one of those times
If a user of CentOS cannot tolerate lag, they can choose to run a local sub-mirror, and build repodata locally in advance of mirroring repodata; the scripting is trivial
If a person/entity cannot tolerate delays in the build, qa and release process CentOS follows, there are multiple write-ups on rpm building, either for selected SRPMS, or the whole shooting match that comprises the distribution.
If they still connot tolerate this, they need to chill out and consider if they are testing updates on their bench before applying updates into production, or just applying the 'latest and greatest' blindly. If one needs for some emotional reason the latest and gteatest, CentOS is not likely to be a satisfying fit for that personality type. People with a testing bench have probably solved building and are probably mirroring SRPMS off the upstream anyway
My little personal s390 autobuilder [a] is walking through a rebuild of C4 atm and has been for a couple weeks. It looks as though it will run about 160 hr a cycle as it converges on a selfhosting build environment; then I will check some fruit, toss out skew and rebuild it all again from my locally produced binaries, through a process of buiklding and testing several chroots. Then I will rebuild all in those chroots yet again. Then I will build for record. If you are keeping score, this is perhaps 600 hr for a clean base to build from. Then I will build the side leaves, and hope I can get say 80% success on the 2700 or so SRPMS
Then I will 'bootstrap up' into a C5 series, and then a C6 series. As this is a labor of love, and a bit of art rather than a mechanical turning of a crank, I don't care -- it is ready when it 'right' to please selfhosting, trademark fixup, updater fixup, and API versions testing to match the libraries present (and absent) and at the versions that I care about
If this sounds laborious and a lotlike work and not particularly fun, that would be accurate
If a user of CentOS would not learn or do these steps, they need to consider buying a SLA backed subscription to the upstream's distribution to meet their time sensitivity.
It really will not hurt my feelings, and I suspect, neither those of any of the core CentOS team, if there is financial support of CentOS' upstream with such subscriptions. Indeed such support helps ensure the continuation of a 'good guy' FOSS citizen resource that all of CentOS depends heavily on
[1] http://twitter.com/buildmonbot A s390x, with a gig of ram allocated to it, and several LVM spindles, fed from a dedicated SRPM submirror, and out-saved through rsync to another binary result mirror
-- Russ herrold
On 05/28/2010 11:37 AM, R P Herrold wrote:
On Fri, 28 May 2010, Robert Heller wrote:
At Fri, 28 May 2010 16:35:44 +0200 CentOS mailing listcentos@centos.org wrote:
On Friday 28 May 2010, Robert Heller wrote:
It seems like there is a major snafu somewhere -- it is not just a random mirror here or there not being up-to-date, but more of a wholesale problem -- are we *sure* the metadata on the root server is not broken somehow?
The distribution repodata usually lags the files the way most mirrors choose to retrieve it (quite properly as that is the most 'automatable' approach); the cascade nature of the mirroring network and the lack of direct control of WHEN a mirror (or more likely, intermediate distribution mirror) BECAUSE CENTOS RELIES ON DONATED RESOURCES causes periodic skew as the system comes back in to coherency. This is one of those times
This doesn't appear to be a lag problem. For each of the broken packages, the mirror does have a file with the expected name and a size that matches the metadata. The downloaded file does pass a "rpm -q --checksig" test, but yum claims, "[Errno -1] Package does not match intended download". If the affected packages are manually fetched with wget using the same URL that yum reported as broken, all the signatures check OK and "yum localinstall" upgrades the packages without complaint.
The same error occurs on all mirrors and on the baseurl repo. It appears that a metadata file was pushed with checksums that do not match some of the files in the repo.
If the affected packages are manually fetched with wget using the same URL that yum reported as broken, all the signatures check OK and "yum localinstall" upgrades the packages without complaint.
wget http://mirror.nexcess.net/CentOS/5.5/updates/i386/RPMS/device-mapper-1.0 2.39-1.el5_5.2.i386.rpm yum localinstall ./device-mapper-1.02.39-1.el5_5.2.i386.rpm
This pulls down needed dependencies and the The Magic Happens.
Thanks, Bob! ******************************************************************* This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept for the presence of computer viruses. www.Hubbell.com - Hubbell Incorporated**
You can try "yum clean all && yum makecache"
-- Best regards, David http://blog.pnyet.web.id
On 05/29/2010 12:56 AM, Brunner, Brian T. wrote:
If the affected packages are manually fetched with wget using the same URL that yum reported as broken, all the signatures check OK and "yum localinstall" upgrades the packages without complaint.
wget http://mirror.nexcess.net/CentOS/5.5/updates/i386/RPMS/device-mapper-1.0 2.39-1.el5_5.2.i386.rpm yum localinstall ./device-mapper-1.02.39-1.el5_5.2.i386.rpm
This pulls down needed dependencies and the The Magic Happens.
Thanks, Bob!
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept for the presence of computer viruses. www.Hubbell.com - Hubbell Incorporated**
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of David Sent: Friday, May 28, 2010 3:33 PM To: CentOS mailing list Subject: Re: [CentOS] Broken repo / mirrors?
You can try "yum clean all && yum makecache"
That wouldn't do me any good since I got it correctly installed by the two-liner I posted. Does this "yum clean all && yum makecache" help anybody else? I understand the problem is that the pushed metadata doesn't match the pushed rpm's; cleaning out and re-loading the mismatched metadata wouldn't be a help here. Confirm please anybody?
-- Best regards, David http://blog.pnyet.web.id
On 05/29/2010 12:56 AM, Brunner, Brian T. wrote:
If the affected packages are manually fetched with wget using the same URL that yum reported as broken, all the signatures
check OK and
"yum localinstall" upgrades the packages without complaint.
wget
http://mirror.nexcess.net/CentOS/5.5/updates/i386/RPMS/device-mapper-1
.0 2.39-1.el5_5.2.i386.rpm yum localinstall ./device-mapper-1.02.39-1.el5_5.2.i386.rpm
This pulls down needed dependencies and the The Magic Happens.
Thanks, Bob!
******************************************************************* This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept for the presence of computer viruses. www.Hubbell.com - Hubbell Incorporated**
On Fri, May 28, 2010 at 2:10 PM, Brunner, Brian T. <BBrunner@gai-tronics.com
wrote:
You can try "yum clean all && yum makecache"
That wouldn't do me any good since I got it correctly installed by the two-liner I posted. Does this "yum clean all && yum makecache" help anybody else? I understand the problem is that the pushed metadata doesn't match the pushed rpm's; cleaning out and re-loading the mismatched metadata wouldn't be a help here. Confirm please anybody?
I tried "yum clean all && yum makecache" then tried running "yum update", but ran into the same error.
On Fri, May 28, 2010 at 2:40 PM, Robert Charm bobcharm@gmail.com wrote:
I tried "yum clean all && yum makecache" then tried running "yum update", but ran into the same error.
# yum clean all && yum makecache && yum update
...
Error Downloading Packages: nss-3.12.6-1.el5.centos.i386: failure: RPMS/nss-3.12.6-1.el5.centos.i386.rpm from t0e-updates: [Errno 256] No more mirrors to try. nspr-4.8.4-1.el5_4.i386: failure: RPMS/nspr-4.8.4-1.el5_4.i386.rpm from t0e-updates: [Errno 256] No more mirrors to try. gnutls-1.4.1-3.el5_4.8.i386: failure: RPMS/gnutls-1.4.1-3.el5_4.8.i386.rpm from t0e-updates: [Errno 256] No more mirrors to try. device-mapper-1.02.39-1.el5_5.2.i386: failure: RPMS/device-mapper-1.02.39-1.el5_5.2.i386.rpm from t0e-updates: [Errno 256] No more mirrors to try.
At Fri, 28 May 2010 16:10:31 -0400 CentOS mailing list centos@centos.org wrote:
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of David Sent: Friday, May 28, 2010 3:33 PM To: CentOS mailing list Subject: Re: [CentOS] Broken repo / mirrors?
You can try "yum clean all && yum makecache"
That wouldn't do me any good since I got it correctly installed by the two-liner I posted. Does this "yum clean all && yum makecache" help anybody else? I understand the problem is that the pushed metadata doesn't match the pushed rpm's; cleaning out and re-loading the mismatched metadata wouldn't be a help here. Confirm please anybody?
This is correct. 'yum clean all' does NOT cure the problem with the two packages that "don't match the expected download". And this includes going after the metadata on the master server (mirror.centos.org). It appears that the *i386* (NOT the x86_64) metadata has a problem -- all the mirror sites are doing is mirroring the problem -- this is NOT a lag issue at all. The only work around is to *manually* download the RPMs (eg with wget) and then doing a yum localinstall of these packages. This has to be done before it is possible to complete the yum update (or you can exclude the 'broken' packages, do a yum --skip-broken update and then download the 'broken' RPMs, do a yum localinstall, and then a yum update to catch anything else (packages skipped because of the broken packages. One might as well just manually download stuff and manually use 'rpm -hUv --test *.rpm' until it stops complaining. Yech. Yum is *supposed* to get us out of that game...
-- Best regards, David http://blog.pnyet.web.id
On 05/29/2010 12:56 AM, Brunner, Brian T. wrote:
If the affected packages are manually fetched with wget using the same URL that yum reported as broken, all the signatures
check OK and
"yum localinstall" upgrades the packages without complaint.
wget
http://mirror.nexcess.net/CentOS/5.5/updates/i386/RPMS/device-mapper-1
.0 2.39-1.el5_5.2.i386.rpm yum localinstall ./device-mapper-1.02.39-1.el5_5.2.i386.rpm
This pulls down needed dependencies and the The Magic Happens.
Thanks, Bob!
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept for the presence of computer viruses. www.Hubbell.com - Hubbell Incorporated**
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Fri, May 28, 2010 at 05:28:52PM -0400, Robert Heller wrote:
packages. One might as well just manually download stuff and manually use 'rpm -hUv --test *.rpm' until it stops complaining. Yech. Yum is *supposed* to get us out of that game...
Or one could get Redhat support entitlements.
There was a problem; it was initially misdiagnosed and was later acknowledged, corrected and new meta data is being pushed out according to Tru. It happens. It wasn't the end of the world as this thread might lead some to believe; heck, packages were available and were able to be manually installed as you yourself noted. Life goes on.
John
At Fri, 28 May 2010 16:38:30 -0500 CentOS mailing list centos@centos.org wrote:
On Fri, May 28, 2010 at 05:28:52PM -0400, Robert Heller wrote:
packages. One might as well just manually download stuff and manually use 'rpm -hUv --test *.rpm' until it stops complaining. Yech. Yum is *supposed* to get us out of that game...
Or one could get Redhat support entitlements.
There was a problem; it was initially misdiagnosed and was later acknowledged, corrected and new meta data is being pushed out according to Tru. It happens. It wasn't the end of the world as this thread might lead some to believe; heck, packages were available and were able to be manually installed as you yourself noted. Life goes on.
Right. *I* never claimed it was the end of the world. Just noticed a problem and posted a question to the list about it. I wasn't sure if it was something *I* was doing wrong or if it was something other people were experiencing or what...
John
One might as well just manually download stuff and manually use
'rpm -hUv --test *.rpm' until it stops complaining. Yech. Yum is *supposed* to get us out of that game...
<computer> You lie to me, I take revenge by doing what you said without regard to what you want. Feed me garbage, I feed you processed garbage. It's all bits to me. </computer>
wget
http://mirror.nexcess.net/CentOS/5.5/updates/i386/RPMS/device-mapper-1.0 2.39-1.el5_5.2.i386.rpm
yum localinstall ./device-mapper-1.02.39-1.el5_5.2.i386.rpm
and it got fixed in the mirrored cache anyhow so this solution should be remembered for *type* not *detail*. ******************************************************************* This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept for the presence of computer viruses. www.Hubbell.com - Hubbell Incorporated**
On Fri, 2010-05-28 at 12:37 -0400, R P Herrold wrote:
[1] http://twitter.com/buildmonbot A s390x, with a gig of ram allocated to it, and several LVM spindles, fed from a dedicated SRPM submirror, and out-saved through rsync to another binary result mirror
-- Russ herrold
--- *GRINS* I question 600hr but parallel DICOM conversion can do that plus more being dependant on the image size and video. I question you but then I don't. One has to ask how many partitions are running?
Let us see `ps arcwwwxo "command %cpu %mem" | grep -v grep | head -6` every 60 secs. You can plum that in, I know you can. I thought the tweet bot was a little creative.
John
On Fri, 28 May 2010, JohnS wrote:
*GRINS* I question 600hr but parallel DICOM conversion can do that plus more being dependant on the image size and video. I question you but then I don't. One has to ask how many partitions are running?
Let us see `ps arcwwwxo "command %cpu %mem" | grep -v grep | head -6` every 60 secs. You can plum that in, I know you can. I thought the tweet bot was a little creative.
I think you are interested in this kind of result
[herrold@ibm ~]$ ps arcwwwxo "command %cpu %mem" | grep -v [pg][rs] COMMAND %CPU %MEM rpmbuild 10.8 1.0
I will add a sampler, and then reduce the data with gnuplot to graphical form, which I can then push, similar to a mrtg/rrd graph set
-- Russ herrold
On Fri, 2010-05-28 at 14:48 -0400, R P Herrold wrote:
On Fri, 28 May 2010, JohnS wrote:
*GRINS* I question 600hr but parallel DICOM conversion can do that plus more being dependant on the image size and video. I question you but then I don't. One has to ask how many partitions are running?
Let us see `ps arcwwwxo "command %cpu %mem" | grep -v grep | head -6` every 60 secs. You can plum that in, I know you can. I thought the tweet bot was a little creative.
I think you are interested in this kind of result
[herrold@ibm ~]$ ps arcwwwxo "command %cpu %mem" | grep -v [pg][rs] COMMAND %CPU %MEM rpmbuild 10.8 1.0
I will add a sampler, and then reduce the data with gnuplot to graphical form, which I can then push, similar to a mrtg/rrd graph set
-- Russ herrold
--- Can't wait sounds interesting... I thought of this also
cyclictest -t1 -n -p99 -v | to run a continuious loop, fetch data from it every so many secs. Show the nodes in the condor grid and status. Then read that and plot the average line every 60 secs. for gcc. 30,000 faults/sec, latency comes to an issue...anticapatory does not seem to help to much for that sacrificing disk throughput. The disk io loss is worth it in a way. Also sar with page faults per sec, gcc really kills memory bad. Alas in the end it shall tweetybird to all....That's my interest. Things like this get my attention span! :-)
I claim no ownership to a s390 but do to 8 pe2650's in Parralell. One Opteron64 Controller. Yes there in my home. [root@XXX~]# /usr/sbin/getSystemId Libsmbios version: 2.2.17 Product Name: PowerEdge 2650 Vendor: Dell Computer Corporation BIOS Version: A21 System ID: 0x0121
John
On Fri, 28 May 2010, JohnS wrote:
Can't wait sounds interesting... I thought of this also
John and on-lookers
May I suggest relocating this thread part to the centos-devel mailing list? See for self-service subscriptions: http://lists.centos.org/mailman/listinfo/centos-devel
teaser:
[herrold@ibm bin]$ tail -f ~/loadhx/psload-20100528 20100528164701 basename 0.0 0.0 20100528164801 remote-build-tr 4.8 0.2 20100528164801 basename 0.0 0.0 20100528164901 remote-build-tr 4.8 0.2 20100528164901 remote-build-tr 0.0 0.1 20100528165101 configure 0.0 0.0 20100528165201 cc1 76.0 1.0 20100528165301 cc1plus 84.0 1.3 20100528165401 cc1plus 58.0 1.1 20100528165501 cc1plus 67.0 1.7
-- Russ herrold
-
Brunner, Brian T. -
David -
Frank Cox -
John R. Dennison -
JohnS -
ken -
m.roth＠5-cent.us -
Peter Kjellstrom -
Phil Schaffner -
R P Herrold -
Robert Charm -
Robert Heller -
Robert Nichols