|Summary:||nmcli cannot modify interface|
|Product:||Red Hat Enterprise Linux 7||Reporter:||Krist van Besien <kvanbesi>|
|Component:||NetworkManager||Assignee:||sushil kulkarni <sukulkar>|
|Status:||CLOSED NOTABUG||QA Contact:||Desktop QE <desktop-qa-list>|
|Version:||7.5||CC:||atragler, bgalvani, fgiudici, kvanbesi, lrintel, ptalbert, rkhan, sukulkar, thaller, vbenes|
|Fixed In Version:||Doc Type:||If docs needed, set a value|
|Doc Text:||Story Points:||---|
|Last Closed:||2018-04-12 14:37:33 UTC||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Description Krist van Besien 2018-04-12 12:36:49 UTC
Description of problem: Version-Release number of selected component (if applicable): [root@fecmrvmaster01 etc]# yum info NetworkManager Loaded plugins: product-id, search-disabled-repos, subscription-manager Installed Packages Name : NetworkManager Arch : x86_64 Epoch : 1 Version : 1.10.2 Release : 13.el7 Size : 5.0 M Repo : installed From repo : rhel-7-server-rpms Summary : Network connection manager and user applications URL : http://www.gnome.org/projects/NetworkManager/ License : GPLv2+ [root@fecmrvmaster01 etc]# cat /etc/redhat-release Red Hat Enterprise Linux Server release 7.5 (Maipo) How reproducible: always Steps to Reproduce: nmcli con mod "eth1" ip4 "172.16.20.34/24" Actual results: Error: Failed to modify connection 'eth1': No such method 'Update2' Expected results: Interface is modified.
Comment 2 Thomas Haller 2018-04-12 12:48:11 UTC
is it possible that you didn't restart NetworkManager after upgrade? Note that in general, the backward compatibility of NetworkManager's D-Bus API works in the way, that clients may be older than the server, but not the other way around. After doing a major upgrade of NetworkManager (from a version < 1.10 to version 1.10, as happens when upgrading from RHEL-7.4 to RHEL-7.5), you also need to restart NetworkManager.
Comment 3 Vladimir Benes 2018-04-12 12:49:01 UTC
[root@wsfd-netdev34-vm-1 NetworkManager-ci]# nmcli con mod "testeth1" ip4 "172.16.20.34/24" [root@wsfd-netdev34-vm-1 NetworkManager-ci]# echo $? 0 [root@wsfd-netdev34-vm-1 NetworkManager-ci]# nmcli connection show testeth1 |grep ipv4 ipv4.method: auto ipv4.dns: -- ipv4.dns-search: -- ipv4.dns-options: "" ipv4.dns-priority: 0 ipv4.addresses: 172.16.20.34/24 ipv4.gateway: -- ipv4.routes: -- ipv4.route-metric: -1 ipv4.route-table: 0 (unspec) ipv4.ignore-auto-routes: no ipv4.ignore-auto-dns: no ipv4.dhcp-client-id: -- ipv4.dhcp-timeout: 0 (default) ipv4.dhcp-send-hostname: yes ipv4.dhcp-hostname: -- ipv4.dhcp-fqdn: -- ipv4.never-default: no ipv4.may-fail: yes ipv4.dad-timeout: -1 (default) [root@wsfd-netdev34-vm-1 NetworkManager-ci]# rpm -q NetworkManager NetworkManager-1.10.2-13.el7.x86_64
Comment 4 Thomas Haller 2018-04-12 12:54:08 UTC
> Expected results: > > Interface is modified. Sidenote: `nmcli connection modify` modifies the "connection profile" in NetworkManager. A profile is not the same as the networking device (interface) itself, but rather the set of configurations that can be used to configure an interface. As such, `nmcli connection modify` doesn't (usually) modify an "interface". For example, changes to the profile like this would only take effect after re-activating the profile. See `nmcli device modify` to modify the interface only, and `nmcli device reapply` to apply the changes to the profile to the interface...
Comment 5 Krist van Besien 2018-04-12 14:20:09 UTC
It is indeed after an update. Restarting NetworkManager fixed the problem. A better error message would be nicer though. Or that an update of NetworkManager trigers a restart.
Comment 6 Thomas Haller 2018-04-12 14:37:33 UTC
(In reply to Krist van Besien from comment #5) > A better error message would be nicer though. In the past, nmcli complained if the server version was newer. However, while strictly speaking not supported, it often works just fine. That's why the warning about version mismatch was removed. It would be a bit cumbersome to intercept exactly this error reason, figure out that it's likely due to a version mismatch, and print a different warning. Maybe it should be done, but seems low priority to me. > Or that an update of > NetworkManager trigers a restart. package updates commonly don't restart services. That is intentional, because it might interrupt more than help. In general, if you update packages it's up to the admin/user to restart all affected programs. Which, in case of libraries and certain services might be so quite difficult to get right and might even result in restarting large part of your system. Hence, the safest way is to reboot after update. Or even better: do updates during reboot where the upgrade happens in a special environment, like `dnf system-upgrade reboot` on Fedora). I am pretty sure it's not supported to upgrade RHEL-7.4 to 7.5 without booting. Or at least, you may do it, but you need to know what you are doing :) I am closing this. If you disagree, please reopen. Thanks!!