Fedora Account System
Red Hat Associate
Red Hat Customer
== Comment: #0 - Sven Schnelle <Sven.Schnelle> - 2026-10-05 01:17:38 == Fedora 45 Beta cannot be installed on s390 - The ip= kernel commandline seems to be ignored and no network interface is configured during installation, so tessia installation cannot proceed. I reported this to Dan Horak.
------- Comment From Sven.Schnelle 2026-10-09 01:49 EDT------- Adding 'rd.net.dns-backend=dnsconfd' to the kernel command line seems to fix installation - but I don't know whether this is intended (or should be default).
I suspect this is a bug in the installer and very likely not specific to s390x. Reassigning to anaconda.
It seems the dnsconfd service is running, even though it's not necessary for eDNS. This might interfere with the NetworkManager service. I'm reassigning this bug to dnsconfd to investigate further. Logs from initramfs will be attached.
FEDORA-2026-2de5da4750 (Fix dnsconfd un-requested start in installer initramfs) has been submitted as an update to Fedora 45. https://bodhi.fedoraproject.org/updates/FEDORA-2026-2de5da4750
Proposed as a Blocker and Freeze Exception for 45-final by Fedora user tkorbar using the blocker tracking app because: This bug causes installation failures on machines that mention `ip=` in their kernel commandline arguments. Update https://bodhi.fedoraproject.org/updates/FEDORA-2026-2de5da4750 fixes it and it was verified by the installer maintainer.
The issue here was caught pretty spot on. Dnsconfd is not supposed to start and take-over /etc/resolv.conf unless it is requested to do so with the kernel argument. This caused the problem during installation and is a regression between fedora 44 and 45, caused by rebase to version 2 i did in f45. Shame that the problem was caught so late.
I tested this on both the x86_64 Beta 1.3 and Final RC 1.2 images, and it worked for me on the x86_64 architecture. I am not able to try on s390. I added `ip=…`, `nameserver=…`, and `rd.neednet=1` to the kernel command line in GRUB to configure a static IP address, gateway, and DNS server. The VM used the host’s NAT network. After installation, I checked the IP address, default route, and DNS settings using `ip` and `nmcli`. I also checked the NetworkManager connection profile and tested internet access with `curl`. The settings appeared to be correct, but I am not completely sure whether I followed the procedure correctly or checked everything needed. The settings, I was using, were ip=192.168.122.50::192.168.122.1:255.255.255.0:fedora:enp1s0:none nameserver=192.168.122.1 rd.neednet=1
For the record, the fix is https://github.com/InfrastructureServices/dnsconfd/commit/570025c95c578df69cc543b3a2c316312d7fb370 . Perhaps the current state is a race between dnsconfd and NetworkManager so it sometimes works and sometimes does not?
yes, Tomas mentioned to me that it's a race condition, for some reason being hit on s390x much more frequently than on other platforms.
Do we know why? The thing is, if it's only commonly encountered on s390x it's probably not a blocker because s390x is not a release-blocking arch. So it does kinda matter. It would be good to know how likely this is to occur on x86_64 or aarch64.
One of the workarounds is the rd.net.dns-backend=dnsconfd option. However that has some networking implications that might not work everywhere (I won't speculate, I'm not a networking guy). We could also build an updates image as a workaround in case F45 is GO tonight, but I'm not completely sure if it would work or not (does the fix also need to affect initramfs?).
Yeah, I don't think that would work. I think the fix is in the initramfs, and updates images are applied during initramfs stage and don't change its state :\
> Tomas mentioned to me that it's a race condition, for some reason being hit on s390x much more frequently than on other platforms Does this mean the race actually *goes the wrong way* more often on s390x, or that Beaker-based testing *enter the race more often* on s390x (because of s390x-specific network requirements in Beaker) and thus sees it get lost more often on s390x?
I believe I can reproduce this one. in beaker, s390x systems always need some 'ip=' parameter because of their specific networking requirements. And ignoring this kernel param is frequently more for s390x? Simply provisioning s390x F44 or Fedora-Rawhide-20261007.n.0 via Beaker Workflow : https://beaker.engineering.redhat.com/reserveworkflow I scheduled 10x F44 and 10x Fedora-Rawhide-20261007.n.0. While most of the F44 installations succeeded, every single Fedora-Rawhide-20261007.n.0 installation failed. console.log: [12.813050] curl: (6) Could not resolve host: beakerpy3.engineering.redhat.com [12.813151] Warning: Problem : timeout. Retrying in 1 second. 3 retries left. [19.823873] Warning: anaconda: failed to fetch kickstart from http://beakerpy3.engineering.redhat.com/kickstart/1200449092 ... [235.411023] curl: (6) Could not resolve host: beakerpy3.engineering.redhat.com [235.412188] Warning: anaconda: failed to fetch kickstart from http://beakerpy3.engineering.redhat.com/kickstart/1200449092 https://beaker.engineering.redhat.com/jobs/1200336959 https://beaker.engineering.redhat.com/jobs/1200336960 https://beaker.engineering.redhat.com/jobs/1200336928 https://beaker.engineering.redhat.com/jobs/1200337026
Discussed at F45 Go/No-Go meeting #2, acting as a blocker review meeting: https://meetbot-raw.fedoraproject.org/meeting_matrix_fedoraproject-org/2026-10-22/f45-final-go-no-go-meeting.2026-10-22-17.00.html . Rejected as a blocker on the basis that initial testing indicates it's not sufficiently reproducible on release-blocking arches (aarch64, x86_64). The release has been slipped for other reasons, however, so we may still be able to include the fix for this if it's accepted as an FE; please vote at https://forge.fedoraproject.org/quality/blocker-review/issues/2238 .
+3 FE in https://forge.fedoraproject.org/quality/blocker-review/issues/2238 , marking accepted.
FEDORA-2026-2de5da4750 has been pushed to the Fedora 45 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-2de5da4750` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-2de5da4750 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.