"RHEL Desktop Workstation (v.5 for 32-bit x86)" child channel has bad checksum
Currently, all of my RHEL5 i386 Workstations are doing this:
[root@kettle ~]# yum clean all
Loaded plugins: rhnplugin
Cleaning up Everything
[root@kettle ~]# yum update
Loaded plugins: rhnplugin
This system is receiving updates from RHN Classic or RHN Satellite.
rhel-i386-client-5 | 1.4 kB 00:00
rhel-i386-client-5/primary | 4.9 MB 00:00
rhel-i386-client-5 10353/10353
rhel-i386-client-supplementary-5 | 1.4 kB 00:00
rhel-i386-client-supplementary-5/primary | 277 kB 00:00
rhel-i386-client-supplementary-5 944/944
rhel-i386-client-workstation-5 | 1.4 kB 00:00
rhel-i386-client-workstation-5/primary | 825 kB 00:00
rhel-i386-client-workstation-5/primary | 825 kB 00:00
rhel-i386-client-workstation-5/primary | 825 kB 00:00
rhel-i386-client-workstation-5/primary | 825 kB 00:00
Error: failed to retrieve repodata/89e31cdcf3aef1da587850a365a8b014d40c003a-primary.xml.gz from rhel-i386-client-workstation-5
error was [Errno -1] Metadata file does not match checksum
[root@kettle ~]#
All RHEL5 i386/x86_64 Servers and RHEL5 x86_64 Workstations are updating happily.
Anyone else having issues?
All the computers have active subscriptions with RHN. One, which had lost its child channel subscriptions owing to temporarily having been downgraded to "Update" rather than "Management" entitlement, was prepared to update until I readded the "RHEL Desktop Workstation (v. 5 for 32-bit x86)" child channel to depsolve some packages, at which point I got this:
Error: failed to retrieve repodata/00c88bd13aefb00b56c228e899f418a0ace9a077-filelists.xml.gz from rhel-i386-client-workstation-5
error was [Errno 14] HTTP Error 404: Not Found
Which is subtly different, but still indicates some kind of issue with this child channel.
Responses
Hi Ben,
I get the impression your systems are directly connected to Red Hat Inc and are not managed by a Satellite server? Is this true? If you do use a satellite server, is it "connected" (to RHN) or "disconnected"?
You could delete the repo information for the failing channel (call support first), but you'd have to be prepared to recreate it with taskomatic, and triggering the proper job. If you are using Red Hat Satellite, what version are you using? Also, make sure you have the most current version of spacewalk-java. Also see this link (Red Hat solution #43122) regarding taskomatic errors (and see the comment by Mathieu Marchand near the end regarding Satellite 5.7)
If your systems are connected directly to Red Hat Inc via "RHN", then I'd recommend you contact Red Hat support. If you are using a Red Hat Satellite, and if it is disconnected, I'd make sure your ISO channel dumps you acquire from Red Hat Inc are valid by doing an md5sum against the ISO files per this Red Hat discussion.
Either way, I'd recommend contacting support.
Hi Ben, the idea of deleting the repo info was for a satellite in this case, and if you were to do that, as I mentioned, I'd contact Red Hat support first.
Since you are directly connected to RHN, perhaps try as a start:
yum clean all
echo n | yum update
The "echo n | yum update" will run through an update scenario, however, will exit without doing any updates due to the "echo n" preceding it. You can then view the output. Also see if there are any non-standard yum repo files in /etc/yum.repos.d/ with an extension of ".repo" that are non-typical. Are you able to update any of your systems, or do they all fail in the way you described?
I'd contact Red Hat support if that does not resolve it.
Side note, are you able to use the 64 bit version of RHEL?
Ben, thanks for the tip about copying the cache contents over. Now I have to try and find the one machine I have that might be similarly 'untainted' :-)
This is a big problem for us as we have our own local repo in addition to the Red Hat and other repos, so if I add content to the local repo and want to install it on a RHEL 5 system that is registered with RHN and has yum-updatesd running, to install anything means I need to do at least a "yum clean metadata" first which of course means that the machine instantly runs afoul of this issue.
I can disable the "rhel-i386-client-workstation-5" repo temporarily for the install but that's not ideal ... plus, once it happens, unless I kill "yum-updatesd" I start getting warnings about it once an hour from then on.
Greg Earle
Jet Propulsion Laboratory
Update:
Looks like it's been fixed now.
[root@testmule-rh54x32 ~]# yum clean all
Loaded plugins: rhnplugin, security
Cleaning up Everything
[root@testmule-rh54x32 ~]# ls -R /var/cache/yum/rhel-i386-client-workstation-5
/var/cache/yum/rhel-i386-client-workstation-5:
headers packages
/var/cache/yum/rhel-i386-client-workstation-5/headers:
/var/cache/yum/rhel-i386-client-workstation-5/packages:
[root@testmule-rh54x32 ~]# yum list yum
Loaded plugins: rhnplugin, security
adobe-linux-i386 | 951 B 00:00
[...]
rhel-i386-client-workstation-5 | 1.4 kB 00:00
rhel-i386-client-workstation-5/primary | 1.2 MB 00:00
rhel-i386-client-workstation-5 4759/4759
[...]
Installed Packages
yum.noarch 3.2.22-20.el5 installed
Available Packages
yum.noarch 3.2.22-40.el5 local-RHELv5
Ben, can you confirm?
Greg Earle
Jet Propulsion Laboratory
This post indicates it's been fixed by flushing the CDN cache:
"I could not find any issues with the repodata files on RHN itself and suspect an issue with CDN caching. I've flushed the cache for the rhel-i386-client-workstation-5 repodata URLs."
I found this page doing a search on this very issue. It started back on July 31st (somewhere around 10 PM PDT). and now if I do a "yum clean all" on any of our 32-bit RHEL 5.4 machines (yes, some of us have to deal with "Mission freeze" configurations!) and a "yum makecache" (or "yum list" or anything), it will elicit this error. We are directly connected, no Red Hat Satellite involved.
I think the problem is in your television set, Red Hat.
Greg Earle
Jet Propulsion Laboratory
Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.
