Bug 488157 - sparcv9 architecture not supported in solaris2mpm & satellite
sparcv9 architecture not supported in solaris2mpm & satellite
Product: Red Hat Satellite 5
Classification: Red Hat
Component: Solaris (Show other bugs)
x86_64 Linux
high Severity medium
: ---
: ---
Assigned To: Jan Pazdziora
Steve Salevan
Depends On:
Blocks: 457000
  Show dependency treegraph
Reported: 2009-03-02 17:13 EST by Erich Morisse
Modified: 2010-10-23 04:03 EDT (History)
4 users (show)

See Also:
Fixed In Version: sat530
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-09-10 15:41:06 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 Erich Morisse 2009-03-02 17:13:31 EST
Description of problem:

Creating an mpm of architecture type sparcv9 fails.  
Fudging it to work by adding sparcv9 to solaris2mpm.py lets the MPM get created, but the Sat does not like the upload (traceback below).  Changing the architecture within the package to sparc gets everything working fine...

Version-Release number of selected component (if applicable):
RHN Satellite 5.2 on RHEL 5

Additional info:

Solaris2mpm program seems to take client architecture from README files
within each patch directory, specifically from the lines which say:

Relevant Architectures: <arch>

Then within solaris2mpm.py there's a _normalize_arch(arch) function
which performs the following assertion (line 952):

if __debug__: assert arch in ("i386", "sparc", "noarch"), "Unknown arch
%s" % arch

Apparently, sometimes the "Relevant Architecture" line in the README
file may have "sparcv9" as a value, and it breaks the above assertion.

Simply adding "sparcv9" to the list in parenthesis does not completely
fix the problem: solaris2mpm then works fine, but when the resulting
mpms are pushed to the satellite server, the satellite server breaks
like this:

(very long traceback of satellite-side error)

Exception reported from maximus.bnysecurities.corp.local
Time: Mon Mar  2 15:01:49 2009
Exception type server.importlib.importLib.InvalidArchError
Exception while handling function upload_server._wrapper Request object
Remote Host:
Server Name: maximus.bnysecurities.corp.local:0
Headers passed in:
        Accept-Encoding: identity
        Content-Length: 10563512
        Content-Type: application/x-rpm
        Host: maximus.bnysecurities.corp.local
        User-Agent: rhnpush
        X-RHN-Upload-Auth-Session: 87x9c98710bf09a35de2903bb1cda6dd562
        X-RHN-Upload-File-MD5sum: cb65ed82d65835692bb16f7540a029dc
        X-RHN-Upload-Force: 0
        X-RHN-Upload-Package-Arch: sparcv9-solaris-patch
        X-RHN-Upload-Package-Name: patch-solaris-118667
        X-RHN-Upload-Package-Release: 1
        X-RHN-Upload-Package-Version: 18
        X-RHN-Upload-Packaging: mpm

Exception Handler Information
Traceback (most recent call last):
  File "/usr/share/rhn/server/apacheUploadServer.py", line 97, in
    ret = function(req)
line 133, in handler
    relative_path=self.rel_package_path, org_id=self.org_id)
  File "/usr/share/rhn/server/rhnPackageUpload.py", line 219, in
  File "/usr/share/rhn/server/importlib/importLib.py", line 616, in run
  File "/usr/share/rhn/server/importlib/packageImport.py", line 264, in
  File "/usr/share/rhn/server/importlib/packageImport.py", line 58, in
  File "/usr/share/rhn/server/importlib/importLib.py", line 674, in
    "Unknown arch %s" % package.arch)
InvalidArchError: Unknown arch sparcv9-solaris-patch

Local variables by frame
Frame _postprocessPackageNEVRA in
/usr/share/rhn/server/importlib/importLib.py at line 674
                        self = <type 'instance'>
<server.importlib.packageImport.PackageImport instance at
                        arch = <type 'NoneType'> None
                     package = <type 'instance'> <ERROR WHILE PRINTING
VALUE: string representation too large>

Frame fix in /usr/share/rhn/server/importlib/packageImport.py at line 58
                        self = <type 'instance'>
<server.importlib.packageImport.PackageImport instance at
                    uniqdict = <type 'dict'> {}
                     package = <type 'instance'> <ERROR WHILE PRINTING
VALUE: string representation too large>

Frame fix in /usr/share/rhn/server/importlib/packageImport.py at line
                        self = <type 'instance'>
<server.importlib.packageImport.PackageImport instance at

Frame run in /usr/share/rhn/server/importlib/importLib.py at line 616
                        self = <type 'instance'>
<server.importlib.packageImport.PackageImport instance at

Frame push_package in /usr/share/rhn/server/rhnPackageUpload.py at line
                  header_end = <type 'int'> 0
                       force = <type 'int'> 0
                header_start = <type 'int'> 0
              payload_stream = <type 'file'> <open file '<fdopen>', mode
'w+b' at 0x2b0fb2fc4c60>
                payload_size = <type 'int'> 10519743
                      md5sum = <type 'str'>
                      org_id = <type 'int'> 1
                       batch = <type 'instance'> <ERROR WHILE PRINTING
VALUE: string representation too large>
               relative_path = <type 'str'>
                    channels = <type 'list'> []
                      header = <type 'instance'> <ERROR WHILE PRINTING
VALUE: string representation too large>
                    importer = <type 'instance'>
<server.importlib.packageImport.PackageImport instance at
                         pkg = <type 'instance'> <ERROR WHILE PRINTING
VALUE: string representation too large>
                upload_force = <type 'int'> 0
                     backend = <type 'instance'>
