[Bug 1660762] Comment bridged from LTC Bugzilla
bugproxy
bugproxy at us.ibm.com
Fri Feb 3 15:39:35 UTC 2017
------- Comment From muvic at br.ibm.com 2017-02-03 10:33 EDT-------
I enabled the debug in udev for Ubuntu 17.04 and I am seeing the following in the log:
systemd-udevd[4552]: 'ifupdown-hotplug'(err) 'ifquery: error while
loading shared libraries: cannot restore segment prot after reloc:
Operation not permitted'
This command is used in the /lib/udev/ifupdown-hotplug script that is
invoked in the 80-ifupdown.rules
# cat /lib/udev/rules.d/80-ifupdown.rules
# Allow rfkill for users in the netdev group
KERNEL=="rfkill", MODE="0664", GROUP="netdev"
# Handle allow-hotplug interfaces
SUBSYSTEM=="net", ACTION=="add|remove", RUN+="ifupdown-hotplug"
The ifquery command is used in the following net_ifup function of the
script:
net_ifup() {
check_program /sbin/ifup
# exit if the interface is not configured as allow-hotplug or auto
if ! (ifquery --allow hotplug -l; ifquery --allow auto -l) | grep -q "^${INTERFACE}\$"; then
exit 0
fi
if [ -d /run/systemd/system ]; then
exec systemctl --no-block start $(systemd-escape --template ifup at .service $INTERFACE)
fi
local out=$(ps -C ifup ho args)
if [ "${out%$INTERFACE*}" != "$out" ]; then
mesg "Already ifup-ing interface $INTERFACE"
exit 0
fi
wait_for_interface lo
exec ifup --allow=hotplug $INTERFACE
}
So it is failing the first if and exiting the function when it shouldn't
be doing so for an interface that is supposed to be configured. And
since it uses exit code 0 it doesn't show up as an error in the syslog
and it appears that the script is successfully executed.
I don't see the error with ifquery when testing in Ubuntu 16.04, so it
might be the point of failure we are looking for.
What I find strange is that the script and rule are the same in Ubuntu
16.04 and Ubuntu 17.04 and when I manually run the command in Ubuntu
17.04 I get the proper output.
# ifquery --allow hotplug -l
enP1p12s0f0
# ifquery --allow auto -l
lo
enP1p12s0f0
I still need to take a closer look to try to figure out what is causing
ifquery to fail in the script and not when using it manually.
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to ifupdown in Ubuntu.
https://bugs.launchpad.net/bugs/1660762
Title:
[Regression] Interface configuration not restored after driver
unbind/bind (generic)
Status in ifupdown package in Ubuntu:
Triaged
Bug description:
---Problem Description---
Interface configuration not restored after driver unbind/bind
root at ltciofvtr-s824-lp8:~# ifconfig enP28p96s0f0
enP28p96s0f0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.10.10.11 netmask 255.255.255.0 broadcast 10.10.10.255
inet6 fe80::290:faff:fe7a:5840 prefixlen 64 scopeid 0x20<link>
ether 00:90:fa:7a:58:40 txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 13 bytes 1046 (1.0 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
root at ltciofvtr-s824-lp8:~# cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
source /etc/network/interfaces.d/*
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
auto ibmveth2
iface ibmveth2 inet static
address 9.47.68.120
netmask 255.255.240.0
network 9.47.64.0
broadcast 9.47.79.255
gateway 9.47.79.254
# dns-* options are implemented by the resolvconf package, if installed
dns-nameservers 9.12.18.2
dns-search pok.stglabs.ibm.com
auto enP28p96s0f0
iface enP28p96s0f0 inet static
address 10.10.10.11
netmask 255.255.255.0
root at ltciofvtr-s824-lp8:~# ethtool -i enP28p96s0f0
driver: be2net
version: 11.1.0.0
firmware-version: 10.2.252.1913
expansion-rom-version:
bus-info: 001c:60:00.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: no
supports-priv-flags: yes
root at ltciofvtr-s824-lp8:~# echo -n 001c:60:00.0 >
/sys/bus/pci/drivers/be2net/unbind
root at ltciofvtr-s824-lp8:~# ls /sys/bus/pci/drivers/be2net
001c:60:00.1 001c:60:00.2 001c:60:00.3 bind module new_id remove_id uevent unbind
root at ltciofvtr-s824-lp8:~# echo -n 001c:60:00.0 >
/sys/bus/pci/drivers/be2net/bind
root at ltciofvtr-s824-lp8:~# ls /sys/bus/pci/drivers/be2net
001c:60:00.0 001c:60:00.1 001c:60:00.2 001c:60:00.3 bind module new_id remove_id uevent unbind
root at ltciofvtr-s824-lp8:~# ifconfig enP28p96s0f0
enP28p96s0f0: flags=4098<BROADCAST,MULTICAST> mtu 1500
ether 00:90:fa:7a:58:40 txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
root at ltciofvtr-s824-lp8:~# ifup enP28p96s0f0
ifup: interface enP28p96s0f0 already configured
root at ltciofvtr-s824-lp8:~# ifdown enP28p96s0f0
RTNETLINK answers: Cannot assign requested address
root at ltciofvtr-s824-lp8:~# ifup enP28p96s0f0
root at ltciofvtr-s824-lp8:~# ifconfig enP28p96s0f0
enP28p96s0f0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.10.10.11 netmask 255.255.255.0 broadcast 10.10.10.255
inet6 fe80::290:faff:fe7a:5840 prefixlen 64 scopeid 0x20<link>
ether 00:90:fa:7a:58:40 txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 16 bytes 1344 (1.3 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
---uname output---
Linux ltciofvtr-s824-lp8 4.9.0-12-generic #13-Ubuntu SMP Tue Jan 10 12:52:39 UTC 2017 ppc64le ppc64le ppc64le GNU/Linux
Machine Type = IBM,8286-42A LPAR
---Steps to Reproduce---
# echo -n 001c:60:00.0 > /sys/bus/pci/drivers/be2net/unbind
# echo -n 001c:60:00.0 > /sys/bus/pci/drivers/be2net/bind
== Comment - Vaishnavi Bhat
Hi,
To bind a device to a driver, the device must first not be controlled by any other driver. Can you check for 'driver' in the below before you bind ?
$ tree /sys//bus/pci/devices/001c:60:00.0
Thank you.
== Comment - Murilo Fossa Vicentini
Just adding some information, this is not a driver specific issue, this was also seen with tg3 and i40e adapters . This behavior is a regression when compared to Ubuntu 16.04 where the interfaces where properly reconfigured upon bind with the information set in /etc/network/interfaces
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1660762/+subscriptions
More information about the foundations-bugs
mailing list