Bug 498273 - Package List never gets refreshed
Package List never gets refreshed
Product: Red Hat Satellite 5
Classification: Red Hat
Component: WebUI (Show other bugs)
All Linux
urgent Severity urgent
: ---
: ---
Assigned To: Shannon Hughes
Sayli Karmarkar
: Reopened
Depends On:
Blocks: 456985
  Show dependency treegraph
Reported: 2009-04-29 13:26 EDT by Mike McCune
Modified: 2015-03-22 21:09 EDT (History)
5 users (show)

See Also:
Fixed In Version: sat530
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 496655
Last Closed: 2009-09-10 16:36:10 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Mike McCune 2009-04-29 13:26:24 EDT
+++ This bug was initially created as a clone of Bug #496655 +++

From spacewalk-list:


I have the same problem of package list not refreshed after yum update/rhn_check with my Spacewalk 0.5 (upgraded from 0.4)

I have created three channels in my spacewalk :
* one for RHEL 5.0
* one for RHEL 5.1
* one for RHEL 5.2

I kickstart a RHEL 5.0 and register it with Spacewlak. After, I change its base channel to be the one for RHEL 5.1 and Spacewalk show me a lot of packages that need to be upgraded. That's good. On the host, I do a yum update and everything is fine. But Spacewalk still tells me that a lot of packages need to be upgraded. After doing what Thomas von Steiger explain (playing with child channels), I have got the list refreshed. I have tried rhn-profile-sync without success

I changed again the base channe to the one for RHEL 5.2 and schedule a packages upgrade from Spacewalk webui. The task complete with success but the webui stills show me that some packages need to be upgraded... I have tried rhn-profile-sync without success. If I remove a child channel, the system status becomes "up to date".

That is weird and right now, Spacewalk lost is reporting functionnality

--- Additional comment from santisaez@woop.es on 2009-04-20 12:03:27 EDT ---


I have exactly the same problem after upgrading from 0.4 to 0.5, on a CentOS 5.3 (x86) box:

# rpm -qa spacewalk

When clicking in "Software -> Packages -> Upgrade", I can see the latest version available for the packages but I can't see installed versions (maybe that's the bug?) An example image is available at:


Re-scheduling package upgrade and running rhn_check I get:

Package 1:cups-1.3.7-8.el5_3.4.i386 already installed and latest version
Package 1:cups-libs-1.3.7-8.el5_3.4.i386 already installed and latest version
Package device-mapper-multipath-0.4.7-23.el5_3.4.i386 already installed and latest version
Package kpartx-0.4.7-23.el5_3.4.i386 already installed and latest version
Package libvolume_id-095-14.20.el5_3.i386 already installed and latest version
Package tzdata-2009f-1.el5.noarch already installed and latest version
Package udev-095-14.20.el5_3.i386 already installed and latest version


D: Running Transaction
Adding packages to package profile: []
Removing packages from package profile: []
D: May free Score board((nil))
D: Sending back response (0, 'Update Succeeded', {})
D: do_call packages.checkNeedUpdate ('rhnsd=1',)
D: local action status:  (0, 'rpm database not modified since last update (or package list recently updated)', {})
D: closed   db index       /var/lib/rpm/Providename
D: closed   db index       /var/lib/rpm/Packages
D: closed   db environment /var/lib/rpm/Packages
D: May free Score board((nil))

Package are already installed in the client but status not updated in Spacewalk DB, executing rhn-profile-sync doesn't solve this:

# rhn-profile-sync -vv
updateLoginInfo() login info
D: login(forceUpdate=True) invoked
logging into up2date server
D: writeCachedLogin() invoked
D: Wrote pickled loginInfo at  1240243338.03  with expiration of  1240246938.03  seconds.
successfully retrieved authentication token from up2date server
D: logininfo: {'X-RHN-Server-Id': 1000010283, 'X-RHN-Auth-Server-Time': '1240243335.86', 'X-RHN-Auth': '0IN1FIHdkgEVNDaXB8A0dQ==', 'X-RHN-Auth-Channels': [['centos-5-i386-base', '20090416163225', '1', '1'], ['centos-5-i386-updates', '20090420135604', '0', '1'], ['centos-5-i386-hostalia', '20090406182608', '0', '1']], 'X-RHN-Auth-User-Id': '', 'X-RHN-Auth-Expire-Offset': '3600.0'}
Updating package profile...
Updating package profile
Updating hardware profile...

