action #47189
closed[functional][y] Crosscheck or remove workaround for bsc#989770 - "Undesired activation of already existing encrypted volume during installation has to be canceled twice"
Added by okurz about 5 years ago. Updated about 5 years ago.
0%
Description
Motivation¶
We have reminder comments in the VERIFIED FIXED bug in https://bugzilla.suse.com/show_bug.cgi?id=989770#c11
Acceptance criteria¶
- AC1: Bug is either reopened, a new bug is opened or the bug detection does not falsely detect this situation
Suggestions¶
- Closely check the logfile and video if the handle the test correctly
Updated by riafarov about 5 years ago
We need to crosscheck this scenario on different architectures as behavior can differ.
Updated by okurz about 5 years ago
https://openqa.suse.de/tests/2430459#step/encrypted_volume_activation/1 shows the module to be green on x86_64 but aarch64 shows the problem in https://openqa.suse.de/tests/2429317#step/encrypted_volume_activation/4 and this is also where the bugzilla reminder comment comes from.
Updated by JRivrain about 5 years ago
- Status changed from Workable to In Progress
The problem had not happened for very long time, and happened only once so far. In the meantime the package yast2-storage ( that seemed to be the cause of https://bugzilla.suse.com/show_bug.cgi?id=989770#c11 ) has been completely re-written and is now called yast2-storage-ng ( https://github.com/yast/yast-storage-ng )
The version of this package in the soft-failing build is 4.1.48-1.6. Some test runs had passed earlier with the same package version in it. The problem did not occur in the following build with 4.1.48-1.7 in it.
When we look at the video of the soft-failing run, it does not seem at all like the cancellation is done twice, but only once, as in a other test runs. My bet for the moment is that openqa probed for the needles second time, before the window was closed. It is strange that it happened only that one time though. If I'm right, it would be good to do many iterations of the test at high load to see if we can reproduce this.
Updated by okurz about 5 years ago
JRivrain wrote:
The problem had not happened for very long time, and happened only once so far. In the meantime the package yast2-storage ( that seemed to be the cause of https://bugzilla.suse.com/show_bug.cgi?id=989770#c11 ) has been completely re-written and is now called yast2-storage-ng ( https://github.com/yast/yast-storage-ng )
Well, yast2-storage-ng is only used though for newer product versions, e.g. not the SLE12 codestream.
If I'm right, it would be good to do many iterations of the test at high load to see if we can reproduce this.
Yes, true. You could use the approach described in https://progress.opensuse.org/projects/openqatests/wiki/Wiki#Statistical-investigation to do this together with limiting the schedule to abort all tests after the soft-failing module.
The test code has
wait_screen_change { send_key 'alt-c'; };
assert_screen($after_cancel_tags);
Could you check the log if the wait_screen_change timed out or actually a screen change did happen? Maybe the dialog did not disappear yet but the simple button press was detected as "screen change" enough to trigger the wait_screen_change? wait_screen_change has optional parameters so maybe we need to adjust them in this case.
Updated by JRivrain about 5 years ago
A screen change was triggered but it really does not look like it on the video. Need to double-check with yast logs.
[2019-02-01T12:39:41.587 UTC] [debug] <<< testapi::send_key(key='alt-c', do_wait=0)
[2019-02-01T12:39:41.810 UTC] [debug] waiting for screen change: 0 41.5230257715049
[2019-02-01T12:39:41.810 UTC] [debug] >>> testapi::wait_screen_change: screen change seen at 0
[2019-02-01T12:39:41.811 UTC] [debug] /var/lib/openqa/cache/openqa.suse.de/tests/sle/tests/installation/encrypted_volume_activation.pm:37 called testapi::assert_screen
[2019-02-01T12:39:41.811 UTC] [debug] <<< testapi::assert_screen(mustmatch=[
'encrypted_volume_activation_prompt',
'enable-multipath',
'scc-registration',
'inst-instmode'
], timeout=30)
[2019-02-01T12:39:44.585 UTC] [debug] >>> testapi::_handle_found_needle: found encrypted_volume_activation_prompt-embedded_password_prompt-20171107, similarity 1.00 @ 351/430
It did not happen again with the 161.1 build.
Updated by JRivrain about 5 years ago
There is no trace of the module ( yast-installation/src/lib/installation/clients/inst_system_analysis.rb ) in y2logs (Martin, ancorgs and HuHa also looked and found the same nothingness) I am not sure reproducing the issue is useful, since we have no way for now to really know what happens.
Updated by JRivrain about 5 years ago
PR https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/6791 "Remove soft failure for fixed bsc#989770".
Updated by JRivrain about 5 years ago
- Status changed from In Progress to Feedback
I put this in feedback, I think the error was a very-unlikely-reproducible openqa bug and in the case we would reproduce it, we would not have logs form yast anyway... unless we start collecting logs when we have a soft-fail. Which could be a good idea if we want to investigate soft-failures.
Updated by riafarov about 5 years ago
- Status changed from Feedback to Resolved