[Spacewalk-list] Disconnect between yum update and spacewalk UI
Tarun Reddy
treddy at rallydev.com
Fri Sep 3 00:20:17 UTC 2010
LOL... I rebuilt my production spacewalk. Started with 1.0 rpms and built it
and configured oracle but did not create channels. (Took a snapshot here)
Now I upgraded to 1.1 via
https://fedorahosted.org/spacewalk/wiki/HowToUpgrade. I added repos and
channels and my test system from before.
I haven't finished sync'ing yet, but already with centos5-updates-x86_64
partially synced, I can tell the bug is gone. All updates, including ones
where multiple architectures are available, now show in the spacewalk gui. I
don't know why, but I can't believe no one is seeing this, unless no one has
done a fresh install from Spacewalk 1.1.
In any case, I'm going to keep my system as is for now. I would be happy to
help a spacewalk developer if need be...
Tarun
On Thu, Sep 2, 2010 at 4:02 PM, Tarun Reddy <treddy at rallydev.com> wrote:
> 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/5cbc6b97/attachment.htm>
More information about the Spacewalk-list
mailing list