--- Additional comment from santisaez@woop.es on 2009-04-20 12:11:56 EDT ---

We are following those steps to refresh installed package version:

- Select affected client and enter in "Software -> Software Channels".

- Unselect a child channel (CentOS 5 i386 Updates) and click "Change Subscriptions".

- Enter again in "Software Channels" and re-selected unselect channel (CentOS 5 i386 Updates).

Following this procedure installed package version will be updated, but if we make this operation globally using "System Set Manager" this doesn't work..

--- Additional comment from santisaez@woop.es on 2009-04-27 05:33:00 EDT ---

I have made a very simple Perl script that uses Spacewalk XML-RPC API to unsuscribe and re-suscribe again to all child channels, and help solving this bug.

Script is available at http://fpaste.org/paste/10243
Comment 1 Brandon Perkins 2009-04-30 10:36:23 EDT
Feel free to rope-in whoever you need to get this fixed soon along with the Spacewalk bug.
Comment 2 Shannon Hughes 2009-04-30 14:27:06 EDT
both prad and I tested this on rhel5 and its working on satellite 530.
Comment 3 Mike McCune 2009-04-30 21:14:25 EDT
Were you using channels created from satellite-sync?  If so you are not thinking like a Spacewalk user :)

The bug comes from Spacewalk so it is important to create channels with the GUI and rhnpush rhel5-u1 and rhel5-u2 into separate channels.

I set this up on fjs-0-03.rhndev.redhat.com with 2 custom channels channels:





I kickstarted fjs-0-16 to rhel5-i386-u1 and registered it to my u1 channel:

 rhnreg_ks --force --serverUrl=http://fjs-0-03.rhndev.redhat.com/XMLRPC --activationkey=1-mmccune-rhel5-u1

and the system indicates there are no new packages for it which is expected because it is at the same level as the channel.

I then re-registered the system with a U2 key:

rhnreg_ks --force --serverUrl=http://fjs-0-03.rhndev.redhat.com/XMLRPC --activationkey=1-mmccune-rhel5-u2

The GUI indicates:

Packages: 147

although yum update indicates 299 but I'm guessing that is some discrepancy between the out of date packages and their deps.

on the system details page.  

I ran:  'yum update' from the client and let it finish upgrading the u1 -> u2:

Installed: dhcpv6-client.i386 0:1.0.10-4.el5 kernel.i686 0:2.6.18-92.el5 libhugetlbfs.i386 0:1.2-5.el5
Dependency Installed: device-mapper-event.i386 0:1.02.24-1.el5 gamin.i386 0:0.1.7-8.el5 gamin-python.i386 0:0.1.7-8.el5 hicolor-icon-theme.noarch 0:0.9-2.1 python-iniparse.noarch 0:0.2.3-4.el5
Replaced: dhcpv6_client.i386 0:0.10-33.el5 libhugetlbfs-lib.i386 0:1.0.1-1.el5
[root@fjs-0-16 ~]# 

GUI still shows:


Packages: 147

Upgrade page still shows 147 packages available:

Comment 4 Shannon Hughes 2009-05-06 13:50:03 EDT
bad index reference in backend code, 

--- a/backend/server/rhnServer/server_packages.py

+++ b/backend/server/rhnServer/server_packages.py

@@ -317,8 +317,8 @@ def update_errata_cache(server_id):



     # Delete unneeded packages

-    non_null_errata = filter(lambda x: x[1] is not None, deleted_packages)

-    null_errata = filter(lambda x: x[1] is None, deleted_packages)

+    non_null_errata = filter(lambda x: x[0] is not None, deleted_packages)

+    null_errata = filter(lambda x: x[0] is None, deleted_packages)
Comment 5 Jan-Frode Myklebust 2009-05-07 04:14:54 EDT
Thanks! This seems to have fixed it for us.
Comment 6 Shannon Hughes 2009-05-20 12:02:44 EDT
mass move to onqa
Comment 7 Sayli Karmarkar 2009-06-15 16:54:11 EDT
Comment 8 Steve Salevan 2009-08-03 10:46:05 EDT
RELEASE_PENDING from 7/24 build.
Comment 9 Brandon Perkins 2009-09-10 16:36:10 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


Note You need to log in before you can comment on or make changes to this bug.