Bug 488157 - sparcv9 architecture not supported in solaris2mpm & satellite
Summary: sparcv9 architecture not supported in solaris2mpm & satellite
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Satellite 5
Classification: Red Hat
Component: Solaris
Version: 520
Hardware: x86_64
OS: Linux
high
medium
Target Milestone: ---
Assignee: Jan Pazdziora (Red Hat)
QA Contact: Steve Salevan
URL:
Whiteboard:
Depends On:
Blocks: 457000
TreeView+ depends on / blocked
 
Reported: 2009-03-02 22:13 UTC by Erich Morisse
Modified: 2018-10-27 14:23 UTC (History)
4 users (show)

Fixed In Version: sat530
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-09-10 19:41:06 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Erich Morisse 2009-03-02 22:13:31 UTC
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
information:
URI: /PACKAGE-PUSH
Remote Host: 192.168.204.100
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
_wrapper
    ret = function(req)
  File
"/usr/share/rhn/upload_server/handlers/package_push/package_push.py",
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
push_package
    importer.run()
  File "/usr/share/rhn/server/importlib/importLib.py", line 616, in run
    self.fix()
  File "/usr/share/rhn/server/importlib/packageImport.py", line 264, in
fix
    ChannelPackageSubscription.fix(self)
  File "/usr/share/rhn/server/importlib/packageImport.py", line 58, in
fix
    self._postprocessPackageNEVRA(package)
  File "/usr/share/rhn/server/importlib/importLib.py", line 674, in
_postprocessPackageNEVRA
    "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
0x2b0fb2fc0878>
                        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
0x2b0fb2fc0878>
                    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
264
                        self = <type 'instance'>
<server.importlib.packageImport.PackageImport instance at
0x2b0fb2fc0878>

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

Frame push_package in /usr/share/rhn/server/rhnPackageUpload.py at line
219
                  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'>
cb65ed82d65835692bb16f7540a029dc
                      org_id = <type 'int'> 1
                       batch = <type 'instance'> <ERROR WHILE PRINTING
VALUE: string representation too large>
               relative_path = <type 'str'>
redhat/1/patch-solaris-118667/18-1/sparcv9-solaris-patch/118667-18.zip
                    channels = <type 'list'> []
                      header = <type 'instance'> <ERROR WHILE PRINTING
VALUE: string representation too large>
                    importer = <type 'instance'>
<server.importlib.packageImport.PackageImport instance at
0x2b0fb2fc0878>
                         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
0x2b0fb2fc08c0>

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
0x2b0fb2b651f0>
                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'>
cb65ed82d65835692bb16f7540a029dc
                         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
115
                    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
0x2b0fb2b651f0>
               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
0x2b0fb2b651f0>

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
0x2b0fb2b651f0>
                           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
0x2b0fb2b651f0>
                      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
'/usr/share/rhn/server/apacheUploadServer.pyc'>
                       hlist = <type 'mp_hlist'>
{'handler:'server.apacheUploadServer::Handler','directory':'/PACKAGE-PUS
H/','silent':0}
                  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:
LANG = C
NLS_LANG = english.UTF8
ORACLE_HOME = /opt/oracle
PATH = /sbin:/usr/sbin:/bin:/usr/bin
PERL_BADFREE = 0
PWD = /
SHLVL = 2
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
PATCHINFOVERSION="1.0"
PATCHID=118667-18
PATCH_CORRECTS='Java.Runtime.64-1.5'
PATCH_ARCH='sparc'
PATCH_OS='SunOS'
PATCH_OSRELEASE='5.8 5.9 5.10'
PATCH_PROPERTIES='clientusr'
bash-2.03#

Comment 1 Brandon Perkins 2009-03-03 16:44:31 UTC
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 21:21:25 UTC
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 15:24:24 UTC
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 (Red Hat) 2009-04-08 08:54:33 UTC
Fixed in Spacewalk master, commit 7b658514d8637886b29e8ce8c0e36a6bac530242.

Comment 9 Jan Pazdziora (Red Hat) 2009-04-08 08:55:26 UTC
Fixed in Spacewalk VADER, commit cf988a0ec81bb22e02106d5dc562a9e04f8ece3d.

Comment 10 Jan Pazdziora (Red Hat) 2009-04-10 08:26:45 UTC
Tagged as rhnpush-5.4.1-1 and rhnpush-5.3.1-3-sat.

Comment 12 Jan Pazdziora (Red Hat) 2009-04-27 09:28:38 UTC
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 18:43:06 UTC
RELEASE_PENDING from latest Stage build.

Comment 15 Brandon Perkins 2009-09-10 19:41:06 UTC
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.