[Spacewalk-list] Remote Upgrade / Install Broken since Update to 1.3

[Mathieu Chouquet-Stringer]

Hello,

Since I've upgraded my spacewalk server and clients to 1.3, remote install /
upgrade through the web UI doesn't work anymore.

My client (running centos) sees all the channel (yum repolist works, yum
install/upgrade too) but any attempt to schedule the upgrade through the UI
fails.

When I run rhn_check in verbose mode, I can see spacewalk sends the correct
list of packages that needs to be updated but yum doesn't find them.

Namely, this piece of code in actions/packages.py is being triggered even
though the package exists:
            if not len(yum_base.tsInfo) > oldcount:
                log.log_debug('MATHIEU THERE #25 empty transaction')

<spacewalk-list at redhat.com>For instance, if I ask satellite to install
package 389-admin-1.1.14-1.el5.

Doing a yum info 389-admin-1.1.14-1.el5 yields something correct:
Available Packages
Name       : 389-admin
Arch       : i386
Version    : 1.1.14
Release    : 1.el5
Size       : 403 k
Repo       : centos-5-os-x86_64
Summary    : 389 Administration Server (admin)
License    : GPLv2 and ASL 2.0
Description: 389 Administration Server is an HTTP agent that provides
management features
           : for 389 Directory Server.  It provides some management web apps
that can
           : be used through a web browser.  It provides the authentication,
access control,
           : and CGI utilities used by the console.

Name       : 389-admin
Arch       : x86_64
Version    : 1.1.14
Release    : 1.el5
Size       : 410 k
Repo       : centos-5-os-x86_64
Summary    : 389 Administration Server (admin)
License    : GPLv2 and ASL 2.0
Description: 389 Administration Server is an HTTP agent that provides
management features
           : for 389 Directory Server.  It provides some management web apps
that can
           : be used through a web browser.  It provides the authentication,
access control,
           : and CGI utilities used by the console.


And I can obviously install it using yum at the command line.

That said through rhn_check, I get this:
D: Called update [['389-admin', '1.1.14', '1.el5', '', 'x86_64']]
D: opening  db environment /var/lib/rpm/Packages joinenv
D: opening  db index       /var/lib/rpm/Packages rdonly mode=0x0
D: opening  db index       /var/lib/rpm/Name rdonly mode=0x0
D: May free Score board((nil))
D: closed   db index       /var/lib/rpm/Name
D: closed   db index       /var/lib/rpm/Packages
D: closed   db environment /var/lib/rpm/Packages
D: May free Score board((nil))
D: Sending back response (32, 'Failed: Packages failed to install properly:
No package(s) available to install', {'version': '1', 'name':
'package_install_failure'})
D: do_call packages.checkNeedUpdate ('rhnsd=1',) {}
D: local action status:  (0, 'rpm database not modified since last update
(or package list recently updated)', {})
D: rpcServer: Calling XMLRPC registration.welcome_message
D: closed   db index       /var/lib/rpm/Providename
D: closed   db index       /var/lib/rpm/Packages
D: closed   db environment /var/lib/rpm/Packages
D: May free Score board((nil))

For an upgrade I get this:
D: May free Score board((nil))
D: Sending back response ((6,), 'Error while executing packages action:
empty transaction', {})
D: do_call packages.checkNeedUpdate ('rhnsd=1',) {}
D: local action status:  (0, 'rpm database not modified since last update
(or package list recently updated)', {})
D: rpcServer: Calling XMLRPC registration.welcome_message
D: closed   db index       /var/lib/rpm/Name
D: closed   db index       /var/lib/rpm/Packages
D: closed   db environment /var/lib/rpm/Packages
D: May free Score board((nil))
D: closed   db index       /var/lib/rpm/Providename
D: closed   db index       /var/lib/rpm/Packages
D: closed   db environment /var/lib/rpm/Packages
D: May free Score board((nil))

I've added code to debug this thing and it looks like in
add_transaction_data, the call to self.install doesn't return anything
useful...

I ended up checking yum (def install(self, po=None, **kwargs) and basically
for all my upgrades, this test is true:
if not pkgs:
            # Do we still want to return errors here?
            # We don't in the cases below, so I didn't here...

Any clue what I should try next?

Thanks.

-- 
Mathieu Chouquet-Stringer                         mathieucs at gmail.com
            The sun itself sees not till heaven clears.
                     -- William Shakespeare --
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/spacewalk-list/attachments/20110211/3509b126/attachment.htm>