[Spacewalk-list] Issues upgrading to next point release

[Jan Pazdziora]

On Fri, Aug 03, 2012 at 07:59:46AM +0000, Ree, Jan-Albert van wrote:
> I have a Spacewalk server with around 20 clients running for about 6 month now.
> I use Scientific Linux 6 both for the spacewalk server and all clients. A repository have been set up to fetch updates from http://ftp.halifax.rwth-aachen.de/scientificlinux/6x/x86_64/updates/security/
> 
> Now my base image is based on SL 6.2 and so far all updates have gone just fine.
> However now that updates tagged with 6.3 are coming out my Spacewalk server shows these updates as being available, but I am unable to apply them to my clients. If I do a 'yum clean all ; yum upgrade' I get '0 updates available'
> 

What happens if you schedule the update from Spacewalk's WebUI and
pick it up with rhn_check -vv -- will it get installed?

> After playing with this, I discovered that if I manually upgrade the sl-release RPM and then re-register the machine, it will pick up the updates, but surely that's not how this is supposed to work. If I don't re-register the machine after manually updating I get a lot of RHN errors, since fields in the /etc/sysconfig/rhn/systemid file no longer match.
> 
> Did I miss something? Thanks in advance,

In general, for yum operations to work, yum needs something called
repo data -- overall description of the channel (repo) plus what
packages to expect in that channel. 

Spacewalk generates the repo data for the channels after any change
in the channel takes place, via an asynchronous job. The Last Repo
Build field in the channel page on the WebUI shows the timestamp of
the last repo generation, so you might want to check if it was updated
alright. I assume it was, otherwise your newly registered machine
wouldn't get them either, but we should know for sure.

I have no idea what the sl-release package contains or overwrites,
so I won't speculate on this one. Does the package own the
/etc/sysconfig/rhn/systemid file? What does rpm -qf
/etc/sysconfig/rhn/systemid?

Aren't some proxies between the clients and the Spacewalk server that
could be source of the problem?

-- 
Jan Pazdziora
Principal Software Engineer, Satellite Engineering, Red Hat