Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1361715 - preupg exits with 255 with some result combinations
Summary: preupg exits with 255 with some result combinations
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: preupgrade-assistant
Version: 6.8
Hardware: Unspecified
OS: Unspecified
Target Milestone: rc
: ---
Assignee: Michal Bocek
QA Contact: Alois Mahdal
: 1368825 (view as bug list)
Depends On:
Blocks: 1335121 1393496
TreeView+ depends on / blocked
Reported: 2016-07-29 20:37 UTC by Alois Mahdal
Modified: 2017-03-21 12:09 UTC (History)
8 users (show)

Fixed In Version: preupgrade-assistant-2.2.0-1.el6
Doc Type: No Doc Update
Doc Text:
Clone Of:
Last Closed: 2017-03-21 12:09:10 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2017:0819 normal SHIPPED_LIVE preupgrade-assistant bug fix and enhancement update 2017-03-21 12:53:47 UTC

Description Alois Mahdal 2016-07-29 20:37:25 UTC
Description of problem

In some cases, `preupg` ends with 255, even though everything else seems
to be OK.

I found this when running mysql module test, which runs all 4 database
modules in loop with varying presence of incompatible options or mysql

There seems to be corelation with results:

    notapplicable  notapplicable  notapplicable  notapplicable     FAIL
    notapplicable  pass           informational  informational     FAIL
    notapplicable  notapplicable  notapplicable  needs_action      PASS
    notapplicable  pass           informational  needs_action      PASS
    notapplicable  pass           informational  needs_inspection  PASS

It seems as if only cases containing at leasr "needs_inspection" or
"needs_action" behave normally.

The exact command run in the test is:

    preupg --force --select-rules 'xccdf_preupg_rule_databases_postgresql_pre,xccdf_preupg_rule_databases_mysql_data_migration_migration,xccdf_preupg_rule_databases_mysql_configuration_changes_configuration,xccdf_preupg_rule_databases_mysql_general_changes_general'

Version-Release number of selected component


How reproducible

Always (with this test)

Steps to Reproduce

Schedule test /CoreOS/preupgrade-assistant/6to7/contents/mysql-configuration_changes:

    ipu sched -B -t /CoreOS/preupgrade-assistant/6to7/contents/mysql-configuration_changes | bash

Actual results

Some subtests report failure due to exit status 255

Expected results

Exit status should be 0, 1 or 2 in all sub-tests (i.e. the preupg wrapper
should always report PASS)

Comment 1 Alois Mahdal 2016-07-29 21:44:14 UTC
This affects mosts tests, giving false positives.

Comment 4 Petr Hracek 2016-08-15 12:19:51 UTC
OK, I will look on it.
It is a pretty hard to test it, though.

Comment 5 Alois Mahdal 2016-08-15 14:30:04 UTC
(In reply to Petr Hracek from comment #4)
> OK, I will look on it.
> It is a pretty hard to test it, though.

It's probably hard to test the failure cases, but the "normal" cases (various result combinations, 0-3) should be relatively straightforward, and those are currently hurting us most.

(I'm planning to write test focused on the "normal" cases; and more in future cycles...)

Comment 9 Petr Hracek 2016-08-22 11:12:47 UTC
*** Bug 1368825 has been marked as a duplicate of this bug. ***

Comment 15 Michal Bocek 2016-12-14 12:51:47 UTC
In preupgrade-assistant-2.2.0-1.el6, preupg exits with code 1 or 2 on module failure/error. See the below table that show what exit codes are returned based on module results.

exit_x | log_x_risk || result | exit status |
fail   | (none)     ||   fail |  2          |
fail   | slight     ||  n_ins |  0          |
fail   | medium     ||  n_ins |  0          |
fail   | high       ||  n_act |  1          |
fail   | extreme    ||   fail |  2          |
fixed  | *          ||  fixed |  0          |
info   | *          ||   info |  0          |
n_app  | *          ||   napp |  0          |
pass   | *          ||   pass |  0          |
error  | *          ||  error |  2          |
    exit_x or       ||        |             |
    log_x_risk      ||  error |  2          |
    not called      ||        |             |

Comment 17 Alois Mahdal 2017-01-31 14:33:34 UTC
/CoreOS/preupgrade-assistant/api/mseverity covers this, and it passes, so OK from me.

Comment 19 errata-xmlrpc 2017-03-21 12:09:10 UTC
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.

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