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 <[email protected]> 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 <[email protected]> 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. >> >> >> >
_______________________________________________ Spacewalk-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/spacewalk-list
