action #131051
closed[openQA-in-openQA] test fails in openqa_worker: python310 vs python311
0%
Description
Observation¶
TW changed default python version to python311, we should adapt.
openQA test in scenario openqa-Tumbleweed-dev-x86_64-openqa_install+publish@64bit-2G fails in
openqa_worker
Test suite description¶
Maintainer: okurz@suse.de Test for installation of openQA itself. To be used with "openqa" distri. Publishes an qcow2 image including the openQA installation ready to run as an appliance.
Reproducible¶
Fails since (at least) Build :TW.20998
Expected result¶
Last good: :TW.20997 (or more recent)
Further details¶
Always latest result in this scenario: latest
Updated by okurz over 1 year ago
I thought maybe the problem would be triggered by us using a too old qcow image vs. the repos but shouldn't it be the other way around because we use a qcow image from the next to be published snapshot? I wonder if we can prevent that problem by the right combination of zypper calls. Or maybe we just need to wait two days for stuff to be in sync again
Updated by jbaier_cz over 1 year ago
The initial failure is gone (as expected), there is a new one which might be connected. I am noting down the problem for future investigation:
[ 357.522724] login[5763]: gkr-pam: error looking up user information
[ 364.021352] login[5763]: pam_unix(login:auth): check pass; user unknown
[ 364.022969] login[5763]: pam_unix(login:auth): authentication failure; logname=LOGIN uid=0 euid=0 tty=/dev/tty3 ruser= rhost=
[ 365.903163] login[5763]: FAILED LOGIN 1 FROM tty3 FOR (unknown), User not known to the underlying authentication module
Updated by jbaier_cz over 1 year ago
- Status changed from New to Resolved
- Assignee set to jbaier_cz
Or maybe we just need to wait two days for stuff to be in sync again
Two days are over and stuff is in sync :)
As expected, now we use the right OS image with the right python version and everything seems to be green again. We do not need to continue further with this ticket.