Project

General

Profile

Actions

action #67654

closed

[sle][functional][u] test fails in first_boot - authentication is required for refresh system repositories

Added by zluo almost 4 years ago. Updated almost 4 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
-
Target version:
SUSE QA - Milestone 30
Start date:
2020-06-03
Due date:
% Done:

0%

Estimated time:
Difficulty:

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

Actions #1

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.
Actions #2

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

Actions #3

Updated by SLindoMansilla almost 4 years ago

  • Assignee set to szarate
  • Target version set to Milestone 30
Actions

Also available in: Atom PDF