+++ This bug was initially created as a clone of Bug #1098149 +++ after clean installation of all components (engine, dwh, reports) when running engine-cleanup we get: [ INFO ] Stage: Initializing [ INFO ] Stage: Environment setup Configuration files: ['/etc/ovirt-engine-setup.conf.d/10-packaging.conf', '/etc/ovirt-engine-setup.conf.d/20-setup-ovirt-post.conf'] Log file: /var/log/ovirt-engine/setup/ovirt-engine-remove-20140515142947-vh6675.log Version: otopi-1.2.1 (otopi-1.2.1-1.fc19) [ ERROR ] Failed to execute stage 'Environment setup': 'OVESETUP_REPORTS_CONFIG/jasperHome' [ INFO ] Stage: Clean up Log file is located at /var/log/ovirt-engine/setup/ovirt-engine-remove-20140515142947-vh6675.log [ INFO ] Generating answer file '/var/lib/ovirt-engine/setup/answers/20140515142948-cleanup.conf' [ INFO ] Stage: Pre-termination [ INFO ] Stage: Termination [ ERROR ] Execution of cleanup failed Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/otopi/context.py", line 142, in _executeMethod method['method']() File "/usr/share/ovirt-engine/setup/bin/../plugins/ovirt-engine-common/ovirt-engine-reports/db/connection.py", line 116, in _setup self.environment[oreportscons.ConfigEnv.JASPER_HOME], Cause: JASPER_HOME has no postinstall value and required for database connection. Why do we need database connection in cleanup? Workaround: # engine-cleanup --otopi-environment="OVESETUP_REPORTS_CONFIG/jasperHome=str:/usr/share/jasperreports-server/"
Moving to QE as it seems to me that downstream is unaffected. This is because the downstream package explicitly defines in 20-packaging-rhevm-reports.conf: OVESETUP_REPORTS_CONFIG/jasperHome=str:@DATAROOT_DIR@/jasperreports-server-pro .
(In reply to Yedidyah Bar David from comment #1) > Moving to QE as it seems to me that downstream is unaffected. This is > because the downstream package explicitly defines in > 20-packaging-rhevm-reports.conf: > OVESETUP_REPORTS_CONFIG/jasperHome=str:@DATAROOT_DIR@/jasperreports-server- > pro . This is so at least since mid Mar or so, didn't check exact version.
This needs to be tested for 3.4 as well.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHEA-2015-0176.html