[Spacewalk-list] Scheduled update fails

[Alan Pittman]

Jeremy wrote:

  1.  The yum cache on the client side hasn't been refreshed yet so it's using old data when trying to do the updates. You should be able to fix this by running "yum clean all" on the client and trying the update again (or yum check-update on the client)
Personally,
       I have found that sometimes, yum clean all, isn't enough. I've also had to delete the /var/cache/yum sub-directory, then run yum makecache.

Alan


From: spacewalk-list-bounces at redhat.com [mailto:spacewalk-list-bounces at redhat.com] On Behalf Of Jeremy Maes
Sent: Thursday, January 31, 2013 8:21 AM
To: spacewalk-list at redhat.com
Subject: Re: [Spacewalk-list] Scheduled update fails

Op 30/01/2013 16:39, Pietro Leone Pola Falletti di Villafalletto schreef:
Hallo, I have other info, I installed another server and spacewalk tells me that there are some packages to update:

tzdata-2012j-1.el6.noarch     tzdata-2012i-2.el6.noarch

xorg-x11-server-common-1.10.6-1.0.1.el6.centos.x86_64     xorg-x11-server-common-1.10.6-1.el6.centos.x86_64

xorg-x11-server-Xorg-1.10.6-1.0.1.el6.centos.x86_64     xorg-x11-server-Xorg-1.10.6-1.el6.centos.x86_64

xulrunner-10.0.12-1.el6.centos.x86_64     xulrunner-10.0.11-1.el6.centos.x86_64

But yum on the server sees one package only:

yum check-update
Loaded plugins: fastestmirror, rhnplugin, security
This system is receiving updates from RHN Classic or RHN Satellite.
Loading mirror speeds from cached hostfile

xulrunner.x86_64           10.0.12-1.el6.centos                           centos6-x86_64

Any idea?

Thanks, Pietro.
There's two possible causes I think:

  1.  The yum cache on the client side hasn't been refreshed yet so it's using old data when trying to do the updates. You should be avble to fix this by running "yum clean all" on the client and trying the update again (or yum check-update on the client)
  2.  The repository cache on the spacewalk server side hasn't been rebuilt. Normally this gets rebuilt automatically after a little time (usually max 1 min), and is triggered by the taskomatic deamon. You can check the last repo change and rebuild dates in the webinterface by going to Channels > Software Channels > channelname you want and looking at the "Last Modified" and "Last Repo Build" times. They should be fairly close to each other.

If they haven't been rebuilt chances are the taskomatic daemon has crashed due to a bug and needs a restart.

Regards,
Jeremy
On 01/30/2013 09:23 AM, Pietro Leone Pola Falletti di Villafalletto wrote:

Hallo, any idea? I found an old bug, but the solution does not work.

Thanks, Pietro.

On 01/29/2013 05:44 PM, Pietro Leone Pola Falletti di Villafalletto wrote:

Hallo, I see several systems that need update, but when I schedule an
update it fails with this error:

Error while executing packages action: empty transaction [[6]]

On the servers yum does not find any update needed, spacewalk see three
packages.

Any idea?

Thanks, Pietro.


**** DISCLAIMER ****
http://www.schaubroeck.be/maildisclaimer.htm
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/spacewalk-list/attachments/20130131/76ce6867/attachment.htm>