[Bug 1561096] Re: STC850:Brazos:Br16:Br16p05: Network ethernet port name changed under Ubuntu 16.04 with added adapters (ibmveth)
Martin Pitt
martin.pitt at ubuntu.com
Tue Apr 5 09:34:14 UTC 2016
> This creates a name-slip problem for these ibmveth devices depending
on the timing of other devices (where another NIC will temporarily be
assigned a name like eth0 before it is renamed by udev).
Can you please explain this further? The kernel should always pick a new
eth* name and avoid name clashes with existing eth* devices, and udev
(since Ubuntu 15.04) will never assign a name like "eth*" which
potentially collides with the kernel default names. At least that's the
current assumption, if that is invalid and you actually see a device
being *re*named to "eth*", this is what we need to fix.
>From your logs I see that the kernel apparently detected an eth0 and
eth2 and udev renamed them to slot-based names:
Feb 10 11:41:39 br16p05 kernel: [ 1.129225] qlge 0001:a0:00.1 enP1p160s0f1: renamed from eth2
Feb 10 11:41:39 br16p05 kernel: [ 1.151033] qlge 0001:a0:00.0 enP1p160s0f0: renamed from eth0
Feb 10 11:41:39 br16p05 kernel: [ 3.844707] mlx4_core 0000:01:00.0 enp1s0: renamed from eth0
Feb 10 11:41:39 br16p05 kernel: [ 3.866910] mlx4_core 0000:01:00.0 enp1s0d1: renamed from eth2
I'm a bit confused why there are two different device drivers claiming
the same device, though.
After booting, what does "ip a" show, i. e. which ethernet devices do
you actually have? It would also be helpful to attach the output of
"udevadm info --export-db" to show me which information udev collected
about the ethernet devices.
Did you manually put "eth0" into /etc/network/interfaces, or was that
done by the installer? The latter would mean that the installer
environment names devices differently than the installed OS (that'd be a
major bug indeed).
> Please add back persistent-net-generator support for non-PCI-based
devices like this.
This isn't going to happen, I'm afraid. That generator was conceptually
broken for virtual hardware (and thus had a large blacklist) and had an
unfixable race condition as it renamed devices to names that are also
being used by the kernel. Let's rather fix this properly with ifnames.
** Changed in: systemd (Ubuntu Xenial)
Status: Triaged => Incomplete
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1561096
Title:
STC850:Brazos:Br16:Br16p05: Network ethernet port name changed under
Ubuntu 16.04 with added adapters (ibmveth)
Status in systemd package in Ubuntu:
Incomplete
Status in systemd source package in Xenial:
Incomplete
Bug description:
Problem Description : I had installed a fresh install of Ubuntu 16.04
from an ISO image and had set up the partition as directed in the
Wiki. I had set up the networking as directed in the WIKI and was able
to ping "iofnim" and was able to perform updates and upgrades to the
Ubuntu installation without issue.
I had checked to make sure (by adding them to an existing AIX
partition) that the Mason and Travis_EN adapters to be added were at
the latest microcode levels. I assigned them to the partition to be
used (br16p05) and then shut down the partition and restarted it to
allow the partition to activate the adapters.
After the partition restarted, I attempted to build the network using
build_net and during its run noticed that the output for the adapters
was returning "Network is unreachable". After it completed, I
attempted to mount iofnim using the command:
"mount iofnim.aus.stglabs.ibm.com:/nim/build_net /root/test -o nolock"
which returned a "Failed" error message.
I then ran "ifconfig -a" to check on the state of the network which
had been working until I rebooted the partition after adding the
adapters.
I found the unconventional names for both the Mason and the Travis_EN
adapters contained in the output from "ifconfig -a" but also found
that "eth0", with which I had originally set up the network access for
the partition during setupp, was no longer listed but instead "eth1"
was now listed and none of the networking data including IP's reported
from "ifconfig -a" were set.
I consulted with Thiru and he asked I write it up and include a tar
file created from /var/log which I have attached to the defect.
As an additional note, I was able to go back into
/etc/network/interfaces and modify the settings for "eth0" to now be
set to "eth1" and after bringing the port down and back up, was able
to again ping out and access the network.
Please advise.
== Comment: #7 - Kevin W. Rudd - 2016-02-11 12:32:49 ==
Thank you for the additional info. This is not quite the same as the bug I referenced earlier. It is actually a match for bug 122308 .
Canonical:
This is the same basic issue as originally worked in LP Bug 1437375
The ibmveth based devices are not associated with PCI bus locations,
and still rely on the legacy eth? naming. The problem here is that
the 75-persistent-net-generator.rules file that used to set up the 70
-persistent-net.rules file for these devices has been removed in 16.04
This creates a name-slip problem for these ibmveth devices depending
on the timing of other devices (where another NIC will temporarily be
assigned a name like eth0 before it is renamed by udev).
Please add back persistent-net-generator support for non-PCI-based
devices like this.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1561096/+subscriptions
More information about the foundations-bugs
mailing list