If you tried the update right after the packages became available in the
repos (lets say you ran a manual spacewalk-repo-sync before or something
like that) this is normal, in my experience it takes around 15 minutes
to actually update the repo metadata on the machine ... so spacewalk has
the new packages, but the clients don't have that information yet (even
though they already show it in the webinterface). I already discussed on
irc that an update package or install package action should trigger an
'yum clean all' before the action takes place, thus ensuring the repo
metadata on the client machine is getting updated before it actually
tries the install/update ...
Furthermore of note in the same category actually:
if you try an update of a package and the package is not available yet
as metadata the scheduled update will show succes in stead of failed,
because it sees it has the latest version and cosiders this a succes
even though it did not update anything and the version is not the one
reported in the webinterface yet. (some better checking should be
applied here)
I encountered most of these things because I maintain a custom repo on
spacewalk with 'homebuilt' packages which got pushed manually seconds
before I tried to install / update them ...
Perhaps this info is a bit outdated, I still run SW 0.7 right now but I
don't think this got fixed in 0.8
Regards,
George
Michiel van Es wrote:
Strange thing is, if I schedule the machines one by one: the updates
work ?!
-------- Original Message --------
Subject: Re: [Spacewalk-list] error with centos 5 clients
From: Colin Coe <[email protected]>
To: [email protected] <[email protected]>
Date: 03/16/2010 05:42 AM
I could be reading this wrong but this is what the spacewalk servers
sees, not the client.
If you do a 'yum list "packagename"' on the client (where
"packagename" is one of those packages not found) what is the result.
CC
On Tue, Mar 16, 2010 at 12:26 PM, Michiel van
Es<[email protected]> wrote:
Hi,
When I try to install a scheduled update I get the following error:
Summary: Package Install scheduled by admin
Details: This action will be executed after 03/16/10 5:19:51
AM CET.
This action's status is: Failed.
The client picked up this action on 03/16/10 5:20:00 AM CET.
The client completed this action on 03/16/10 5:20:02 AM CET.
Client execution returned "Failed: Packages failed to install
properly: No
package(s) available to install" (code 32)
Packages Scheduled:
xulrunner-devel-1.9.0.18-1.el5_4
libXi-1.0.1-4.el5_4
mysql-5.1.44-1.el5.remi
mysql-libs-5.1.44-1.el5.remi
openoffice.org-langpack-pt_PT-2.3.0-6.11.el5_4.4:1
mysql-server-5.0.84-2.el5.centos
mysql-devel-5.0.77-4.el5_4.2
yum-3.2.22-20.el5.centos
NetworkManager-0.7.0-9.el5_4:1
sudo-1.6.9p17-6.el5_4
xulrunner-1.9.0.18-1.el5_4
php-cli-5.3.2-1.el5.remi
php-mysql-5.3.2-1.el5.remi
php-mbstring-5.3.2-1.el5.remi
php-pdo-5.3.2-1.el5.remi
coreutils-5.97-23.el5_4.2
php-5.3.2-1.el5.remi
openssh-server-4.3p2-36.el5_4.4
NetworkManager-glib-0.7.0-9.el5_4:1
php-ldap-5.3.2-1.el5.remi
openoffice.org-langpack-tn_ZA-2.3.0-6.11.el5_4.4:1
firefox-3.0.18-1.el5.centos
openssh-clients-4.3p2-36.el5_4.4
xulrunner-devel-unstable-1.9.0.18-1.el5_4
openoffice.org-core-2.3.0-6.11.el5_4.4:1
openssh-4.3p2-36.el5_4.4
proftpd-1.3.2b-1.el5
php-gd-5.3.2-1.el5.remi
php-common-5.3.2-1.el5.remi
libXi-devel-1.0.1-4.el5_4
libgtop2-2.14.4-8.el5_4
It happens on ALL my CentOS 5 machines.
DOes anyone know why this happens?
As you can see it see's some scheduled updates but fails to install them
with the message: No package(s) available to install" (code 32)
Sounds like a contradiction to me :)
--
Regards,
Michiel
_______________________________________________
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
_______________________________________________
Spacewalk-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/spacewalk-list