<server.importlib.backendOracle.OracleBackend instance at

Frame handler in
/usr/share/rhn/upload_server/handlers/package_push/package_push.py at
line 133
                  header_end = <type 'int'> 0
                         req = <type 'mp_request'> <mp_request object at
                header_start = <type 'int'> 0
              payload_stream = <type 'file'> <open file '<fdopen>', mode
'w+b' at 0x2b0fb2fc4c60>
                 temp_stream = <type 'file'> <open file '<fdopen>', mode
'w+b' at 0x2b0fb2fc4b70>
                      md5sum = <type 'str'>
                         ret = <type 'int'> 0
                      header = <type 'instance'> <ERROR WHILE PRINTING
VALUE: string representation too large>
                        self = <type 'instance'>
<upload_server.handlers.package_push.package_push.PackagePush instance
at 0x2b0fb2b68320>

Frame _wrapper in /usr/share/rhn/server/apacheUploadServer.py at line
                    function = <type 'instancemethod'> <bound method
PackagePush.handler of
<upload_server.handlers.package_push.package_push.PackagePush instance
at 0x2b0fb2b68320>>
                        self = <type 'instance'>
<server.apacheUploadServer.UploadHandler instance at 0x2b0fb2ec6ef0>
                         req = <type 'mp_request'> <mp_request object at
               function_name = <type 'str'> handler

Frame handler in /usr/share/rhn/server/apacheUploadServer.py at line 69
                        self = <type 'instance'>
<server.apacheUploadServer.UploadHandler instance at 0x2b0fb2ec6ef0>
                         req = <type 'mp_request'> <mp_request object at

Frame __call__ in /usr/share/rhn/server/apacheServer.py at line 49
                        self = <type 'instance'>
<server.apacheUploadServer.UploadHandlerWrap instance at 0x2b0fb2ebfd88>
                         req = <type 'mp_request'> <mp_request object at
                           f = <type 'instancemethod'> <bound method
UploadHandler.handler of <server.apacheUploadServer.UploadHandler
instance at 0x2b0fb2ec6ef0>>

Frame HandlerDispatch in
/usr/lib64/python2.4/site-packages/mod_python/apache.py at line 299
                         req = <type 'mp_request'> <mp_request object at
                      config = <type 'mp_table'> {'PythonInterpreter':
'rhn.server.upload', 'PythonPath': 'sys.path+['/usr/share/rhn']'}
                        self = <type 'instance'>
<mod_python.apache.CallBack instance at 0x2b0fb2b69c68>
                      object = <type 'instance'>
<server.apacheUploadServer.UploadHandlerWrap instance at 0x2b0fb2ebfd88>
                           l = <type 'list'>
['server.apacheUploadServer', 'Handler']
                      module = <type 'module'> <module
'server.apacheUploadServer' from
                       hlist = <type 'mp_hlist'>
                  object_str = <type 'str'> Handler
                       debug = <type 'int'> 0
                 module_name = <type 'str'> server.apacheUploadServer
                  pathstring = <type 'str'> sys.path+['/usr/share/rhn']
                      result = <type 'int'> 500

Environment for PID=9678 on exception:
NLS_LANG = english.UTF8
ORACLE_HOME = /opt/oracle
PATH = /sbin:/usr/sbin:/bin:/usr/bin
PWD = /
TERM = xterm
_ = /usr/sbin/httpd


Changing "sparcv9" to just "sparc" within the README file does seem to
avoid the problem completely, but RH dev team still probably should fix
this. A good thing to do would be to take the arch info from the file
called "patchinfo" right inside a patch directory rather than from the
README file. A patchinfo file looks like this:

bash-2.03# cat patchinfo
PATCH_OSRELEASE='5.8 5.9 5.10'
Comment 1 Brandon Perkins 2009-03-03 11:44:31 EST
Can you please provide the patch, package, or patch cluster you used and the exact command-line arguments.
Comment 2 Erich Morisse 2009-03-12 17:21:25 EDT
The patch is 118667_18 from the 10_Recommend cluster dated ~2/27.  The cluster is ~1GB compressed, so have not asked the customer to provide it.

It looks like we're reading in the architecture of the patch from the wrong place.  sparcv9 is listed as the architecture in the README included in the patch, but PATCH_ARCH in the patchinfo file correctly identifies the architecture.  

Setting the architecture in the README gets this patch application to work correctly, but I think the right answer is to read from the patchinfo file?
Comment 3 Brandon Perkins 2009-03-17 11:24:24 EDT
Agreeing to take a look at it in sat530.  We're assuming at this point that Sun changed something that breaks our assumptions.
Comment 8 Jan Pazdziora 2009-04-08 04:54:33 EDT
Fixed in Spacewalk master, commit 7b658514d8637886b29e8ce8c0e36a6bac530242.
Comment 9 Jan Pazdziora 2009-04-08 04:55:26 EDT
Fixed in Spacewalk VADER, commit cf988a0ec81bb22e02106d5dc562a9e04f8ece3d.
Comment 10 Jan Pazdziora 2009-04-10 04:26:45 EDT
Tagged as rhnpush-5.4.1-1 and rhnpush-5.3.1-3-sat.
Comment 12 Jan Pazdziora 2009-04-27 05:28:38 EDT
Package rhnpush 5.3.1-5 has the fix.

Moving ON_QA with composes Satellite-5.3.0-RHEL?-re20090424.1 available.
Comment 14 Steve Salevan 2009-08-14 14:43:06 EDT
RELEASE_PENDING from latest Stage build.
Comment 15 Brandon Perkins 2009-09-10 15:41:06 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.