Project

General

Profile

Actions

action #96281

closed

coordination #96302: [qe-core][QU] Quarterly update failures

[qem] test fails in first_boot

Added by hurhaj over 2 years ago. Updated over 2 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Bugs in existing tests
Target version:
-
Start date:
2021-07-29
Due date:
% Done:

0%

Estimated time:
Difficulty:

Description

Observation

  • after user login the prompt for root passwd pops up to refresh repos; probably "PackageKit[4674]: uid 1000 is trying to obtain org.freedesktop.packagekit.system-sources-refresh auth (only_trusted:0)"

openQA test in scenario sle-15-SP3-Online-QR-s390x-btrfs_libstorage-ng@s390x-zVM-vswitch-l3 fails in
first_boot

Test suite description

Maintainers: QSF-y.

Test installation with btrfs filesystem and libstorage-ng.
Validates no_COW attributes on subvolumes, file system on partitions, checks whether /home is on separate partition or not (depending on the system).

Reproducible

Fails since (at least) Build 188.13 (current job)

Expected result

Last good: 188.11 (or more recent)

Further details

Always latest result in this scenario: latest

Actions #1

Updated by szarate over 2 years ago

  • Parent task set to #96302

Setting to parent task to have a common tracker

Actions #2

Updated by oorlov over 2 years ago

  • Status changed from New to Feedback

So, this is known issue, related to s390x: https://bugzilla.suse.com/show_bug.cgi?id=1177446

Even though we tried to catch such cases and avoid them using the workaround, they sometimes happened.

So, restart helped that time, but we probably need to decide if we want to keep such flacky test suite in updates job group, or decide to make the workaround to be more solid.

Passed job: https://openqa.suse.de/tests/6618179

Actions #3

Updated by hurhaj over 2 years ago

oorlov wrote:

we probably need to decide if we want to keep such flacky test suite in updates job group, or decide to make the workaround to be more solid.

Reading (quickly) through the bug, it looks like this problem appeared in different tests/suites and that it was intentional with the setup that was used. Rather than changing the setups and hoping no one will ever create new one just like that, I would vote for improving the workaround.

Thanks for looking into it so quickly!

Actions #4

Updated by oorlov over 2 years ago

  • Assignee set to oorlov
Actions #5

Updated by oorlov over 2 years ago

  • Status changed from Feedback to Resolved
Actions

Also available in: Atom PDF