Project

General

Profile

action #96281

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

[qem] test fails in first_boot

Added by hurhaj about 2 months ago. Updated about 2 months 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

History

#1 Updated by szarate about 2 months ago

  • Parent task set to #96302

Setting to parent task to have a common tracker

#2 Updated by oorlov about 2 months 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

#3 Updated by hurhaj about 2 months 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!

#4 Updated by oorlov about 2 months ago

  • Assignee set to oorlov

#5 Updated by oorlov about 2 months ago

  • Status changed from Feedback to Resolved

Also available in: Atom PDF