Bug 1727411

Summary: NetworkManager 1.20.0-0.3.fc31 seems to ignore newly-created ifcfg-eth0 on service restart, using "Wired connection 1" instead
Product: [Fedora] Fedora Reporter: Adam Williamson <awilliam>
Component: NetworkManagerAssignee: Lubomir Rintel <lkundrak>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: rawhideCC: bgalvani, dcbw, fgiudici, gnome-sig, john.j5live, lkundrak, mclasen, rhughes, rstrode, sandmann, thaller
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard: openqa
Fixed In Version: NetworkManager-1.20.0-0.4.fc31 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-07-08 16:15:02 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
logs from a failed test (includes some diagnostic output, then a dump of the journal) none

Description Adam Williamson 2019-07-05 23:35:16 UTC 
In yesterday's Rawhide openQA tests, a bunch of tests which rely on using static network configs failed. All these tests do basically the same thing: they boot with 'net.ifnames=0' to ensure the interface is called 'eth0', write a static config to /etc/sysconfig/network-scripts/ifcfg-eth0 (I believe that until this point, that file *does not exist at all*), and restart NetworkManager with 'systemctl restart NetworkManager.service'. This has always worked fine before, right up to Fedora-Rawhide-20190703.n.0 , which had NetworkManager 1.20.0-0.2.fc31 .

In Fedora-Rawhide-20190704.n.1 , though, with NetworkManager 1.20.0-0.3.fc31 , it appears not to work. When NM is restarted, it appears to ignore the static configuration written in the file and try to get an IP address via DHCP, which does not work; the system thus has no working network connection and the test fails as soon as it tries to do anything via the network.

Here is one example of such a failed test:

https://openqa.fedoraproject.org/tests/419105

I will attach the logs from the test - when the network is unavailable, the tests are set to dump out some diagnostics via the serial port, so we get it all in one big file from monitoring the serial port.

Adding an 'nmcli connection reload' between the saving of the file and the reload of NetworkManager.service does not appear to help. 'nmcli con show' seems to show we are using "Wired connection 1" not "System eth0" for some reason.

Doing 'systemctl down "Wired connection 1"; systemctl down "System eth0"; systemctl up "System eth0"' *does* seem to work around the problem, so I think I'll hack openQA up to do that for now...
Comment 1 Adam Williamson 2019-07-05 23:37:27 UTC 
So basically my best bet is that what's going on here is, if ifcfg-(whatever) doesn't exist on startup so NM creates a "Wired connection" for it automatically, but then ifcfg-(whatever) is created *after that*, NM won't switch from "Wired connection X" to "System (whatever)" on restart any more, it just sticks with "Wired connection X"? Just my guess, anyway.
Comment 2 Adam Williamson 2019-07-05 23:38:36 UTC 
Created attachment 1587870 [details]
logs from a failed test (includes some diagnostic output, then a dump of the journal)
Comment 3 Adam Williamson 2019-07-05 23:45:35 UTC 
Gah, this paragraph is wrong of course:

"Doing 'systemctl down "Wired connection 1"; systemctl down "System eth0"; systemctl up "System eth0"' *does* seem to work around the problem, so I think I'll hack openQA up to do that for now..."

I meant 'nmcli con down' and 'nmcli con up', not 'systemctl down' and 'systemctl up', so it should read:

"Doing 'nmcli con down "Wired connection 1"; nmcli con down "System eth0"; nmcli con up "System eth0"' *does* seem to work around the problem, so I think I'll hack openQA up to do that for now..."
Comment 4 Lubomir Rintel 2019-07-08 16:15:02 UTC 
Thanks for the report.

The fixed package NetworkManager-1.20.0-0.4.fc31 is now being built.

https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commit/c6106672861f9a188469f7e490cc38af60943a10
Comment 5 Adam Williamson 2019-08-08 15:47:21 UTC 
This same problem seems to be back with 1.20.0-0.5.fc31 and later, but the cause must be different. Filed https://bugzilla.redhat.com/show_bug.cgi?id=1739148 .