action #68507
closed[functional][y] Apply workaround for bsc#1157928 when switch to x11 console on s390x kvm
0%
Description
Follow up for #67765.
Investigation has shown that we face combination of 2 issues, one is that we get polkit window and other is console switching itself.
Following code solves the issue:
select_console('x11', await_console => 0);
record_soft_failure 'bsc#1157928 - deal with additional polkit windows';
wait_still_screen(3);
ensure_unlocked_desktop;
# deal with potential followup authentication window which is not
# actually a login screen but polkit asking for modification to system
# repositories
wait_still_screen(3);
ensure_unlocked_desktop;
However, we already have workaround in first_boot module and proper solution should be triggered from console_selected, so ensure_unlocked_desktop seems to be better place for this solution as we can face this issue not only during the boot.
Updated by riafarov almost 4 years ago
- Subject changed from [functional][y] Apply workaround for bsc#1157928 when switch to x11 console on s390x to [functional][y] Apply workaround for bsc#1157928 when switch to x11 console on s390x kvm
Updated by riafarov almost 4 years ago
- Due date changed from 2020-07-14 to 2020-07-28
Updated by riafarov almost 4 years ago
- Status changed from New to Workable
- Estimated time set to 5.00 h
Updated by oorlov over 3 years ago
- Due date changed from 2020-07-28 to 2020-09-08
The issue with popup, that asks to update repositories seems to be fixed just recently: https://bugzilla.suse.com/show_bug.cgi?id=1170416#c13
The other issue with https://bugzilla.suse.com/show_bug.cgi?id=1157928 also marked as RESOLVED FIXED.
As we don't have new builds right now, it is decided to move this ticket to the future sprint, and once we'll have new build to check if the issue is solved there. And in case it is solved, we can remove the appropriate workaround from first_boot: handle_additional_polkit_windows_bsc1157928().
Updated by oorlov over 3 years ago
- Due date changed from 2020-09-08 to 2020-09-22
Updated by openqa_review over 3 years ago
This is an autogenerated message for openQA integration by the openqa_review script:
This bug is still referenced in a failing openQA test: allmodules+allpatterns+registration
https://openqa.suse.de/tests/4424698
To prevent further reminder comments one of the following options should be followed:
- The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
- The openQA job group is moved to "Released"
- The label in the openQA scenario is removed
Updated by openqa_review over 3 years ago
This is an autogenerated message for openQA integration by the openqa_review script:
This bug is still referenced in a failing openQA test: allmodules+allpatterns+registration@s390x-zVM-vswitch-l2
https://openqa.suse.de/tests/4610434
To prevent further reminder comments one of the following options should be followed:
- The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
- The openQA job group is moved to "Released"
- The label in the openQA scenario is removed
Updated by riafarov over 3 years ago
- Due date changed from 2020-09-22 to 2020-10-06
Updated by JRivrain over 3 years ago
- Status changed from Workable to Blocked
The problem is here
[2020-09-15T18:03:49.878 CEST] [debug] tests/shutdown/shutdown.pm:28 called power_action_utils::power_action -> lib/power_action_utils.pm:255 called testapi::select_console -> lib/susedistribution.pm:860 called x11utils::ensure_unlocked_desktop -> lib/x11utils.pm:102 called testapi::assert_and_click
unless ($args{keepconsole}) {
select_console $args{textmode} ? 'root-console' : 'x11';
}
Anyway, I cannot try anything currently as we never reach the shutdown module in the last builds, and assets are missing for the older builds. Setting this as blocked until we get a build that works.
Updated by JRivrain over 3 years ago
- Status changed from Blocked to In Progress
Updated by JRivrain over 3 years ago
The problem did not happen in the last run. I tried something, see PR: https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/11120/files .
Though the problem in the failed runs was that we had a popup because of package repositories being refreshed. So then we have that piece of code, where is looks like "autenticate" was asserted way after the button was clicked:
if (match_has_tag('authentication-required-user-settings') || match_has_tag('authentication-required-modify-system')) {
type_password;
assert_and_click "authenticate";
}
This does not seem to happen in latest build, as we don't have that pop-up. I launched 20 runs in low priority with my attempt of workaround, to see if the pop-up appears again. Otherwise there may be a way to trigger it.
Updated by JRivrain over 3 years ago
workaround not working https://openqa.suse.de/tests/4763206#step/shutdown/5.
Updated by riafarov over 3 years ago
- Project changed from openQA Tests to qe-yam
- Category deleted (
Enhancement to existing tests)
Updated by JRivrain over 3 years ago
- Status changed from In Progress to Feedback
Updated by JRivrain over 3 years ago
- Status changed from Feedback to In Progress
Put back as workable as we could re-open the bug or a open a new one. I am trying to determine if what we see here is the same bug as https://bugzilla.suse.com/show_bug.cgi?id=1157928 by reproducing this scenario on zVM.
Updated by JRivrain over 3 years ago
- Status changed from In Progress to Blocked
I reported this https://bugzilla.suse.com/show_bug.cgi?id=1177446 and that https://bugzilla.suse.com/show_bug.cgi?id=1177445, let's see what feedback we'll get, setting to blocked until then.