action #67654
closed[sle][functional][u] test fails in first_boot - authentication is required for refresh system repositories
0%
Description
Observation¶
openQA test in scenario sle-15-SP2-Full-s390x-skip_registration+workaround_modules@s390x-zVM-ctc fails in
first_boot
Test suite description¶
Like skip_registration test suite, but enable all modules as custom addons.
For internal testing, not simulating customer workflows
See https://progress.opensuse.org/issues/25264 for details. For now only "INSTALLONLY=1", later could be extended to do a full test run.
Reproducible¶
Fails since (at least) Build 203.1 (current job)
Expected result¶
Last good: 202.6 (or more recent)
Further details¶
it looks weird, afer user login, then authentication is required for refresh system repositories:
https://openqa.suse.de/tests/4295262#step/first_boot/7
Always latest result in this scenario: latest
Updated by szarate almost 4 years ago
- Status changed from New to Feedback
- Assignee set to szarate
- Target version set to Milestone 30
- Difficulty set to easy
Needle already created, waiting for verification job (https://gitlab.suse.de/openqa/os-autoinst-needles-sles/-/commit/a4ebd7b326b8cbf5e9d0c2be2f3151b703695a67) https://openqa.suse.de/tests/4306352#live
Let me explain it. The reason of having the authentication window is SLES has a more restrictive security policy than SLED. So to diminish the dialog, we need to relax the corresponding policy with proper security audit. This was dealt with https://bugzilla.suse.com/show_bug.cgi?id=1169540
However as you can see from bsc#1169540 , "puching a security hole" was not that preferrable through the audti. In the end, as a trade-off, we have a partly approved relax of policy, which only applies to GNOME local seat (a set of local display, mouse and keyboard). But the remote connection like VNC connection to the machine still has this more restrictive policy set.
👍🏾 1
To answer the above question, connecting guest GNOME using QEMU VNC is different from connecting GNOME directly using the SUT system VNC.
With the former way, GNOME does not realize it is remotely connected and will assign the "local seat" to the QEMU emulated display, mouse and keyboard.
With the later way, GNOME knows it is remotely connected and the session process is a bit different. So a local seat is not assigned to the user, and in SLES, a more restrictive policy applies.
So I assume the s390x first_boot failure is probably hit by the latter case.
Updated by szarate almost 4 years ago
- Category deleted (
Bugs in existing tests) - Status changed from Feedback to Resolved
- Assignee deleted (
szarate) - Target version deleted (
Milestone 30) - Difficulty deleted (
easy)
Verification run passed
Updated by SLindoMansilla almost 4 years ago
- Assignee set to szarate
- Target version set to Milestone 30