-
Notifications
You must be signed in to change notification settings - Fork 36
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
network tests specifying device name failing (timeout) on Fedora 42 iso built by Anaconda PR CI github workflow #1372
Comments
rvykydal
added a commit
to rvykydal/anaconda
that referenced
this issue
Feb 27, 2025
diff of
indicates what might be the issue. PRs to fix the label: |
rvykydal
added a commit
to rvykydal/anaconda
that referenced
this issue
Feb 27, 2025
rvykydal
added a commit
to rvykydal/anaconda
that referenced
this issue
Feb 27, 2025
Fixed |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This concerns also smoke tests containing these failing network tests
network-static-2-httpks
bond2-httpks
In general it hits network tests using
KSTEST_NETDEV<X>
specification.The failure happens early in initramfs so nothing can be seen in the logs:

It works on regular F42 boot.iso, it fails on iso created by this workflow: https://github.com/rhinstaller/anaconda/actions/runs/13372582869/workflow
The problem is network device naming scheme which is set by libvirt by os detection so it seems it fails on the iso built by the workflow.
enpXxY
is expected whileensX
is used.This issue has quite some history it might be good idea to search in git history or in closed issues.
Maybe we need to migrate our runners to Fedora-Cloud-Base-40 (similar to https://gitlab.cee.redhat.com/rhinstaller/builders/-/commit/c06f7b8c4c853de61b064b439e524cbfe99650ff) to be able to detect F42 correctly, but why the detection seems to be working on regular F42 boot iso?
I briefly checked the iso volume id, it seems correct, but the mechanism works probably on a bit different level.
The text was updated successfully, but these errors were encountered: