action #20824
closed
coordination #20580: [sle][functional][epic] sle 15 setup
[sles][functional] test fails in change_desktop - Failed to select default product pattern, later then fails with booting into wrong session
Added by SLindoMansilla almost 7 years ago.
Updated over 6 years ago.
Category:
Bugs in existing tests
Description
Observation¶
openQA test in scenario sle-15-Leanos-DVD-aarch64-btrfs@aarch64 fails in
change_desktop
Failed to select default product pattern.
The test should be workaround.
Reproducible¶
Fails since (at least) Build 65.1
Expected result¶
Last good: (unknown) (or more recent)
Further details¶
Always latest result in this scenario: latest
- Target version set to Milestone 10
okurz and me decided that we need a new test variable SLE_PRODUCT that should default to server and from this one we can derive the default desktop (SLES -> gnome, LeanOS -> textmode). Should default to server, we can override that in medium settings and we can override that in leanos specific test suites.
- Assignee changed from SLindoMansilla to okurz
- Subject changed from [sles][functional] test fails in change_desktop - Failed to select default product pattern to [sles][functional] test fails in change_desktop - Failed to select default product pattern, later then fails with booting into wrong session
So what we can do now is to specify the test variable setting SLE_PRODUCT=leanos on testsuites where we want to mainly cover the installation workflow without needing registration, e.g. "yast_hostname". In the end we should have a good coverage of all products, that is currently sles, sled, leanos. We can switch some of the existing ones over to leanos and for some we probably need a duplication of either the testsuites (e.g. create_hdd_sled) and for some we can define a variant using a new MACHINE type where the SLE_PRODUCT is set differently
I set ext4 and yast_hostname+linuxrc_hostname with SLE_PRODUCT=leanos for the sake of permutation testing and proceeding further in tests.
Waiting for these two tests to finish.
Basically the original ticket is considered done, continuing now with "fails to boot with wrong session". We have the following options:
- As workaround we could set SLE_PRODUCT=leanos, pass the "first_boot" in textmode, then test will fail in some console test, extend leanos test from there, file bugs about missing parts, exclude all not-applicable modules for a complete test of leanos
- Add ADDONURL=… as in "create_hdd_sle15" to provide all dependencies as workaround which is related to #20984
- Register all SLES tests to be more or less on where we have been in before with our tests, e.g. having access to full SLES with all its packages, blocked by #23492
- Status changed from In Progress to Feedback
- Parent task set to #20580
- Status changed from Feedback to In Progress
- Assignee deleted (
okurz)
- Priority changed from Normal to Urgent
How is this in progress while there is no Assignee? :)
To make matter more interesting the prio is: urgent
good you found this ticket. The status "In Progress" is correct according to our ticket workflow because it is considered a workable item and work had started on it already in before. Why there is no assignee is also a point I raised in offline meetings but so far no one signed up to continue work on it except for me who made some proposals about how to continue.
- Status changed from In Progress to Resolved
- Assignee set to okurz
I reviewed all jobs currently labeled with this ticket and in most cases I found that actually the problem is that we should have never reached the "first_boot" module with unregistered SLES. So I labeled all jobs instea dwith bsc#1055023 which is corresponding to that. When the bug is resolved and we need to register we should put the registration details into the medium.
Also available in: Atom
PDF