-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Let's test fedora-42 #21607
Let's test fedora-42 #21607
Conversation
9c68d69
to
cfb51d6
Compare
It's actually all the same issue: we expect to see a hostkey prompt when connecting to a secondary host and we don't see it. The obvious thing that would be wrong here is that we're not checking keys properly, but we're also failing in one of the tests to login with the expected credentials, which suggests to me that we're somehow not ending up on the expected host... |
Nope. It's not actually because of a bad username or password. That's just the generic error that's printed when cockpit-ws doesn't know why auth failed. The real reason is this:
from |
The actual failing syscalls:
turning selinux enforcing off fixes it, predictably. |
@allisonkarlitskaya This is https://issues.redhat.com/browse/RHEL-72967 which apparently affects Fedora 42 as well. We need a hack similar to cockpit-project/bots@eb3cedd2d on the f-42 image. |
@martinpitt the issue should be fixed with latest systemd Also this has been backported to systemd-v257-stable branch and it should appear in Fedora once @keszybz does the rebase. |
We added the workaround via bots (and it just went green), so let's close this one. |
Thanks @msekletar , great to hear! |
No description provided.