action #165800
closedtest fails in firstrun - New window to handle
0%
Description
Observation¶
openQA test in scenario opensuse-Tumbleweed-JeOS-for-RPi-aarch64-jeos@RPi3 fails in
firstrun
It seems there is a new window to handle
User Creation > you have to enter a password
Test suite description¶
Maintainer: fvogt
Start JeOS from the HDD image, configure it using the firstboot wizard and then run basic tests. console=tty0 added as needed for aarch64.
Reproducible¶
Fails since (at least) Build 20240825 (current job)
Expected result¶
Last good: 20240709 (or more recent)
Further details¶
Always latest result in this scenario: latest
Files
Updated by pvorel 3 months ago
FYI there is an error message:
https://openqa.opensuse.org/tests/4440137#step/firstrun/15
Invalid username.
Make sure it starts with a lowercase
letter and only contains -, _, digits and
lowercase letters.
Which was not on the previous run (build 20240709)
https://openqa.opensuse.org/tests/4329198#step/firstrun/14
It looks like we really pass wrong username.
Updated by pvorel 3 months ago
On https://openqa.opensuse.org/tests/4440137/video?filename=video.webm 0.11 there is "echo 0idMV-$?clear" in username.
Obviously openQA bug.
Updated by pvorel 3 months ago
I tried to verify if https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/19964 caused the problem, but reverting does not help.
https://openqa.opensuse.org/tests/overview?build=test-poo165800
Updated by mloviska 3 months ago
Just a wild guess, but isn't it a worker problem? This test works https://openqa.opensuse.org/tests/4440120#step/firstrun/13, maybe the generalhw workers have old test code repo?
Updated by ggardet_arm 3 months ago
mloviska wrote in #note-6:
Just a wild guess, but isn't it a worker problem? This test works https://openqa.opensuse.org/tests/4440120#step/firstrun/13, maybe the generalhw workers have old test code repo?
Indeed, the code repo stalled, so I fixed it.
Let's see how a restarted test goes: https://openqa.opensuse.org/tests/4442619
Updated by ggardet_arm 3 months ago
Still fails, but in a different way: https://openqa.opensuse.org/tests/4442619#step/firstrun/15
Updated by mloviska 3 months ago
https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/20097
I have noticed the default password is different from what we tend to use in other cases. That causes cracklib-check to fail is the password is too short.
Updated by openqa_review 2 months ago
This is an autogenerated message for openQA integration by the openqa_review script:
This bug is still referenced in a failing openQA test: jeos-container_host@RPi3
https://openqa.opensuse.org/tests/4488589#step/firstrun/1
To prevent further reminder comments one of the following options should be followed:
- The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
- The openQA job group is moved to "Released" or "EOL" (End-of-Life)
- The bugref in the openQA scenario is removed or replaced, e.g.
label:wontfix:boo1234
Expect the next reminder at the earliest in 28 days if nothing changes in this ticket.
Updated by ph03nix about 2 months ago
Issue is still present: https://openqa.opensuse.org/tests/4501612#step/firstrun/15
Updated by mloviska about 2 months ago
So I have added WIZARD_SKIP_USER=1
to the medium
Updated by mloviska about 2 months ago
- Status changed from In Progress to Resolved
as of now the problem has been resolved by skipping the user creation in the UI (hence keeping the previous code path)