> The 30000002 is likely what we'd want to bind to.

Thanks for pointing this out! This sounds like a very good solution,
much better than either of the above. If this is stable across reboots
and indeed a property of the (virtual) "hardware", then let's use this.

Thus an udev rule like this ought to work, e. g. in /lib/udev/rules.d/76
-ibmveth-naming.rules:

SUBSYSTEM=="net", NAME=="", DRIVERS=="ibmveth", PROGRAM="/bin/sh -ec
'D=${DEVPATH#*/vio/}; D=${D#3}; echo ${D%%%%/*} | sed s/^0*//",
NAME="ibmveth$result"

This will sort after any existing 70-persistent-net.rules, but before 80
-net-setup-link.rules.

So for your example the interface would be called "ibmveth2", and for a
device which breaks the "starts with 3" assumption and has e. g.
/devices/vio/5000003, it would then be named "ibmveth5000003". If this
(not starting with '3') "Should Not Happen™", that's fine, but I'd
rather be cautious.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, 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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to     : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to