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)<br><br>Now I upgraded to 1.1 via <a href="https://fedorahosted.org/spacewalk/wiki/HowToUpgrade">https://fedorahosted.org/spacewalk/wiki/HowToUpgrade</a>. I added repos and channels and my test system from before.<br>

<br>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.<br>

<br>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...<br><br>Tarun<br><br><br><div class="gmail_quote">On Thu, Sep 2, 2010 at 4:02 PM, Tarun Reddy <span dir="ltr"><<a href="mailto:treddy@rallydev.com">treddy@rallydev.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">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.<br>


<br>I'm using a single client Centos system in VMWare to register against one server and then the other to test.<br>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.<br>


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. <br><br>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?<br>

<font color="#888888">
<br>Tarun</font><div><div></div><div class="h5"><br><br><div class="gmail_quote">On Wed, Sep 1, 2010 at 9:48 AM, Tarun Reddy <span dir="ltr"><<a href="mailto:treddy@rallydev.com" target="_blank">treddy@rallydev.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<div>



<br></div><div>My current issue seems to be a situation where for a given package, yum sees the update available, but spacewalk does not.</div><div><br></div><div>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 </div>



<div><br></div><div>yum repolist:</div><div><div>repo id                                                         repo name                                  status</div><div>centos5-base-x86_64                      CentOS 5 Base - x86_64                          enabled: 3,434</div>



<div>centos5-updates-x86_64                  CentOS 5 Updates - x86_64                     enabled:   635</div><div>epel5-x86_64                                 EPEL5 - x86_64                                       enabled: 6,299</div>



<div>rally-repo                                       Rally repo                                                enabled:    25</div><div>spacewalk-client-x86_64                 Spacewalk Client - x86_64                        enabled:    24</div>



<div>repolist: 10,417</div></div><div><br></div><div>When I do a "yum list | grep db4", I get this:</div><div><div>yum list | grep db4</div><div>db4.x86_64                           4.3.29-10.el5        installed             </div>



<div>db4.i386                             4.3.29-10.el5_5.2    centos5-updates-x86_64</div><div><div>db4.x86_64                           4.3.29-10.el5_5.2    centos5-updates-x86_64</div></div><div>db4-devel.i386                       4.3.29-10.el5_5.2    centos5-updates-x86_64</div>



<div>db4-devel.x86_64                     4.3.29-10.el5_5.2    centos5-updates-x86_64</div><div>db4-java.x86_64                      4.3.29-10.el5_5.2    centos5-updates-x86_64</div><div>db4-tcl.x86_64                       4.3.29-10.el5_5.2    centos5-updates-x86_64</div>



<div>db4-utils.x86_64                     4.3.29-10.el5_5.2    centos5-updates-x86_64</div></div><div><br></div><div>Good! I see that I have an updates.</div><div><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></div>



<br>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.<div><br></div><div><b>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.</b></div>



<div><b><br></b></div><div><b><span style="font-weight:normal">So for example, for the device-mapper suite of rpms (device-mapper, device-mapper-event, device-mapper-multipath), a yum list shows this:</span></b></div>
<div><b><span style="font-weight:normal"><br></span></b></div><div><b><span style="font-weight:normal"><div>device-mapper.x86_64                 1.02.39-1.el5        installed             </div>
<div>device-mapper-event.x86_64           1.02.39-1.el5        installed             </div><div>device-mapper-multipath.x86_64       0.4.7-34.el5         installed             </div><div>device-mapper.i386                   1.02.39-1.el5_5.2    centos5-updates-x86_64</div>


<div>
<div>device-mapper.x86_64                 1.02.39-1.el5_5.2    centos5-updates-x86_64</div></div><div><div>device-mapper-event.x86_64           1.02.39-1.el5_5.2    centos5-updates-x86_64</div></div><div>
<div>device-mapper-multipath.x86_64       0.4.7-34.el5_5.4     centos5-updates-x86_64</div>
<div><br></div></div><div>Spacewalks' UI shows only device-mapper-event and <b><span style="font-weight:normal"><div style="display:inline !important">device-mapper-multipath are available for updates. It feels like a bit of relief that I found the pattern... but now what?</div>



</span></b></div></span></b></div><div><div><br></div><div>Any ideas?</div><div><br></div><div>Tarun</div><div><br></div><div><br></div><div>BTW, I'm syncing my repo using the sync_repo.py from <a href="https://fedorahosted.org/spacewalk/wiki/UploadFedoraContent" target="_blank">https://fedorahosted.org/spacewalk/wiki/UploadFedoraContent</a>. I do this daily and it seems to be working great.</div>



<div><br></div><div><br></div></div>
</blockquote></div><br>
</div></div></blockquote></div><br>