Bug 1727411 - NetworkManager 1.20.0-0.3.fc31 seems to ignore newly-created ifcfg-eth0 on service restart, using "Wired connection 1" instead
Summary: NetworkManager 1.20.0-0.3.fc31 seems to ignore newly-created ifcfg-eth0 on se...
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: NetworkManager
Version: rawhide
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Lubomir Rintel
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: openqa
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-07-05 23:35 UTC by Adam Williamson
Modified: 2019-08-08 15:47 UTC (History)
11 users (show)

Fixed In Version: NetworkManager-1.20.0-0.4.fc31
Clone Of:
Environment:
Last Closed: 2019-07-08 16:15:02 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
logs from a failed test (includes some diagnostic output, then a dump of the journal) (164.43 KB, text/plain)
2019-07-05 23:38 UTC, Adam Williamson
no flags Details

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 .


Note You need to log in before you can comment on or make changes to this bug.