Check rhntaskomaric log and see if it's running out of working memory the default is 512MB I have found in recent versions it really needs at least 1GB



-- Sent from my HP Pre3


On Jun 6, 2014 14:44, [email protected] <[email protected]> wrote:

Matthew, I am new at this. If do not have any files in /etc/yum.repos.d directory, that is part of your problem.

install Spacewalk REPO: yum localinstall http://yum.spacewalkproject.org/2.0/RHEL/6/x86_64/spacewalk-repo-2.0-3.el6.noarch.rpm

Install EPEL REPO: yum localinstall http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm

of course this will depends on what version or OS you are running. Also you want to run setenforce 0, this will disable selinux temporarily. All in all you should have file in you yum.repos.d dir. 

From: "Matthew Madey" <[email protected]>
To: "Name, Full" <[email protected]>
Sent: Wednesday, June 4, 2014 8:27:27 PM
Subject: [Spacewalk-list] failed to retrieve repodata/repomd.xml


When running a yum -y update against a Fedora 20 client, I'm getting the below error:

 One of the configured repositories failed (Unknown),
 and yum doesn't have enough cached data to continue. At this point the only
 safe thing yum can do is fail.

failed to retrieve repodata/repomd.xml from fedora20-base-x86_64-updates
error was [Errno 14] HTTPS Error 404 - Not Found

The client is subscribed to 2 child channels, and only the "updates" channel is causing the issue. Another Fedora 20 client configured the same way can download the repodata just fine. 
I don't have any .repo files in /etc/yum.repos.d/.. Here's what I've already tried thus far:

On client
- yum clean all
- rm -Rf /var/cache/yum/*
- Re-registering with Spacewalk
- Compared rhn-plugin and other yum packages with working client, no differences in versions
- Copying repodata from working client to affected client
- Disabling iptables
- Disabling SSL in /etc/sysconfig/rhn/up2date

On Spacewalk server
- rm -Rf /var/cache/rhn ; service taskomatic restart (waited a full day to allow for metadata regeneration)
- Unsubscribing and re-subscribing the client to the affected channel
- tailing /var/log/httpd/error_log (surprisingly no errors)

Right now I'm going back to the standard repo's and bypassing Spacewalk for this client to update, then I'll try again and see if I can get this working. Anyone have ideas as to what could be wrong? 






_______________________________________________
Spacewalk-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/spacewalk-list

_______________________________________________
Spacewalk-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/spacewalk-list

Reply via email to