Bug 568958

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