Bug 1566502

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.

[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

> 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...

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.

(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!!