You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@madlib.apache.org by "Stuart Pollock (Jira)" <ji...@apache.org> on 2019/11/20 14:47:00 UTC

[jira] [Created] (MADLIB-1396) Installing MADLib 1.16 Fails, Reporting Already Installed

Stuart Pollock created MADLIB-1396:
--------------------------------------

             Summary: Installing MADLib 1.16 Fails, Reporting Already Installed
                 Key: MADLIB-1396
                 URL: https://issues.apache.org/jira/browse/MADLIB-1396
             Project: Apache MADlib
          Issue Type: Bug
            Reporter: Stuart Pollock


Installing MADLib on our freshly installed two-node system (running RHEL 7.7 on bare metal) reports that MADLib is already installed, and the installation seems to have failed.

{{[gpadmin@sdw5 ~]$ gppkg -i }}madlib-1.16+5-gp6-rhel7-x86_64/madlib-1.16+5-gp6-rhel7-x86_64.gppkg

{{...}}

{{stderr='warning: waiting for transaction lock on /usr/local/greenplum-db-6.1.0/share/packages/database/.rpm.lock package madlib-1.16-1.x86_64 is already installed}}

Running the installation again also reports that MADLib is already installed, but the nature of the error is different:

{{[gpadmin@sdw5 ~]$ gppkg -i }}{{madlib-1.16+5-gp6-rhel7-x86_64/madlib-1.16+5-gp6-rhel7-x86_64.gppkg}}

{{20191119:08:50:05:105922 gppkg:sdw5:gpadmin-[INFO]:-Starting gppkg with args: -i }}{{madlib-1.16+5-gp6-rhel7-x86_64/madlib-1.16+5-gp6-rhel7-x86_64.gppkg}}

{{20191119:08:50:05:105922 gppkg:sdw5:gpadmin-[INFO]:-Installing package madlib-1.16+5-gp6-rhel7-x86_64.gppkg}}

{{20191119:08:50:05:105922 gppkg:sdw5:gpadmin-[INFO]:-Validating rpm installation cmdStr='rpm --test -i /usr/local/greenplum-db-6.1.0/.tmp/madlib-1.16-1.x86_64.rpm --dbpath /usr/lo$al/greenplum-db-6.1.0/share/packages/database --prefix /usr/local/greenplum-db-6.1.0'}}

{{20191119:08:50:05:105922 gppkg:sdw5:gpadmin-[CRITICAL]:-gppkg failed. (Reason='madlib-1.16+5-gp6-rhel7-x86_64.gppkg is already installed.') exiting...}}

Please note that .rpm.lock is an issue during the first invocation and not in the second.

Frequency:  This behavior happened two consecutive on clean installations on a system containing GPDB 6.1.0 with GPCC 6.0.0.

 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)