[Spacewalk-list] Spacewalk 2.0 unable to update clients

miller3489 at comcast.net miller3489 at comcast.net
Fri Nov 22 14:13:21 UTC 2013


Larry, my apology on the incorrect information (rhn_check -v-v-v).. My correction is run the following on your client.. /usr/sbin/ osad -N -v -v -v.. also check to ensure your repo is correct by running the following on your client.. yum --verbose repolist. However.. taskomatic should be running on spacewalk in order for the metadata to be generated. 
  
mike miller 

----- Original Message -----

From: "Dimitri Yioulos" <dyioulos at onpointfc.com> 
To: spacewalk-list at redhat.com 
Sent: Friday, November 22, 2013 8:31:47 AM 
Subject: Re: [Spacewalk-list] Spacewalk 2.0 unable to update clients 

Previous posts may well be correct but, in my experience at 
least, the following from your log: 

Cannot retrieve repository metadata (repomd.xml) for 
repository: epel_ol6.4_x86_64. Please verify its path and 
try again 

usually means a connectivity error.  Are you sure your 
server can get out to the 'net, and that you're pointing to 
the EPEL repository correctly?. 

Dimitri 


On Friday 22 November 2013 5:28:16 am Andreas Dijkman wrote: 
> In my experience, the Taskomatic-daemon has not enough 
> memory to do all the errata and repository stuff. I had 
> to raise the xmx-value for taskomatic and after that, it 
> all ran smooth. I had to change it in the file 
> /usr/share/rhn/config-defaults/rhn_taskomatic_daemon.conf 
> and restart taskomatic. Than retry the reposync for all 
> the repositories and try again. 
> 
> Kind regards, 
> 
> Andreas Dijkman 
> 
> On 22 Nov, 2013, at 1:41 , Micheal & Maxine Miller 
<miller3489 at comcast.net> wrote: 
> > Larry, I am not an expert, matter of fact I am new to 
> > the Linux and Spacewalk world. what does rhn-satellite 
> > status says. Ensure Taskomatic is running. If 
> > taskomatic is not running, then look into your httpd 
> > dir and ensure that “Listen” only has the port number. 
> > For example: Listen 80 and not the full FQDN. 
> > Taskomatic has to run in order for the metadata to be 
> > generated. Also what does rhn_check  -v -v  -v –v shows 
> > 
> > Mike Miller 
> > 
> > From: spacewalk-list-bounces at redhat.com 
> > [mailto:spacewalk-list-bounces at redhat.com] On Behalf Of 
> > Clegg, Larry E [HDS] Sent: Thursday, November 21, 2013 
> > 3:14 PM 
> > To: spacewalk-list at redhat.com 
> > Subject: [Spacewalk-list] Spacewalk 2.0 unable to 
> > update clients 
> > 
> > Greetings Spacewalkers, 
> > 
> > I am running Spacewalk V2.0 on Oracle Linux 6.4 with 
> > the latest patches. I am running Cobbler V2.4.0 
> > 
> > I’ve created base/child channels and reposync’d them 
> > from the various public repos. 
> > 
> > I am successfully performing a bare metal install on a 
> > client and that client is successfully registering back 
> > to the Spacewalk server.  But when I attempt to apply 
> > any updates to that client I get the errors shown 
> > below.  So far we have not figured out the root cause 
> > and fix.  Hopefully this list will be able to offer 
> > some insight. 
> > 
> > Thank you, 
> > Larry 
> > 
> > From the client: 
> > 
> > [root at shdswalk240 log]# yum repolist 
> > Loaded plugins: rhnplugin, security 
> > This system is receiving updates from RHN Classic or 
> > Red Hat Satellite. repo id                  repo name   
> >                                  status 
> > epel_ol6.4_x86_64        EPEL for Oracle Linux 6.4 - 
> > Base (x86_64)    0 hp_ol6.4_latest          HP for 
> > Oracle 6.4                            0 oul6.4_base     
> >          Oracle Linux 6.4 - Base (x86_64)             0 
> > oul6_latest              Oracle Linux 6 Latest (x86_64) 
> >               0 ppc_2.0_oul6.4           Puppet Client 
> > for Oracle Linux 6 - x86_64    0 swc2.0_oul6.4         
> >   Spacewalk Client 2.0 for Oracle Linux 6.4    0 
> > repolist: 0 
> > 
> > Same channels as seen from the Spacewalk server: 
> > Oracle Linux 6.4 - Base (x86_64)                       
> >                         6250 Child Channel EPEL for 
> > Oracle Linux 6.4 - Base (x86_64)  9990 Child Channel HP 
> > for Oracle 6.4                                         
> >         219 Child Channel Oracle Linux 6 Latest 
> > (x86_64)                       17949 Child Channel 
> > Puppet Client for Oracle Linux 6 - x86_64  356 Child 
> > Channel Spacewalk Client 2.0 for Oracle Linux 6.4  22 
> > 
> > From the /var/log/up2date log on the client: 
> > 
> > [Thu Nov 21 11:21:24 2013] up2date logging into up2date 
> > server [Thu Nov 21 11:21:24 2013] up2date successfully 
> > retrieved authentication token from up2date server [Thu 
> > Nov 21 11:21:24 2013] up2date updateLoginInfo() login 
> > info [Thu Nov 21 11:21:24 2013] up2date logging into 
> > up2date server [Thu Nov 21 11:21:24 2013] up2date 
> > successfully retrieved authentication token from 
> > up2date server [Thu Nov 21 11:21:24 2013] up2date 
> > updateLoginInfo() login info [Thu Nov 21 11:21:24 2013] 
> > up2date logging into up2date server [Thu Nov 21 
> > 11:21:24 2013] up2date successfully retrieved 
> > authentication token from up2date server [Thu Nov 21 
> > 11:21:24 2013] up2date 
> > Traceback (most recent call last): 
> >   File "/usr/sbin/rhn_check", line 347, in __run_action 
> >     (status, message, data) = 
> > CheckCli.__do_call(method, params, kwargs) File 
> > "/usr/sbin/rhn_check", line 339, in __do_call method = 
> > getMethod.getMethod(method, "/usr/share/rhn/", 
> > "actions") File 
> > "/usr/share/rhn/up2date_client/getMethod.py", line 79, 
> > in getMethod actions = __import__(modulename) 
> >   File "/usr/share/rhn/actions/packages.py", line 273, 
> > in <module> yum_base = YumAction() 
> >   File "/usr/share/rhn/actions/packages.py", line 64, 
> > in __init__ self.doTsSetup() 
> >   File 
> > "/usr/lib/python2.6/site-packages/yum/depsolve.py", 
> > line 84, in doTsSetup return self._getTs() 
> >   File 
> > "/usr/lib/python2.6/site-packages/yum/depsolve.py", 
> > line 99, in _getTs self._getTsInfo(remove_only) 
> >   File 
> > "/usr/lib/python2.6/site-packages/yum/depsolve.py", 
> > line 110, in _getTsInfo pkgSack = self.pkgSack 
> >   File 
> > "/usr/lib/python2.6/site-packages/yum/__init__.py", 
> > line 887, in <lambda> pkgSack = property(fget=lambda 
> > self: self._getSacks(), File 
> > "/usr/lib/python2.6/site-packages/yum/__init__.py", 
> > line 669, in _getSacks 
> > self.repos.populateSack(which=repos) 
> >   File "/usr/lib/python2.6/site-packages/yum/repos.py", 
> > line 309, in populateSack sack.populate(repo, mdtype, 
> > callback, cacheonly) File 
> > "/usr/lib/python2.6/site-packages/yum/yumRepo.py", line 
> > 165, in populate if self._check_db_version(repo, 
> > mydbtype): File 
> > "/usr/lib/python2.6/site-packages/yum/yumRepo.py", line 
> > 223, in _check_db_version return 
> > repo._check_db_version(mdtype) 
> >   File 
> > "/usr/lib/python2.6/site-packages/yum/yumRepo.py", line 
> > 1256, in _check_db_version repoXML = self.repoXML 
> >   File 
> > "/usr/lib/python2.6/site-packages/yum/yumRepo.py", line 
> > 1455, in <lambda> repoXML = property(fget=lambda self: 
> > self._getRepoXML(), File 
> > "/usr/share/yum-plugins/rhnplugin.py", line 579, in 
> > _getRepoXML return YumRepository._getRepoXML(self) 
> >   File 
> > "/usr/lib/python2.6/site-packages/yum/yumRepo.py", line 
> > 1451, in _getRepoXML raise Errors.RepoError, msg 
> > <class 'yum.Errors.RepoError'>: Cannot retrieve 
> > repository metadata (repomd.xml) for repository: 
> > epel_ol6.4_x86_64. Please verify its path and try again 
> > 
> > [Thu Nov 21 11:39:12 2013] up2date updateLoginInfo() 
> > login info [Thu Nov 21 11:39:12 2013] up2date logging 
> > into up2date server [Thu Nov 21 11:39:12 2013] up2date 
> > successfully retrieved authentication token from 
> > up2date server 
> > 
> > 
> > From the Spacewalk – for this client: 
> > 
> > This action's status is: Failed. 
> > The client picked up this action on 11/21/13 2:17:09 PM 
> > EST. The client completed this action on 11/21/13 
> > 2:17:09 PM EST. Client execution returned "Fatal error 
> > in Python code occurred [[6]]" (code -1) 
> > 
> > 
> > Larry Clegg 
> > HD Supply San Diego GSC 
> > Lead Systems Engineer -Technology & Application 
> > Services Team San Diego, CA 
> > Desk: 858.831.2650  (Cisco ext:  12650) 
> > Cell: 858-880-6578 
> > EMail: Larry.Clegg at HDSupply.com 
> > 
> > _______________________________________________ 
> > Spacewalk-list mailing list 
> > Spacewalk-list at redhat.com 
> > https://www.redhat.com/mailman/listinfo/spacewalk-list 



-- 
This message has been scanned for viruses and 
dangerous content by MailScanner, and is 
believed to be clean. 


_______________________________________________ 
Spacewalk-list mailing list 
Spacewalk-list at redhat.com 
https://www.redhat.com/mailman/listinfo/spacewalk-list 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/spacewalk-list/attachments/20131122/2c2790f4/attachment.htm>


More information about the Spacewalk-list mailing list