Fedora Account System
Red Hat Associate
Red Hat Customer
This is a lot like https://bugzilla.redhat.com/show_bug.cgi?id=1727411 , only...it's not the same cause, obviously. (I checked, that bug didn't revert). Just as in that bug, it seems like with NetworkManager 1.20.0-0.5 (and 1.20.0-1) in recent Rawhide, dropping an ifcfg-eth0 in /etc/sysconfig/network-scripts and restarting NetworkManager.service does not cause the new config to be used. Instead the auto-generated "Wired connection 1" profile is used (not "System eth0" as you'd expect). Again just as with that bug, doing: nmcli con down "Wired connection 1" nmcli con down "System eth0" nmcli con up "System eth0" seems to work around the issue. This broke between 20190730.n.0 (which had NetworkManager-1.20.0-0.4.1) and 20190802.n.0 (which had NetworkManager 1.20.0-0.5), so the newer NM build definitely seems to be the issue. If I was a betting man, I'd bet https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commit/d35d3c468a304c3e0e78b4b068d105b1d753876c is the cause of this, but it's only a guess. I'll try bisecting it in a bit.
Created attachment 1601866 [details] logs from an affected boot various diagnostics/log dumps from an affected boot are in this file (when the network isn't working, openQA dumps them out over the serial line). The system is booted with 'biosdevname=0 net.ifnames=0', ensuring the network adapter appears as eth0. On boot NM tries to bring up the network with an auto-generated connection as 'Wired connection 1', which won't work as in this particular test setup there is no DHCP server available. Then the test drops in an /etc/sysconfig/network-scripts/ifcfg-eth0 file with static configuration and runs "systemctl restart NetworkManager.service", around 06:13:12 . At that point the network should come up successfully as "System eth0", but it does not.
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle. Changing version to '31'.
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle. Changing version to 31.
Ping?
Yes, it seems that after https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commit/d35d3c468a304c3e0e78b4b068d105b1d753876c the default wired connection is saved in "/var/run/NetworkManager/system-connections/Wired connection 1.nmconnection" and reused after the daemon restarts instead of preferring the persistent profile. While this is a change in behavior from the past, it makes some sense to me because restarting NM has never been the proper way to reapply changes to profiles; the idea is that restarting NM should be non disruptive and keep the previous network configuration. If a change in connections is available, it must be explicitly indicated to NM through a reactivation of the desired profile.
but...when I filed https://bugzilla.redhat.com/show_bug.cgi?id=1727411 one month before this bug, which had exactly the same symptom, it was fixed as a bug.
Ping? There's a possibly-related issue we keep running to in infra, as well, where even if we write an ifcfg-eth0 with `NM_CONTROLLED=yes` and `ONBOOT="no"`, NetworkManager brings the interface up anyway under a profile named "Wired Connection" or "Wired Connection 1"...
(In reply to Adam Williamson from comment #7) > Ping? There's a possibly-related issue we keep running to in infra, as well, > where even if we write an ifcfg-eth0 with `NM_CONTROLLED=yes` and > `ONBOOT="no"`, NetworkManager brings the interface up anyway under a profile > named "Wired Connection" or "Wired Connection 1"... it would be most helpful to see full level=TRACE logs. Otherwise it's hard from the description to understand whether NM activated the profile that it was supposed to activated (or why not). The log from comment 1 doesn't have debug logs. But in general, it's as Beniamino says: restarting NetworkManager is not the way to make changes to your network. Restarting NetworkManager should be seldom necessary, and if you commonly restart the daemon, you either do it wrong or you know why you are doing it (and understand the effects that it has). > but...when I filed https://bugzilla.redhat.com/show_bug.cgi?id=1727411 one month before this bug, which had exactly the same symptom, it was fixed as a bug. Well... there was a real bug which was fixed under as 1727411. The bug was that NM would under some circumstances wrongly create the "Wired connection #". It is assumed that the reported issue was caused by the fixed bug. If that's not the case, there might be yet another bug. However, from the present information I cannot say that.
This message is a reminder that Fedora 31 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '31'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 31 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 31 changed to end-of-life (EOL) status on 2020-11-24. Fedora 31 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.