Program received signal SIGSEGV, Segmentation fault.
0x0000555555646b59 in platform_link_added (self=self@entry=0x5555559fe1d0,
ifindex=<optimized out>, plink=plink@entry=0x555555b10a70)
at nm-manager.c:1889
1889 nm_log_warn (LOGD_HW, "%s: factory failed to create device: %s",
(gdb) bt
#0 0x0000555555646b59 in platform_link_added (self=self@entry=0x5555559fe1d0, ifindex=<optimized out>, plink=plink@entry=0x555555b10a70) at nm-manager.c:1889
#1 0x000055555564980c in nm_manager_start (self=0x5555559fe1d0)
at nm-manager.c:1988
#2 0x000055555564980c in nm_manager_start (self=0x5555559fe1d0, error=error@entry=0x7fffffffe658) at nm-manager.c:4212
#3 0x00005555555ae173 in main (argc=1, argv=0x7fffffffe7c8) at main.c:428
(gdb)
On slow virtual machine, these tests could fail because the
timeout was too low. As in a successful run the timeouts should
not be reached anyway, just extend them.
The naming of these logging macros is unexpected, as we use such
macros only here in platform.
For these messages we cannot use the default _LOGD() set of macros,
because there is no @platform instance around. So let's introduce an
alternative set of logging macros (_LOG2D(), etc) and use it.
We already have the macros _LOGD(), _LOGI(), etc. to provide context sensitive
logging (such as printing the object pointer as prefix).
In some implementations, we would like to have a second set of logging
macros, that shall be used differently. For example, use the default
_LOGD() for messages that are explicitly issued by one objects, and use
_LOG2D() in a static context when no object is around.
The "_LOG2" prefix is not great from a naming point of view. However, it is
meant to be a second (alternative) set of logging macros with the same
usage pattern as the _LOGD() macros.
When a new link is detected, NM tries to generate a default "Wired
connection" in nm_settings_device_added(), but if the link has not
been initialized by udev yet the function returns early because
priv->unmanaged_flags = UNMANAGED_PLATFORM_INIT.
To be sure that a default connection is created is such situation, we
need to call again nm_settings_device_added() after link
initialization.
https://bugzilla.redhat.com/show_bug.cgi?id=1254089
Those are not required with systemd-udevd v210 or newer. This way
distros which have a new enough version of udev can skip installing
84-nm-drivers.rules. While at it, don't use absolute paths for sed and
ethtool.
test-dispatcher-envp.c: In function 'test_generic':
test-dispatcher-envp.c:507:3: error: format not a string literal and no format arguments [-Werror=format-security]
Don't disconnect the device when the DHCP renewal fails and there are
already configured static IP addresses on the device. Instead, keep
the device up and try DHCP again after some time.
https://bugzilla.redhat.com/show_bug.cgi?id=1168388
check_if_startup_complete() could be invoked from nm_settings_start() before
devices had chance to be added, which results in premature "startup complete"
and NM would quit when configure-and-quit=yes is set up.
Postpone actual check_if_startup_complete() resolution until we add all devices
and they are processed.
(gdb) bt
#0 0x00005555556401f3 in check_if_startup_complete (self=0x5555559f91d0)
at nm-manager.c:719
#1 0x00007ffff4d69de8 in g_closure_invoke () at /lib64/libgobject-2.0.so.0
#2 0x00007ffff4d7b70d in signal_emit_unlocked_R ()
at /lib64/libgobject-2.0.so.0
#3 0x00007ffff4d83471 in g_signal_emit_valist () at /lib64/libgobject-2.0.so.0
#4 0x00007ffff4d8372f in g_signal_emit () at /lib64/libgobject-2.0.so.0
#5 0x00007ffff4d6e4b5 in g_object_dispatch_properties_changed ()
at /lib64/libgobject-2.0.so.0
#6 0x00007ffff4d709d9 in g_object_notify () at /lib64/libgobject-2.0.so.0
#7 0x00005555556e232c in check_startup_complete (self=self@entry=0x555555a0e130) at settings/nm-settings.c:204
#8 0x00005555556e5203 in nm_settings_start (self=0x555555a0e130, error=error@entry=0x7fffffffe658) at settings/nm-settings.c:2122
#9 0x0000555555646d06 in nm_manager_start (self=0x5555559f91d0, error=0x7fffffffe658) at nm-manager.c:4153
#10 0x00005555555add43 in main (argc=1, argv=0x7fffffffe7c8) at main.c:428
(gdb)
Fixes:Beaker:NetworkManager_Test37_run_once_new_connection
https://bugzilla.redhat.com/show_bug.cgi?id=1256772
Add support for IFLA_LINK_NETNSID to properly handle linked parent
interfaces that reside in another netns.
This requires support of the IFLA_LINK_NETNSID from both the kernel
and libnl3.
https://bugzilla.gnome.org/show_bug.cgi?id=753726
The parent of a link (IFLA_LINK) can be in another network namespace and
thus invisible to NM.
This requires the netlink attribute IFLA_LINK_NETNSID which is supported
by recent versions of kernel and libnl.
In this case, set the parent field to NM_PLATFORM_LINK_OTHER_NETNS
and properly handle this special case.
