`systemctl start network-online.target` should suffice to start
"NetworkManager.service".
That would work because
- "network-online.target" has "Wants=NetworkManager-wait-online.service"
- "NetworkManager-wait-online.service" has "Require=NetworkManager.service".
But previously, "NetworkManager-wait-online.service" would just
fail with missing dependency.
See also https://github.com/systemd/systemd/pull/6065 which does the
same for networkd's wait-online serice, and see rh#1452866 for a
use-case.
Related: https://bugzilla.redhat.com/show_bug.cgi?id=1452866
(cherry picked from commit 28b97f02f6)
Since commit d61eaf2545 ("service: don't
install dependency for "NetworkManager-wait-online.service" to
"network-online.target.wants") we no longer install NM-w-o.service
in "network-online.target.wants" directory.
Obviously, for previous RPM versions NM-w-o.service was always enabled.
For current versions, it depends now on the preset. Most importantly,
this allows the user to disable the service, without masking it.
Previously NM-w-o.service was always implicitly enabled.
But presets are not applied during package upgrade, so it means that
after upgrade the service will be disabled. Hack around that via an RPM
scriptlet.
https://bugzilla.redhat.com/show_bug.cgi?id=1455704
(cherry picked from commit 513d0c2286)
The function should not close the input file descriptor; however
fdopen() associates the fd to the new stream so that when the stream
is closed, the fd is too. The result is a double close() and the
second call can in certain cases affect a wrong fd.
Use a duplicate fd for the stream.
Fixes: 1d9bdad1dfhttps://bugzilla.redhat.com/show_bug.cgi?id=1451236
(cherry picked from commit 597072296a)
The bus manager takes extra references to the GDBusConnection every
time g_dbus_object_manager_server_get_connection() its called,
preventing its disposal once the connection is closed. This causes a
leak for each DHCP event.
https://bugzilla.redhat.com/show_bug.cgi?id=1461643
(cherry picked from commit 5b81d40338)
If unrealize() failed we returned without thawing notify signals. Fix
this by moving g_object_freeze_notify() after the
unrealization/deletion but before the properties are reset in
unrealize_notify().
Fixes: a93807c288
(cherry picked from commit 24a7f88bc5)
Zero is a valid route metric and distinct from -1, which means unspecified.
Fix reader and writer.
Fixes: e374923bbe
(cherry picked from commit 099be8e4db)
Rename @error to @out_err_str, because @error is usually used for GError
output arguments.
Also, make the string variables "const char *".
Use nm_assert() in read_field(), because it is a static function
with only four call sites. It's easily verified that the assertion
holds, so no need for a run-time check in production builds.
(cherry picked from commit 29e9b567f0)
Currently, after a client performs a connectivity check it cannot
access the up-to-date value of the manager.connectivity property right
away, but it must wait that the queued PropertiesChanged signal is
processed, which is cumbersome.
Arguably, clients already receive the new connectivity value as the
result of the connectivity check call, so they don't have to read it
from the object; however it would be better if the right value of the
object property was available immediately as well.
https://bugzilla.gnome.org/show_bug.cgi?id=784629
(cherry picked from commit b799de281b)
Since commit 6845b9b80a ("device: delay
startup complete until device is initialized in platform", we also wait
for devices that are still initializing platform/UDEV.
Obviously, that only applies to realized devices.
Otherwise, an unrealized device is going to block startup complete.
Fixes: 6845b9b80a
(cherry picked from commit 9ad8010fe0)
GNOME Settings 3.26 is crashing every time a VPN connection changed its
state. After some digging, a debug message was put on dispose, and this
issue was found:
libnm-Message: Object 0x55555633c070 disposed
libnm-Message: Object 0x55555633c730 disposed
libnm-Message: Object 0x55555633eae0 disposed
libnm-Message: Object 0x555556340a80 disposed
Thread 1 "gnome-control-c" received signal SIGSEGV, Segmentation fault.
g_type_check_instance_cast (type_instance=type_instance@entry=0x55555633c070, iface_type=93825006537856) at /.../glib/gobject/gtype.c:4057
4057 node = lookup_type_node_I (type_instance->g_class->g_type);
(gdb) bt
NetworkManager is calling callbacks on disposed objects, which leads to
crashes in clients (e.g. GNOME Settings).
Fix this issue by disconnecting signal handlers when the objects are
disposed.
Patch originally by Georges Basile Stavracas Neto <georges.stavracas@gmail.com>
https://bugzilla.gnome.org/show_bug.cgi?id=787893
(cherry picked from commit b18896f770)
This isn't useful for contrib/fedora/rpm itself because here
the __SOURCE__ gets set by the build scripts.
But this spec file is copied to Fedora downstream where the
SOURCE URL is used.
(cherry picked from commit 85e3f956ad)
A newer compiler version might emit some warnings and break the build
of the RPM. Of course, such warnings must be fixed. But it is still very
inconvenient to break the build of an old RPM version without easy workaround.
When building without "test" (which is on by default), don't use fatal warnings
for compilation.
(cherry picked from commit 7d00a96d23)
'nmcli device wifi connect' only supports WEP and WPA-PSK at the
moment, but not WPA-EAP. If the AP supports both WPA-PSK and WPA-EAP,
nmcli doesn't add the PSK to the connection, causing a connection
failure. Fix this.
https://bugzilla.redhat.com/show_bug.cgi?id=1492064
(cherry picked from commit 7af471919a)
the --timeout command line option is a custom feature added in some
linux distributions (fedora). Passing that command line argument will
make dhclient fail if the binary does not support it, preventing
activation of dhcp based connections.
Worse, the option has just been recently changed from "-timeout", so
that we are currently incompatibile with Centos, RedHat and older
versions of Fedora too.
Leverage the "timeout" option in dhclient config file: it will produce
the expected behavior and will be universally supported.
Fixes test: dhcp-timeout
Fixes: fa46736013https://bugzilla.redhat.com/show_bug.cgi?id=1491243
(cherry picked from commit 1cb4832f09)
A typo in the new dhcp-timeout option caused the dhclient daemon to exit
with error when the dhcp-timeout option was specified.
This prevents dhcp connection to be upped.
Fixes: 82ef497cc9
(cherry picked from commit fa46736013)
When comparing a platform route with a route from configuration, we
must translate the value of rt_source.
This fixes CI test @ipv6_preserve_cached_routes
If the slave is 'external' we should never touch it, in particular we
should not release the link from its master; we only have to remove it
from master's list.
https://bugzilla.redhat.com/show_bug.cgi?id=1442361
(cherry picked from commit 981f90e324)
Previously, if a master device had internal state 'managed', we would
promote the slave to 'managed' as well. However,
- if the slave is 'external', it should stay as is because we don't
want to start managing it
- if the slave is 'assumed', it will become managed when the
activation succeeds, so it's not necessary to do it here
Fixes: 850c977953
(cherry picked from commit 9e99590508)
If we install "NetworkManager-wait-online.service" in the
"network-online.target.wants" directory, network-online.target always
pulls in NetworkManager-wait-online.service. As it was, it could only
be disabled by masking the service.
Instead, we should enable NetworkManager-wait-online.sevice via
systemd's preset. That is already done for Fedora 26 and newer.
Note that NetworkManager-wait-online.sevice already has Install.WantedBy.
This way, the dependency is created automatically when enabling the service.
https://bugzilla.redhat.com/show_bug.cgi?id=1455704
(cherry picked from commit d61eaf2545)
Previously, the --quick option only mattered when creating
the source tarball, to run `make dist` instead of the slower
`make distcheck`.
Extend its meaning to also skip unit tests while building the RPM.
You still can enable them with
$ ./contrib/fedora/rpm/build_clean.sh -Q -w test
(cherry picked from commit c528a89519)
Software devices don't have a permanent hardware address and thus it
doesn't make sense to enforce the 'fake' (generated) permanent one
when cloned-mac-address=permanent. Also, setting the fake permanent
address on bond devices, prevents them from inheriting the first slave
hardware address, so let's just skip the setting of MAC when
cloned-mac-address=permanent and there is no real permanent address.
https://bugzilla.redhat.com/show_bug.cgi?id=1472965
(cherry picked from commit 2f4dfd0f2e)
