Created attachment 283149 [details] Dmesg for 5.2-rc3 When booting 5.2-rc3 on an arubacloud VPS (running VMware and using the e1000 driver for internet access) no IP address is assigned to eth0 The last working kernel was 5.2-rc2 Systemd-networkd is being used for network setup. Tried networkmanager too. With systemd-networkd no IP address is assigned to eth0. Networkmanager does assign an address to eth0 but there is no internet access Booting 5.2-rc2 or 5.1.7 works with both systemd-networkd and networkmanager without any issues The dmesg for 5.2-rc3 has been attached The kernel configuration can be found here https://emptyclouds.net/anupri/dot.config This is an output of ip addr on 5.2-rc3 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 00:50:56:9f:92:d8 brd ff:ff:ff:ff:ff:ff 3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 00:50:56:9f:e4:53 brd ff:ff:ff:ff:ff:ff 4: eth2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 00:50:56:9f:31:a5 brd ff:ff:ff:ff:ff:ff Same thing but with 5.2-rc2 (or 5.1.7 as the output is the same for both) 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc cake state UP group default qlen 1000 link/ether 00:50:56:9f:92:d8 brd ff:ff:ff:ff:ff:ff inet 217.61.104.90/24 brd 217.61.104.255 scope global eth0 valid_lft forever preferred_lft forever inet6 2a03:a140:10:2c5a::1/64 scope global valid_lft forever preferred_lft forever inet6 fe80::250:56ff:fe9f:92d8/64 scope link valid_lft forever preferred_lft forever 3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 00:50:56:9f:e4:53 brd ff:ff:ff:ff:ff:ff 4: eth2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 00:50:56:9f:31:a5 brd ff:ff:ff:ff:ff:ff ip link on 5.2-rc3 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether 00:50:56:9f:92:d8 brd ff:ff:ff:ff:ff:ff 3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether 00:50:56:9f:e4:53 brd ff:ff:ff:ff:ff:ff 4: eth2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether 00:50:56:9f:31:a5 brd ff:ff:ff:ff:ff:ff [root@archlinux ~]# ip link 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc cake state UP mode DEFAULT group default qlen 1000 link/ether 00:50:56:9f:92:d8 brd ff:ff:ff:ff:ff:ff 3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether 00:50:56:9f:e4:53 brd ff:ff:ff:ff:ff:ff 4: eth2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 ip link on 5.2-rc2 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc cake state UP mode DEFAULT group default qlen 1000 link/ether 00:50:56:9f:92:d8 brd ff:ff:ff:ff:ff:ff 3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether 00:50:56:9f:e4:53 brd ff:ff:ff:ff:ff:ff 4: eth2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether 00:50:56:9f:31:a5 brd ff:ff:ff:ff:ff:ff
Note that I'm fine with sharing the IP address of the server
The "[root@archlinux ~]# ip link" line is the IP link command performed on the 5.1.7 stable kernel
Stephen, any updates on this? I've been working towards bisecting it but debugging a remote server is slightly hard
(7dc2bccab0ee) $ git bisect bad 7dc2bccab0ee37ac28096b8fcdc390a679a15841 is the first bad commit commit 7dc2bccab0ee37ac28096b8fcdc390a679a15841 Author: Maxim Mikityanskiy <maximmi@mellanox.com> Date: Tue May 21 06:40:04 2019 +0000 Validate required parameters in inet6_validate_link_af inet6_set_link_af requires that at least one of IFLA_INET6_TOKEN or IFLA_INET6_ADDR_GET_MODE is passed. If none of them is passed, it returns -EINVAL, which may cause do_setlink() to fail in the middle of processing other commands and give the following warning message: A link change request failed with some changes committed already. Interface eth0 may have been left with an inconsistent configuration, please check. Check the presence of at least one of them in inet6_validate_link_af to detect invalid parameters at an early stage, before do_setlink does anything. Also validate the address generation mode at an early stage. Signed-off-by: Maxim Mikityanskiy <maximmi@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net> net/ipv6/addrconf.c | 57 ++++++++++++++++++++++++++++++++--------------------- 1 file changed, 35 insertions(+), 22 deletions(-)
After a quick search for the commit sha# it seems this has been reported before here https://www.mail-archive.com/netdev@vger.kernel.org/msg300190.html https://bugzilla.kernel.org/show_bug.cgi?id=203769 https://bugzilla.redhat.com/show_bug.cgi?id=1718192
No idea. Kernel bugzilla is write only. You should contact the Intel developers.
Thanks Stephen. I have mailed the people who are maintaining the affected file
After rebuilding systemd from git myself the issue has been resolved Further reading makes me believe this was a systemd bug and not a kernel bug at all