"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.
Interested in participating? Red Hat Customer Portal Discussions are open to the public and can be viewed by everyone, but you must have a Red Hat Subscription to post and participate. Login now!
Comments
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 there,
The systems are directly connected to RHN, yes. No Satellite in the mix at all.
Delete the repo information? From where? RHN? Not sure I can do that. I don't have any support with RH, so I'm not sure I'm allowed to call them. I haven't seen anyone else with a 32-bit workstation complaining. Maybe there aren't any, or it's just me. Why it's just all of my 32-bit workstations though I don't know...
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:
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?
Hi there,
As you can see from my initial posting, I start with a "yum clean all". I then do a "yum update". There's no need to "echo n" as it never gets to the point at which the choice to press "y" or "n" comes up. Also, as you can see above, there are no other .repo files being used.
All of my RHEL5 32-bit workstations (note, not 32-bit server, nor any 64-bit versions of RHEL5 client or server) are affected. This issue is confined solely to RHEL5 32-bit client installs with the workstation child channel. And all of them.
I have, for the moment, 'solved' this issue by finding the one RHEL5 32-bit workstation which I hadn't tried to update since 31 July (see William Stromberg's post below) and copied /var/cache/yum/rhel-i386-client-workstation-5/ from it to those machines having issues. This allowed them to be updated successfully. This proves pretty conclusively that there's nothing wrong with my machines, but with the checksums for the RHN repo/channel for RHEL5 32-bit workstation...
It really shouldn't take RH this long to have a look and see what the problem is, should it?
Disappointingly, these machines are all used by users who don't want to have their installs taken away for any length of time (and replaced with new, shiny RHEL6/7 64-bit client installs). Therefore, no, I'm not 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
yes, you are correct, sorry I missed that.
I agree with you - I hope Red Hat helps you soon with this.
Update:
Looks like it's been fixed now.
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."
Yes, I can confirm that that cache flush of the CDN seems to have fixed it. I'll be thanking Dennis Gregorovic via the mailing list shortly. However, is there a mechanism to ensure this kind of thing doesn't happen again? Or a work-around that doesn't involve the coping I did? Disabling "Location-aware updates", perhaps?
Ben
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