Bug 524826 - System->Software->Verify - package verification fails on multiarch clients
Summary: System->Software->Verify - package verification fails on multiarch clients
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Network
Classification: Retired
Component: RHN/Backend
Version: rhn602
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Sebastian Skracic
QA Contact: Nicole Yancey
URL:
Whiteboard: US 16206
Depends On: 456539
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-09-22 11:42 UTC by Vishal Gaikwad
Modified: 2018-11-28 21:52 UTC (History)
11 users (show)

Fixed In Version:
Clone Of: 456539
Environment:
Last Closed: 2012-02-20 09:13:30 UTC
Embargoed:


Attachments (Terms of Use)

Description Vishal Gaikwad 2009-09-22 11:42:28 UTC
+++ This bug was initially created as a clone of Bug #456539 +++

Description of problem:

When scheduling a package verification from Spacewalk on a client that has
modified files belonging to 2 packages with same NEVR but different
architectures, the scheduled verification action never completes and each
attempt generates an Internal Server Error.

How reproducible:
Always

Steps to Reproduce:
1. Populate an x86_64 channel on Spacewalk 
2. Install/register a client system using that channel
3. Identify a package on the client that:
- has i386 and x86_64 versions
- has a modified file
(nss should match these requirements on a default install)
4. On Spacewalk, select the client system and go to Software->Packages->Verify
5. Select both versions of the package identified in step 3 and click on 'Verify
Selected Packages', then Confirm
6. Run rhn_check -vvv on the client

Actual results:

The verify action never completes and each attempt generates an Internal Server
Error.

The traceback email associated with the ISE reveals a problem on the database:

'ORA-00001: unique constraint (RHNSAT.RHN_SACTIONVR_SANEC_UQ) violated\\n'

The problem appears to be that this unique index (RHN_SACTIONVR_SANEC_UQ) does
not include the package's architecture in its definition for uniqueness.

Expected results:
Package verifications succeed.  Spacewalk should handle multi-arch (same package
NEVR and different architecture).

Additional info:

--- Additional comment from bbuckingham on 2008-11-04 09:28:32 EDT ---

Git commit: 24cdb841e3ac11667040de3c4d4ce3a68e5217f7

Added package_arch_id to the index for rhnServerActionVerifyMissing and rhnServerActionVerifyResult.  Verified that user could then perform package verification of 2 pkgs with same nevr but differing arch.

Scenario:

1. register rhel4 x86_64 client
2. up2date --arch=i386 nss_ldap

observe:[root@dhcp77-134 rpm]# rpm -qa --queryformat="%{NAME}.%{ARCH}\\n" |grep nss_ldap
nss_ldap.x86_64
nss_ldap.i386

[root@dhcp77-134 rpm]# rpm -qa |grep nss_ldap
nss_ldap-253-5.el4
nss_ldap-253-5.el4

3. perform: Software-Packages->Verify: schedule package verification for nss_ldap i386 & x86_64

4. rhn_check -vvv

No tracebacks or errors reported to /var/log/httpd/error_log

--- Additional comment from bbuckingham on 2009-01-15 12:36:23 EDT ---

verified with spacewalk-java-0.4.14-1.el5, spacewalk-schema-0.4.15-1.el5

Comment 10 Sebastian Skracic 2012-02-01 14:00:48 UTC
Steps to reproduce and verify the fix:

From the machine itself:

1. register a RHEL5 x86_64 machine against RHN.
2. # yum install firefox
3. # rpm -q --queryformat="%{NAME}.%{ARCH}\\n" firefox
   should list both archs RPMs installed:
firefox.i386
firefox.x86_64
4. rename a file common to these packages:
   # mv /usr/share/man/man1/firefox.1.gz /usr/share/man/man1/firefox.1.gz.bak
5. from the box, verify that the same file has been reported as missing from both RPMs:
   #  rpm --verify firefox
missing   d /usr/share/man/man1/firefox.1.gz
missing   d /usr/share/man/man1/firefox.1.gz

From the RHN Web UI:

6. Locate that system in RHN Web UI, and go to System->Software->Packages->Verify
7. From the resulting table, select firefox RPMs (you can use Filter by to speed the process up), and click on 'Verify Selected' followed by 'Confirm'.

Now, you can either wait, or:

8. from the machine, issue: "rhn_check"
You should receive the 'Internal Server Error' reply.

Comment 14 Nicole Yancey 2012-02-08 19:14:21 UTC
Link to case - https://tcms.engineering.redhat.com/case/134776/?from_plan=5268

verified in https://rhn.qa.redhat.com


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