[Spacewalk-list] Disconnect between yum update and spacewalk UI

Tarun Reddy treddy at rallydev.com
Thu Sep 2 22:02:06 UTC 2010


Sigh.. it gets stranger. I actually have two spacewalk servers. One for our
internal IT systems, was a spacewalk 1.0 system that I used
spacewalk-schema-upgrade to upgrade to 1.1. The other is a new one for our
production network. That one was built with spacewalk 1.1 from the ground
up.

I'm using a single client Centos system in VMWare to register against one
server and then the other to test.
The 1.0->1.1 spacewalk servers works perfectly with all rpms showing up in
the web gui, including RPMS that have multiple architectures in the
repository.
The 1.1 "native" system always shows this bug where any RPM that is
represented by i386 and x86_64 versions in the repo are absent from the
spacewalk gui, but still available in the yum update.

I've rebuilt the 1.1 "native" system 3 times and always have the same issue.
I'm actually seriously considering rebuilding with 1.0 and then upgrading to
see if this fixes the issue, but I'm wondering if I should do some sort of
database schema compare first?

Tarun

On Wed, Sep 1, 2010 at 9:48 AM, Tarun Reddy <treddy at rallydev.com> wrote:

> Sorry for the confusion.. I'm going to start over, fresh and clean since
> apparently on occasion I keep running into my same old issues. Specifically,
> when spacewalk has more packages available than yum, cleaning
> /var/cache/rhn/repodata/* fixes that issue.
>
> My current issue seems to be a situation where for a given package, yum
> sees the update available, but spacewalk does not.
>
> I have a server that has db4-4.3.29-10.el5.x86_64 installed. It is
> registered with spacewalk, and /etc/yum.repos.d is completely empty. I've
> yum clean all so
>
> yum repolist:
> repo id                                                         repo name
>                                status
> centos5-base-x86_64                      CentOS 5 Base - x86_64
>              enabled: 3,434
> centos5-updates-x86_64                  CentOS 5 Updates - x86_64
>           enabled:   635
> epel5-x86_64                                 EPEL5 - x86_64
>                       enabled: 6,299
> rally-repo                                       Rally repo
>                                enabled:    25
> spacewalk-client-x86_64                 Spacewalk Client - x86_64
>              enabled:    24
> repolist: 10,417
>
> When I do a "yum list | grep db4", I get this:
> yum list | grep db4
> db4.x86_64                           4.3.29-10.el5        installed
>
> db4.i386                             4.3.29-10.el5_5.2
>  centos5-updates-x86_64
> db4.x86_64                           4.3.29-10.el5_5.2
>  centos5-updates-x86_64
> db4-devel.i386                       4.3.29-10.el5_5.2
>  centos5-updates-x86_64
> db4-devel.x86_64                     4.3.29-10.el5_5.2
>  centos5-updates-x86_64
> db4-java.x86_64                      4.3.29-10.el5_5.2
>  centos5-updates-x86_64
> db4-tcl.x86_64                       4.3.29-10.el5_5.2
>  centos5-updates-x86_64
> db4-utils.x86_64                     4.3.29-10.el5_5.2
>  centos5-updates-x86_64
>
> Good! I see that I have an updates.
> <strike>Now going to spacewalk, the weirdness shows up. Going to
> the db4-4.3.29-10.el5.x86_64.rpm package page, and clicking on "New
> Versions" shows "No other versions". Even though yum finds the newer version
> in the spacewalk repo, spacewalk doesn't.</strike>
>
> Ignore that last sentence. db4-4.3.29-10.el5_5.2.x86_64 is in the spacewalk
> repo as part of the centos5-update-x86_64 repo.
>
> *So that shows me the bug. All of the packages that show up in the
> Spacewalk UI are only available in x86_64. The missing packages have i386 or
> noarch version available in yum. Even though those i386 versions aren't
> installed on the target server, the availability of them is preventing the
> spacewalk UI from showing them as available updates.*
> *
> *
> *So for example, for the device-mapper suite of rpms
> (device-mapper, device-mapper-event, device-mapper-multipath), a yum list
> shows this:*
> *
> *
> *
> device-mapper.x86_64                 1.02.39-1.el5        installed
>
> device-mapper-event.x86_64           1.02.39-1.el5        installed
>
> device-mapper-multipath.x86_64       0.4.7-34.el5         installed
>
> device-mapper.i386                   1.02.39-1.el5_5.2
>  centos5-updates-x86_64
>  device-mapper.x86_64                 1.02.39-1.el5_5.2
>  centos5-updates-x86_64
> device-mapper-event.x86_64           1.02.39-1.el5_5.2
>  centos5-updates-x86_64
> device-mapper-multipath.x86_64       0.4.7-34.el5_5.4
> centos5-updates-x86_64
>
> Spacewalks' UI shows only device-mapper-event and
> device-mapper-multipath are available for updates. It feels like a bit of
> relief that I found the pattern... but now what?
> *
>
> Any ideas?
>
> Tarun
>
>
> BTW, I'm syncing my repo using the sync_repo.py from
> https://fedorahosted.org/spacewalk/wiki/UploadFedoraContent. I do this
> daily and it seems to be working great.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/spacewalk-list/attachments/20100902/6d0c4bb7/attachment.htm>


More information about the Spacewalk-list mailing list