action #116851
closedtest fails in check_system_info - sle-module-basesystem is not in the output of zypper lr
Added by leli over 1 year ago. Updated over 1 year ago.
0%
Description
Observation¶
openQA test in scenario sle-15-SP5-Migration-from-SLE15-SPx-x86_64-online_sles15sp4_pscc_basesys-srv-live-tsm_def_full_zdup@64bit fails in
check_system_info
sle-module-basesystem is not in the output of zypper lr.
Acceptance criteria¶
AC1: Investigate why the sle-module-basesystem is not in the output of zypper lr.
Updated by tinawang123 over 1 year ago
Need add setting 'KEEP_REGISTERED=1'
As, we did de-register at patch_sle, so after patch_sle we cannot find any modules.
We need keep register then check modules.
Updated by tinawang123 over 1 year ago
Need check why check modules at x86_64 platform, but not check modules at ppc64le and s390x platform:
https://openqa.nue.suse.com/tests/9564837#step/check_system_info/4
https://openqa.nue.suse.com/tests/9564900#
Updated by leli over 1 year ago
Need check why output of 'SUSEConnect -s' is 'Not Registered', it can still check addons.
Check the expected addons before migration¶
if (check_var('VERSION', get_required_var('ORIGIN_SYSTEM_VERSION')) && ($output !~ /Not Registered/)) {
Updated by coolgw over 1 year ago
jgwang will investigate firstly try to find root cause
Updated by JERiveraMoya over 1 year ago
- Tags deleted (
qe-yast-refinement) - Target version set to future
Updated by JERiveraMoya over 1 year ago
- Priority changed from Normal to Low
Setting Priority: 'Low' and Target version: 'future' and removing Tag 'qe-yast-refinement' until we have more info.
Updated by jgwang over 1 year ago
tinawang123 wrote:
Need check why check modules at x86_64 platform, but not check modules at ppc64le and s390x platform:
https://openqa.nue.suse.com/tests/9564837#step/check_system_info/4
https://openqa.nue.suse.com/tests/9564900#
I checked the above jobs about ppc64le and s390x, the jobs didn't check basesystem module because the code of "version_switch_origin_system" changed the value(15-SP5) of "VERSION" to the value(15-SP2) of "ORIGIN_SYSTEM_VERSION", and the job for x86_64 doesn't include "version_switch_origin", so the conditions in the code "check_system_info" are not true after de-register:
# Check the expected addons before migration
if (check_var('VERSION', get_required_var('ORIGIN_SYSTEM_VERSION')) && ($output !~ /Not Registered/))
...
# Check the expected information after migration
if (check_var('VERSION', get_required_var('UPGRADE_TARGET_VERSION')))
that's the reason that the behavior of s390x and ppc64le is different from x86_64.
Updated by jgwang over 1 year ago
leli wrote:
Need check why output of 'SUSEConnect -s' is 'Not Registered', it can still check addons.
Check the expected addons before migration¶
if (check_var('VERSION', get_required_var('ORIGIN_SYSTEM_VERSION')) && ($output !~ /Not Registered/)) {
this code block is not executed for https://openqa.nue.suse.com/tests/9545668/modules/check_system_info/steps/14, the condition($output !~ /Not Registered/) is not true.
Updated by jgwang over 1 year ago
we can add the code "version_switch_origin_system" in the beginning of the job https://openqa.nue.suse.com/tests/9681180, this solution doesn't break existing workflow in the job(actually I don't like to change variable values arbitrarily), I suggest we adopt the solution. please add your comments if you have good suggestions.
Updated by leli over 1 year ago
jgwang wrote:
we can add the code "version_switch_origin_system" in the beginning of the job https://openqa.nue.suse.com/tests/9681180, this solution doesn't break existing workflow in the job(actually I don't like to change variable values arbitrarily), I suggest we adopt the solution. please add your comments if you have good suggestions.
Right, the version_switch_origin_system is not loaded, you need deep investigation to find the root cause why the module hasn't been loaded.
Updated by jgwang over 1 year ago
leli wrote:
jgwang wrote:
we can add the code "version_switch_origin_system" in the beginning of the job https://openqa.nue.suse.com/tests/9681180, this solution doesn't break existing workflow in the job(actually I don't like to change variable values arbitrarily), I suggest we adopt the solution. please add your comments if you have good suggestions.
Right, the version_switch_origin_system is not loaded, you need deep investigation to find the root cause why the module hasn't been loaded.
- in ppc64le job https://openqa.nue.suse.com/tests/9564900, ONLINE_MIGRATION was set to "0", "version_switch_origin_system" would be loaded
- in s390x job https://openqa.nue.suse.com/tests/9564837, ONLINE_MIGRATION was not set(I think it is default to "undef"), "version_switch_origin_system" would be loaded
- in x84_64 job https://openqa.nue.suse.com/tests/9545668, ONLINE_MIGRATION was set to "1", "version_switch_origin_system" would be NOT loaded
I am a little confused, I think these three jobs are for online migration, but the values of ONLINE_MIGRATION are different.
Updated by jgwang over 1 year ago
I only set ONLINE_MIGRATION=0, and the job for x86_64 passed:
I compared online_sles15sp4_pscc_basesys-srv-live-tsm_def_full_zdup with online_sles15sp3_pscc_basesys-srv-live-tsm_def_full_zdup, no ONLINE_MIGRATION in online_sles15sp3_pscc_basesys-srv-live-tsm_def_full_zdup.
Updated by leli over 1 year ago
jgwang wrote:
I only set ONLINE_MIGRATION=0, and the job for x86_64 passed:
I compared online_sles15sp4_pscc_basesys-srv-live-tsm_def_full_zdup with online_sles15sp3_pscc_basesys-srv-live-tsm_def_full_zdup, no ONLINE_MIGRATION in online_sles15sp3_pscc_basesys-srv-live-tsm_def_full_zdup.
Yes, in fact for zdup cases we shouldn't set ONLINE_MIGRATION=1, please fix it by removing the setting (while don't set ONLINE_MIGRATION=0, that's not the usual using).
Updated by jgwang over 1 year ago
I committed MR:
Updated by leli over 1 year ago
jgwang wrote:
I committed MR:
Merged, good job.