Bug 498273 - Package List never gets refreshed
Package List never gets refreshed
Status: CLOSED CURRENTRELEASE
Product: Red Hat Satellite 5
Classification: Red Hat
Component: WebUI (Show other bugs)
530
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
Environment:
Last Closed: 2009-09-10 16:36:10 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
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:

http://www.redhat.com/archives/spacewalk-list/2009-April/msg00183.html

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


Hi!

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

# rpm -qa spacewalk
spacewalk-0.5.4-1.el5

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:

http://filesocial.com/262h9

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:

mmccune-rhel5-u1:

https://fjs-0-03.rhndev.redhat.com/rhn/channels/ChannelDetail.do?cid=141

mmccune-rhel5-u2 

https://fjs-0-03.rhndev.redhat.com/rhn/channels/ChannelDetail.do?cid=142

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
[...snip...]
Replaced: dhcpv6_client.i386 0:0.10-33.el5 libhugetlbfs-lib.i386 0:1.0.1-1.el5
Complete!
[root@fjs-0-16 ~]# 

GUI still shows:

https://fjs-0-03.rhndev.redhat.com/rhn/systems/details/Overview.do?sid=1000010060

Packages: 147

Upgrade page still shows 147 packages available:

https://fjs-0-03.rhndev.redhat.com/rhn/systems/details/packages/UpgradableList.do?sid=1000010060
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
verified.
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.

http://rhn.redhat.com/errata/RHEA-2009-1434.html

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