Description of problem: After an upgrade to Satellite 5.3, it was noticed that System Set Manager (SSM) can no longer remove or verify packages from existing systems - the pkg listing is empty even though there're clearly packages installed. Upon further investigation it seems that system profiles (not including newly provisioned systems) doesn't list architecture under it's software profile - System Details -> Software -> installed packages shows "not specified" under architecture column. A customer reported this affects their RHEL 2.1 and 3 client systems while RHEL 5 ones are fine. Internally confirmed for RHEL 3 systems, and RHEL 4 system profiles are affected too. Version-Release number of selected component (if applicable): Red Hat Network (RHN) Satellite 5.3.0 How reproducible: Always. Steps to Reproduce: 1. Install Satellite 5.2 2. Install and register a client - RHEL 2.1, 3, 4, 5 respectively for comparison. 3. Click on system profile -> 'Software' -> 'List/Remove' -> Observe 'Architecture' column, observe values like x86_64, i386 or noarch. 4. Select each of these system profiles for SSM and go to SSM Remove and Verify systems pages - observe that packages should show up. 5. Upgrade to satellite 5.3. 6. Repeat steps 3 and 4. 7. (Additional tests) Compare between the 2.1, 3, 4, 5 systems. Re-register the system profiles. Re-point them to 5.2 satellite then compare. Actual results: Architecture is 'not specified' for step 3, and pkg list is empty for SSM -> remove packages and SSM -> verify packages Expected results: Architecture should be specified like previous versions, and SSM -> remove packages and SSM -> verify should show non-empty, correct list of pkgs for each system. Additional info:
Running the following sub-query, substituting the user_id, and set_label ('system_list') confirmed that rhnServerPackage.package_arch_id is null for affected systems on Satellite 5.3.0 - SELECT SP.name_id, SP.evr_id, SP.package_arch_id, COUNT (SP.server_id) num_systems FROM rhnServerPackage SP, rhnSet S WHERE s.user_id = :user_id AND s.label = :set_label AND s.ELEMENT = SP.server_id GROUP BY SP.name_id, SP.evr_id, SP.package_arch_id (this is a sub-query of the following query which is used by the SSM for building pkg list for removal/verification - spacewalk-java-0.5.44/code/src/com/redhat/rhn/common/db/datasource/xml/Package_queries.xml ... <mode name="packages_from_server_set" class="com.redhat.rhn.frontend.dto.SsmRemovePackageListItem"> <query params="user_id, set_label"> SELECT PN.ID || '|' || PE.ID || '|' || PA.ID AS id_combo, PN.name || '-' || PE.evr.as_vre_simple() || '.' || PA.label nvre, PA.label AS arch, X.num_systems AS num_systems FROM rhnPackageName PN, rhnPackageEVR PE, rhnPackageArch PA, (SELECT SP.name_id, SP.evr_id, SP.package_arch_id, COUNT (SP.server_id) num_systems FROM rhnServerPackage SP, rhnSet S WHERE s.user_id = :user_id AND s.label = :set_label AND s.ELEMENT = SP.server_id GROUP BY SP.name_id, SP.evr_id, SP.package_arch_id) X WHERE PE.ID = X.evr_id AND PN.ID = X.name_id AND PA.ID = X.package_arch_id ORDER BY UPPER (PN.NAME) </query> </mode> ...)
(In reply to comment #0) > A customer reported this affects their RHEL 2.1 and 3 client systems while RHEL > 5 ones are fine. Internally confirmed for RHEL 3 systems, and RHEL 4 system > profiles are affected too. > Correction: *some* RHEL 4 systems are affected. So until root cause is found (whether the bug is in schema, upgrade code, registration code or elsewhere), it's hard to say whether it's the RHEL version that makes a difference or time of registration (before or after upgrade).
Per discussion with engineering (thanks Justin & also Prad), it looks like this is due to an old bug w/r/t rhn client not sending package architecture information during updates, which was fixed in RHEL 4.8 and RHEL 5. This means that during initial registration, package arch info is sent to the Satellite and populated, however a profile refresh (such as "up2date -p" or installing pkgs via activation keys) will refresh package information minus the architecture, resulting in null package_arch_ids. Workaround for older client systems (i.e., before RHEL 4.8 and RHEL 5) that are impacted by this bug: Re-register system, but do not use any activation keys to install packages, or schedule a package/profile refresh. Setting this NEEDINFO on myself since once we confirm this is all there is to the problem then this BZ needs to be closed.
After further discussion w/ Cliff & Justin, the proposed fix for this bug is to change the SSM query on Satellite side so that it can proceed to remove/verify pkgs even for older client systems (pre RHEL 4.8 and 5) that are missing pkg arch info.
fixed in spacewalk master: 0e3bb3c8b4ab01d7a5221708f1c822e10514bc2f
Checked the Satellite 5.2 to 5.3 upgrade scenario in https://bugzilla.redhat.com/show_bug.cgi?id=568958#c0 against Satellites on RHEL4 (i386, x86_64) and RHEL5 (i386, x86_64) platforms with RHEL 3, 4, 5. updated packages fixing the problem: python-cheetah-2.0.1-1 cobbler-1.6.6-5 spacewalk-backend-0.5.28-40.x.2 spacewalk-web-0.5.23-34 spacewalk-java-0.5.44-75
# VERIFIED Checked the Satellite 5.2 to 5.3 upgrade scenario against Satellites on RHEL4 and RHEL5 s390x platform with RHEL 3, 4, 5 client. updated packages fixing the problem: python-cheetah-2.0.1-1 cobbler-1.6.6-5 spacewalk-backend-0.5.28-40.x.2 spacewalk-web-0.5.23-34 spacewalk-java-0.5.44-75
Description for upgrade scenario for: https://bugzilla.redhat.com/show_bug.cgi?id=568958#c10 https://bugzilla.redhat.com/show_bug.cgi?id=568958#c11 I installed Satellites 5.2 on RHEL4 (i386, x86_64, s390x) and RHEL5 (i386, x86_64, s390x). Synced channels rhel-i386-as-3 rhel-i386-as-4 rhel-i386-server-5 and connected clients RHEL3-U9, RHEL4-U8, RHEL5-Client-U4. I clicked on system profile -> 'Software' -> 'List/Remove' -> Observe 'Architecture' column, observe values i386 or noarch. I selected each of these system profiles for SSM and go to SSM Remove and Verify systems pages - observe that packages should show up. Then I installed rhn-upgrade package and upgraded from Sat 5.2 to 5.3. The repeated 2 previous steps. I re-registered the clients and checked if everything is in place.
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/RHBA-2010-0369.html