Ubuntu
systemd package

[udev] Adding "Austin" adapter to Ubuntu partition take over system network interface

Bug #1437375 reported by bugproxy on 2015-03-27

This bug affects 1 person

	Status	Importance	Assigned to
systemd (Ubuntu)	Fix Released	High	Mathieu Trudel-Lapierre
Trusty	Fix Released	Undecided	Mathieu Trudel-Lapierre
Vivid	Fix Released	High	Martin Pitt
Wily	Fix Released	Undecided	Mathieu Trudel-Lapierre

Bug Description

[Impact]
This impacts any user of LPARs; upon adding physical network interfaces (or, realistically, any network interface at all, even virtual), the network interface which is used for system access and used to install the system may not appear in the same order after reboot.

[Test Case]
Requires access to logical partitions.
1) Install system
2) Add an physical network adapter to the partition
3) Reboot.

Observed behavior:
After reboot, the virtual adapter expected to be used is unavailable, the address is assigned to any other network adapter which may have been detected and used persistent addresses.

Expected behavior
The system should come up with network interfaces in the same order as before rebooting.

[Regression Potential]
Added virtual interfaces that should be not persist (because they are locally administered and thus may have their MAC address change) may come up as persistent devices due to the use of the ibmveth driver, and thus fail to work as expected.

---

Problem Description:
====================

Adding Austin adapter to Ubuntu partition took over system network interface. This caused system to be off network connection.

ver 1.5.4.3 - OS, HTX, Firmware and Machine details

                           OS: GNU/Linux
                   OS Version: Ubuntu Vivid Vervet (development branch) \n \l
               Kernel Version: 3.18.0-13-generic
                  HTX Version: htxubuntu-322
                    Host Name: br14p08
            Machine Serial No: IBM,0210800E7
           Machine Type/Model: IBM,9119-MHE
              System FW Level: FW830.00 (SC830_021)

BEFORE adding Austin adapter to br14p08:
========================================

Before adding austin adapter to br14p05 (vio client), the system network is good.

ubuntu@br14p08:~$ lsslot -cpci
ubuntu@br14p08:~$

+ eth0 U9119.MHE.10800E7-V8-C2-T1
Interpartition Logical LAN

root@br14p08:~# lscfg |grep eth
+ eth0 U9119.MHE.10800E7-V8-C2-T1

root@br14p08:~# ifconfig
eth0 Link encap:Ethernet HWaddr 16:59:c0:50:0a:02
          inet addr:9.3.21.12 Bcast:9.3.21.255 Mask:255.255.254.0
          inet6 addr: fe80::1459:c0ff:fe50:a02/64 Scope:Link
          inet6 addr: 2002:903:15f:290:1459:c0ff:fe50:a02/64 Scope:Global
          UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
          RX packets:37366 errors:0 dropped:16 overruns:0 frame:0
          TX packets:153 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:2472739 (2.4 MB) TX bytes:22596 (22.5 KB)
          Interrupt:19

lo Link encap:Local Loopback
          inet addr:127.0.0.1 Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING MTU:65536 Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

root@br14p08:~# ping br14p08
PING br14p08.aus.stglabs.ibm.com (9.3.21.12) 56(84) bytes of data.
64 bytes from br14p08.aus.stglabs.ibm.com (9.3.21.12): icmp_seq=1 ttl=64 time=0.008 ms
64 bytes from br14p08.aus.stglabs.ibm.com (9.3.21.12): icmp_seq=2 ttl=64 time=0.004 ms
64 bytes from br14p08.aus.stglabs.ibm.com (9.3.21.12): icmp_seq=3 ttl=64 time=0.005 ms
^C
--- br14p08.aus.stglabs.ibm.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1998ms
rtt min/avg/max/mdev = 0.004/0.005/0.008/0.003 ms

root@br14p08:~# ping nimitz
PING nimitz.aus.stglabs.ibm.com (9.3.165.31) 56(84) bytes of data.
64 bytes from nimitz.aus.stglabs.ibm.com (9.3.165.31): icmp_seq=1 ttl=254 time=0.344 ms
64 bytes from nimitz.aus.stglabs.ibm.com (9.3.165.31): icmp_seq=2 ttl=254 time=0.326 ms
64 bytes from nimitz.aus.stglabs.ibm.com (9.3.165.31): icmp_seq=3 ttl=254 time=0.363 ms
^C

AFTER ADDED Austin Adapter:
===========================

Once the Austin adapter added to the partition, the Austin's 1st port became eth0.
and it pushed the virtual ethernet (which is system's ethernet) to be eth4.
However, the system still looking for eth0 as system's main network interface.

root@br14p08:~# lscfg | grep eth
+ eth4 U9119.MHE.10800E7-V8-C2-T1
+ eth0 U78CA.001.RCH0133-P1-C2-C1-T1
+ eth0 U78CA.001.RCH0133-P1-C2-C1-T1
+ eth3 U78CA.001.RCH0133-P1-C2-C1-T2
+ ethernet U78CA.001.RCH0133-P1-C2-C1-T3
+ eth5 U78CA.001.RCH0133-P1-C2-C1-T4

+ eth4 U9119.MHE.10800E7-V8-C2-T1
                                         Interpartition Logical LAN
+ eth0 U78CA.001.RCH0133-P1-C2-C1-T1
                                         PCIe2 4-port 1GbE Adapter (14105716)
+ eth0 U78CA.001.RCH0133-P1-C2-C1-T1
                                         Ethernet PCI Adapter
+ ptp0 U78CA.001.RCH0133-P1-C2-C1-T1

+ eth3 U78CA.001.RCH0133-P1-C2-C1-T2
                                         PCIe2 4-port 1GbE Adapter (14105716)
+ ethernet U78CA.001.RCH0133-P1-C2-C1-T3
                                         PCIe2 4-port 1GbE Adapter (14105716)
+ eth5 U78CA.001.RCH0133-P1-C2-C1-T4
                                         PCIe2 4-port 1GbE Adapter (14105716)

root@br14p08:~# ifconfig
eth0 Link encap:Ethernet HWaddr 40:f2:e9:5a:33:a0
          inet addr:9.3.21.12 Bcast:9.3.21.255 Mask:255.255.254.0
          inet6 addr: fe80::42f2:e9ff:fe5a:33a0/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:509 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B) TX bytes:32744 (32.7 KB)
          Interrupt:248

lo Link encap:Local Loopback
          inet addr:127.0.0.1 Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING MTU:65536 Metric:1
          RX packets:258 errors:0 dropped:0 overruns:0 frame:0
          TX packets:258 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:28260 (28.2 KB) TX bytes:28260 (28.2 KB)

== Comment: #8 - Siraj M. Ismail <email address hidden> - 2015-03-23 16:43:50 ==
This is a LPAR on a PowerVM system, so no bridge or br0 interfaces on this one. The Virtual adapter is provided by the VIOS server, which shows up as a ethernet port when the LPAR boots up. The issue is that when another adapter with 4 ports gets added to the LPAR with DLPAR add operation while the partition is running, the original eth0 gets renamed to eth5 or similar, and we loose the IP configuration for the LPAR. And that is what need to be looked at and see if this is a driver issue or just a procedure change.

Here are some details of what happens on the system:

Before adding the adapter: (initial config)
================================
root@br14p08:~# lsslot
# Slot Description Linux Name Device(s)
U9119.MHE.10800E7-V8-C0 Virtual I/O Slot 30000000 vty
U9119.MHE.10800E7-V8-C2 Virtual I/O Slot 30000002 l-lan
U9119.MHE.10800E7-V8-C3 Virtual I/O Slot 30000003 v-scsi

root@br14p08:~# ethtool -P eth0
Permanent address: 16:59:c0:50:0a:02 <== MAC

root@br14p08:~# ifconfig -a
eth0 Link encap:Ethernet HWaddr 16:59:c0:50:0a:02
          inet addr:9.3.21.12 Bcast:9.3.21.255 Mask:255.255.254.0
          inet6 addr: fe80::1459:c0ff:fe50:a02/64 Scope:Link
          inet6 addr: 2002:903:15f:290:1459:c0ff:fe50:a02/64 Scope:Global
          UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
          RX packets:375794 errors:0 dropped:1 overruns:0 frame:0
          TX packets:9646 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:46210638 (46.2 MB) TX bytes:787820 (787.8 KB)
          Interrupt:19

root@br14p08:~# 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).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0

iface eth0 inet static
  address 9.3.21.12
  netmask 255.255.254.0
  gateway 9.3.20.1
  dns-nameservers 9.3.1.200
  dns-search aus.stglabs.ibm.com isst.aus.stglabs.ibm.com

After adding a four port Ethernet adapter at runtime:
========================================

Before Reboot:
===========
root@br14p08:~# lspci
01:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5719 Gigabit Ethernet PCIe (rev 01)
01:00.1 Ethernet controller: Broadcom Corporation NetXtreme BCM5719 Gigabit Ethernet PCIe (rev 01)
01:00.2 Ethernet controller: Broadcom Corporation NetXtreme BCM5719 Gigabit Ethernet PCIe (rev 01)
01:00.3 Ethernet controller: Broadcom Corporation NetXtreme BCM5719 Gigabit Ethernet PCIe (rev 01)
root@br14p08:~# ifconfig -a
eth0 Link encap:Ethernet HWaddr 16:59:c0:50:0a:02
          inet addr:9.3.21.12 Bcast:9.3.21.255 Mask:255.255.254.0
          inet6 addr: fe80::1459:c0ff:fe50:a02/64 Scope:Link
          inet6 addr: 2002:903:15f:290:1459:c0ff:fe50:a02/64 Scope:Global
          UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
          RX packets:637083 errors:0 dropped:3 overruns:0 frame:0
          TX packets:10943 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:63241734 (63.2 MB) TX bytes:977826 (977.8 KB)
          Interrupt:19

eth3 Link encap:Ethernet HWaddr 40:f2:e9:5a:33:a1
          BROADCAST MULTICAST MTU:1500 Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

eth4 Link encap:Ethernet HWaddr 40:f2:e9:5a:33:a2
          BROADCAST MULTICAST MTU:1500 Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

eth5 Link encap:Ethernet HWaddr 40:f2:e9:5a:33:a3
          BROADCAST MULTICAST MTU:1500 Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

rename6 Link encap:Ethernet HWaddr 40:f2:e9:5a:33:a0
          BROADCAST MULTICAST MTU:1500 Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

After reboot:
=========

root@br14p08:~# lspci
01:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5719 Gigabit Ethernet PCIe (rev 01)
01:00.1 Ethernet controller: Broadcom Corporation NetXtreme BCM5719 Gigabit Ethernet PCIe (rev 01)
01:00.2 Ethernet controller: Broadcom Corporation NetXtreme BCM5719 Gigabit Ethernet PCIe (rev 01)
01:00.3 Ethernet controller: Broadcom Corporation NetXtreme BCM5719 Gigabit Ethernet PCIe (rev 01)
root@br14p08:~# lsslot
# Slot Description Linux Name Device(s)
U9119.MHE.10800E7-V8-C0 Virtual I/O Slot 30000000 vty
U9119.MHE.10800E7-V8-C2 Virtual I/O Slot 30000002 l-lan
U9119.MHE.10800E7-V8-C3 Virtual I/O Slot 30000003 v-scsi
root@br14p08:~#

root@br14p08:~# ifconfig
eth0 Link encap:Ethernet HWaddr 40:f2:e9:5a:33:a0
          inet addr:9.3.21.12 Bcast:9.3.21.255 Mask:255.255.254.0
          inet6 addr: fe80::42f2:e9ff:fe5a:33a0/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:242 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B) TX bytes:15656 (15.6 KB)
          Interrupt:248

lo Link encap:Local Loopback
          inet addr:127.0.0.1 Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING MTU:65536 Metric:1
          RX packets:123 errors:0 dropped:0 overruns:0 frame:0
          TX packets:123 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:13584 (13.5 KB) TX bytes:13584 (13.5 KB)

root@br14p08:~# ethtool -P eth0 <= Eth0 has changed to new adapter
Permanent address: 40:f2:e9:5a:33:a0

As you can see, port for eth0 has now changed, but the IP address stayed with the port name eth0, whih causes the LPAR to loose it's network. That is the issue we need to address with this bug.

== Comment: #9 - Brian J. King <email address hidden> - 2015-03-23 18:49:15 ==
It looks like Ubuntu 14.04 by default uses /lib/udev/write_net_rules to modify /etc/udev/rules.d/70-persistent-net.rules in order to do persistent eth device name binding. Looking at /etc/udev/rules.d/70-persistent-net.rules on this system, I see multiple entries for the same mac address, so something may be broken in this script.

== Comment: #11 - Siraj M. Ismail <email address hidden> - 2015-03-24 10:19:20 ==
This is a LPAR on a PowerVM system, so no bridge or br0 interfaces on this one. The Virtual adapter is provided by the VIOS server, which shows up as a ethernet port when the LPAR boots up. The issue is that when another adapter with 4 ports gets added to the LPAR with DLPAR add operation while the partition is running, the original eth0 gets renamed to eth5 or similar, and we loose the IP configuration for the LPAR. And that is what need to be looked at and see if this is a driver issue or just a procedure change.

Here are some details of what happens on the system:

root@br14p08:~# ethtool -P eth0
Permanent address: 16:59:c0:50:0a:02 <== MAC

root@br14p08:~# 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).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0

iface eth0 inet static
  address 9.3.21.12
  netmask 255.255.254.0
  gateway 9.3.20.1
  dns-nameservers 9.3.1.200
  dns-search aus.stglabs.ibm.com isst.aus.stglabs.ibm.com

After adding a four port Ethernet adapter at runtime:
========================================

After reboot:
=========

root@br14p08:~# ifconfig
eth0 Link encap:Ethernet HWaddr 40:f2:e9:5a:33:a0
          inet addr:9.3.21.12 Bcast:9.3.21.255 Mask:255.255.254.0
          inet6 addr: fe80::42f2:e9ff:fe5a:33a0/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:242 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B) TX bytes:15656 (15.6 KB)
          Interrupt:248

root@br14p08:~# ethtool -P eth0 <= Eth0 has changed to new adapter
Permanent address: 40:f2:e9:5a:33:a0

As you can see, port for eth0 has now changed, but the IP address stayed with the port name eth0, whih causes the LPAR to loose it's network. That is the issue we need to address with this bug.

See original description

Tags:

bugproxy (bugproxy) on 2015-03-27

tags:

added: architecture-ppc64 bugnameltc-122308 severity-high targetmilestone-inin---

Revision history for this message

Ubuntu Foundations Team Bug Bot (crichton) wrote on 2015-03-27:

Thank you for taking the time to report this bug and helping to make Ubuntu better. It seems that your bug report is not filed about a specific source package though, rather it is just filed against Ubuntu in general. It is important that bug reports be filed about source packages so that people interested in the package can find the bugs about it. You can find some hints about determining what package your bug might be about at https://wiki.ubuntu.com/Bugs/FindRightPackage. You might also ask for help in the #ubuntu-bugs irc channel on Freenode.

To change the source package that this bug is filed about visit https://bugs.launchpad.net/ubuntu/+bug/1437375/+editstatus and add the package name in the text box next to the word Package.

[This is an automated message. I apologize if it reached you inappropriately; please just reply to this message indicating so.]

tags:

added: bot-comment

Luciano Chavez (lnx1138) on 2015-03-31

affects:

ubuntu → udev (Ubuntu)

bugproxy (bugproxy) on 2015-03-31

tags:

added: architecture-ppc64le targetmilestone-inin1504
removed: architecture-ppc64 targetmilestone-inin---

Revision history for this message

bugproxy (bugproxy) wrote on 2015-03-31: Comment bridged from LTC Bugzilla

------- Comment From <email address hidden> 2015-03-31 20:59 EDT-------
This needs to be assigned to the udev package in Launchpad.

Revision history for this message

bugproxy (bugproxy) wrote on 2015-04-06:

------- Comment From <email address hidden> 2015-04-06 17:15 EDT-------
==== State: Assigned by: tnadams on 06 April 2015 12:08:40 ====

Has this been reassigned as requested? Any updates here? Thanks.

Luciano Chavez (lnx1138) on 2015-04-07

Changed in udev (Ubuntu):
assignee:	nobody → Taco Screen team (taco-screen-team)

Revision history for this message

Steve Langasek (vorlon) wrote on 2015-04-07: Re: Adding "Austin" adapter to Ubuntu partition take over system network interface

Please attach the /etc/udev/rules.d/70-persistent-net.rules from the affected system.

Revision history for this message

bugproxy (bugproxy) wrote on 2015-04-07: Comment bridged from LTC Bugzilla

------- Comment From <email address hidden> 2015-04-07 16:05 EDT-------
==== State: Assigned by: mpham on 07 April 2015 11:02:35 ====

The partition currently has Austin adapter so there is no system network that I can transfer the file here.

The file is quite small, so I'll paste its content here:

root@br14p08:/etc/udev/rules.d# cat 70-persistent-net.rules
# This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.

# PCI device 0x1924:0x0803 (sfc)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="40:f2:e9:44:00:31", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth2"

# PCI device 0x1924:0x0803 (sfc)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="40:f2:e9:44:00:30", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"

# PCI device 0x14e4:0x1657 (tg3)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="40:f2:e9:5a:33:a1", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth3"

# PCI device 0x14e4:0x1657 (tg3)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="40:f2:e9:5a:33:a0", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

# PCI device 0x14e4:0x1657 (tg3)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="40:f2:e9:5a:33:a2", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth4"

# PCI device 0x14e4:0x1657 (tg3)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="40:f2:e9:5a:33:a3", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth5"

Revision history for this message

Steve Langasek (vorlon) wrote on 2015-04-07: Re: Adding "Austin" adapter to Ubuntu partition take over system network interface

Thanks. So notably, *none* of the entries in your 70-persistent-net.rules matches the original ethernet device. This explains why, on reboot, the eth0 name was not reserved for the device that was used at install time.

Looking at /lib/udev/rules.d/75-persistent-net-generator.rules, it appears that the hardware address "16:59:c0:50:0a:02" matches this line:

ENV{MATCHADDR}=="?[2367abef]:*", ENV{MATCHADDR}=""

The comment preceding this line is:

# ignore interfaces with locally administered or null MAC addresses
# and VMWare, Hyper-V, KVM, Virtualbox and Xen virtual interfaces

And a bit of research shows that, indeed, this mac address of 16:[...] has the bit set that indicates a locally-administered address.

Is this pre-production hardware? Or is it expected that partitions under PowerVM use locally-administered mac addresses?

Revision history for this message

bugproxy (bugproxy) wrote on 2015-04-10: Comment bridged from LTC Bugzilla

------- Comment From <email address hidden> 2015-04-10 12:55 EDT-------
==== State: Assigned by: bellivea on 10 April 2015 07:44:36 ====

#=#=# 2015-04-10 07:44:33 (CDT) #=#=#
New Keywords = [STI=IOA]
#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#

Revision history for this message

bugproxy (bugproxy) wrote on 2015-04-13:

------- Comment From <email address hidden> 2015-04-13 15:39 EDT-------
To answer the first question, the system is considered ship level HW.

On the second question, and to be more clear, the adapter port we are adding with Dynamic add are all real physical Ethernet ports.

The only virtual port is the original Eth0, which is a PowerVM Virtual LAN port. It has the MAC 16:59:c0:50:0a:02 assigned to it.

If that is what is causing the issue, then we will need a solution for the customers, as this works on all the other supported O/S without any issues.

Revision history for this message

bugproxy (bugproxy) wrote on 2015-04-14:

------- Comment From <email address hidden> 2015-04-14 13:35 EDT-------
The workaround for this bug is basically one of the three:

a) add a persistent rule for eth0 in etc/udev/rules.d/70-persistent-net.rules, as:
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="4c:45:42:45:01:04", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

b) force localy-administered MACs interfaces to have persistency, removing the following line /lib/udev/rules.d/75-persistent-net-generator.rules.

ENV{MATCHADDR}=="?[2367abef]:*", ENV{MATCHADDR}=""

c) Changing the mac address of the interface, as ip link set dev interface address XX:XX:XX:XX:XX:XX

Revision history for this message

Steve Langasek (vorlon) wrote on 2015-04-14: Re: Adding "Austin" adapter to Ubuntu partition take over system network interface

#10

On other supported OSes, is the interface brought up as 'eth0', or using the net-ifname interface naming scheme?

Revision history for this message

bugproxy (bugproxy) wrote on 2015-04-14: Comment bridged from LTC Bugzilla

#11

------- Comment From <email address hidden> 2015-04-14 15:12 EDT-------
On the other Linux O/S I checked, it comes up as eth0, at least on the ones I checked.

Revision history for this message

bugproxy (bugproxy) wrote on 2015-04-15:

#12

------- Comment From <email address hidden> 2015-04-15 22:45 EDT-------
Cancelled by the CDE Bridge because the corresponding problem was moved out of the bridge problem domain

Revision history for this message

bugproxy (bugproxy) wrote on 2015-04-17:

#13

------- Comment From <email address hidden> 2015-04-17 20:32 EDT-------
There is an exception in /lib/udev/rules.d/75-persistent-net-generator.rules for ibmveth:

# ibmveth interfaces have stable locally administered MAC addresses
SUBSYSTEMS=="ibmveth", ENV{MATCHADDR}="$attr{address}"

This should override the issue related to locally administered mac addresses in this case. However, if we run:

udevadm monitor --e

and then:

echo "add" > /sys/class/net/eth0/uevent

We see:

KERNEL[622.903561] add /devices/vio/30000002/net/eth0 (net)
ACTION=add
DEVPATH=/devices/vio/30000002/net/eth0
IFINDEX=2
INTERFACE=eth0
SEQNUM=2105
SUBSYSTEM=net

UDEV [622.918331] add /devices/vio/30000002/net/eth0 (net)
ACTION=add
DEVPATH=/devices/vio/30000002/net/eth0
ID_NET_DRIVER=ibmveth
ID_NET_LINK_FILE=/lib/systemd/network/99-default.link
ID_NET_NAME_MAC=enx9232371c4202
IFINDEX=2
INTERFACE=eth0
MATCHDEVID=0x0
MATCHIFTYPE=1
SEQNUM=2105
SUBSYSTEM=net
SYSTEMD_ALIAS=/sys/subsystem/net/devices/eth0
<email address hidden>
TAGS=:systemd:
USEC_INITIALIZED=3954

If I make this change to /lib/udev/rules.d/75-persistent-net-generator.rules, then I get a rule generated for ibmveth devices:

--- 75-persistent-net-generator.rules.orig 2015-04-17 16:29:19.188304056 -0400
+++ 75-persistent-net-generator.rules 2015-04-17 16:26:34.395299425 -0400
@@ -103,6 +103,7 @@
# ibmveth interfaces have stable locally administered MAC addresses
SUBSYSTEMS=="ibmveth", ENV{MATCHADDR}="$attr{address}"
+DRIVERS=="ibmveth", ENV{MATCHADDR}="$attr{address}"
# S/390 interfaces are matched only by id
SUBSYSTEMS=="ccwgroup", \
@@ -125,6 +126,8 @@
ENV{COMMENT}="S/390 device at $id"
SUBSYSTEMS=="ibmveth", \
ENV{COMMENT}="LPAR virtual device at $id"
+DRIVERS=="ibmveth", \
+ ENV{COMMENT}="LPAR virtual device at $id"
SUBSYSTEMS=="ieee1394", \
ENV{COMMENT}="Firewire device $attr{host_id}"
ENV{COMMENT}=="", \

Revision history for this message

Steve Langasek (vorlon) wrote on 2015-05-03: Re: Adding "Austin" adapter to Ubuntu partition take over system network interface

#14

Mathieu, it looks like we have a viable patch for this issue in the udev persistent net rules. Could you please look at shepherding this into the archive for 15.04 and "w'?

Changed in udev (Ubuntu):
assignee:	Taco Screen team (taco-screen-team) → Mathieu Trudel-Lapierre (mathieu-tl)
importance:	Undecided → High
status:	New → Triaged

Mathieu Trudel-Lapierre (cyphermox) on 2015-05-05

description:

updated

Martin Pitt (pitti) on 2015-05-05

affects:	udev (Ubuntu Vivid) → systemd (Ubuntu Vivid)
summary:	- Adding "Austin" adapter to Ubuntu partition take over system network - interface + [udev] Adding "Austin" adapter to Ubuntu partition take over system + network interface

Revision history for this message

Martin Pitt (pitti) wrote on 2015-05-05:

#15

Indeed, SUBSYSTEMS=="ibmveth" is bogus, that should have been DRIVERS== all along. Thanks for pointing this out!

I committed the fix to the Debian experimental git, from where it will land in wily: http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?h=experimental&id=183a860e1a

Changed in systemd (Ubuntu Wily):
status:	New → Fix Committed

Revision history for this message

Martin Pitt (pitti) wrote on 2015-05-05:

#16

Also cherry-picked into the ubuntu branch, which has a few fixes staged for vivid-proposed: http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?id=3fcab4895a175f

Changed in systemd (Ubuntu Vivid):
assignee:	Mathieu Trudel-Lapierre (mathieu-tl) → Martin Pitt (pitti)
status:	Triaged → Fix Committed

Revision history for this message

Mathieu Trudel-Lapierre (cyphermox) wrote on 2015-05-06:

#17

Since this is in the queue for vivid-proposed already; should be In Progress.

Changed in systemd (Ubuntu Vivid):
status:	Fix Committed → In Progress

Revision history for this message

Chris J Arges (arges) wrote on 2015-05-06: Please test proposed package

#18

Hello bugproxy, or anyone else affected,

Accepted systemd into vivid-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/systemd/219-7ubuntu4.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in systemd (Ubuntu Vivid):
status:	In Progress → Fix Committed
tags:	added: verification-needed

Revision history for this message

Martin Pitt (pitti) wrote on 2015-05-07:

#19

Ah, I'm afraid Mathieu jumped the gun a little - what was uploaded here was *not* what was committed to git, and there are also some other pending changes staged up. Can we please accept 219-7ubuntu5.dsc in unapproved instead?

Revision history for this message

Chris Halse Rogers (raof) wrote on 2015-05-07:

#20

Hello bugproxy, or anyone else affected,

Accepted systemd into vivid-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/systemd/219-7ubuntu5 in a few hours, and then in the -proposed repository.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Revision history for this message

Mathieu Trudel-Lapierre (cyphermox) wrote on 2015-05-07:

#21

pitti, I had uploaded a day before you committed things to git, seems like there was a bit of miscommunication before, I had mentioned it on IRC I believe. In any case, it's good that things are covered in -proposed now.

Revision history for this message

Martin Pitt (pitti) wrote on 2015-05-07: Re: [Bug 1437375] Re: [udev] Adding "Austin" adapter to Ubuntu partition take over system network interface

#22

Mathieu Trudel-Lapierre [2015-05-07 14:20 -0000]:
> pitti, I had uploaded a day before you committed things to git, seems
> like there was a bit of miscommunication before, I had mentioned it on
> IRC I believe. In any case, it's good that things are covered in
> -proposed now.

Ah okay, sorry for the misunderstanding then!

Revision history for this message

Launchpad Janitor (janitor) wrote on 2015-05-08:

#23

Download full text (5.9 KiB)

This bug was fixed in the package systemd - 219-8ubuntu1

---------------
systemd (219-8ubuntu1) wily; urgency=medium

  * Merge with Debian experimental branch. Remaining Ubuntu changes:
    - Hack to support system-image read-only /etc, and modify files in
      /etc/writable/ instead.
    - Keep our much simpler udev maintainer scripts (all platforms must
      support udev, no debconf).
    - initramfs init-top: Drop $ROOTDELAY, we do that in a more sensible way
      with wait-for-root. Will get applicable to Debian once Debian gets
      wait-for-root in initramfs-tools.
    - initramfs init-bottom: If LVM is installed, settle udev,
      otherwise we get missing LV symlinks. Workaround for LP #1185394.
    - Add debian/udev.lvm2.init: Dummy SysV init script to satisfy insserv
      dependencies to "lvm2" which is handled with udev rules in Ubuntu.
    - Add debian/udev.lvm2.service to avoid running the dummy lvm2 init
      script.
    - Provide shutdown fallback for upstart. (LP: #1370329)
    - debian/extra/ifup@.service: Additionally run for "auto" class. We don't
      really support "allow-hotplug" in Ubuntu at the moment, so we need to
      deal with "auto" devices appearing after "/etc/init.d/networking start"
      already ran. (LP: #1374521) Also, check if devices are actually defined
      in /etc/network/interfaces as we don't use Debian's net.agent.
      Also run ifup in the background during boot, to avoid blocking
      network.target. (LP: #1425376)
    - ifup@.service: Drop dependency on networking.service (i. e.
      /etc/init.d/networking), and merely ensure that /run/network exists.
      This avoids unnecessary dependencies/waiting during boot and dependency
      cycles if hooks wait for other interfaces to come up (like ifenslave
      with bonding interfaces). (LP: #1414544)
    - Add Get-RTC-is-in-local-time-setting-from-etc-default-rc.patch: In
      Ubuntu we currently keep the setting whether the RTC is in local or UTC
      time in /etc/default/rcS "UTC=yes|no", instead of /etc/adjtime.
      (LP: #1377258)
    - Put session scopes into all cgroup controllers. This makes unprivileged
      user LXC containers work under systemd. (LP: #1346734)
    - systemctl: Don't forward telinit u to upstart. This works around
      upstart's Restart() always reexec'ing /sbin/init on Restart(), even if
      that changes to point to systemd during the upgrade. This avoids running
      systemd during a dist-upgrade. (LP: #1430479)
    - Drop hwdb-update dependency from udev-trigger.service, which got
      introduced in v219-stable. This causes udev and plymouth to start too
      late and isn't really needed in Ubuntu yet as we don't support stateless
      systems yet and handle hwdb.bin updates through dpkg triggers. This can
      be dropped again with initramfs-tools 0.117.
    - Lower Breaks: to plymouth version which has the udev inotify fix in
      Ubuntu.
    - Lower libappamor dep to the Ubuntu version where it moved to /lib.
    - Change systemd-sysv's conflicts to upstart-sysv. (LP: #1422681)
    - Make failure of boot-and-services NSpawn.test_boot non-fatal for now.
      This currently fails when being t...

This bug was fixed in the package systemd - 219-8ubuntu1

---------------
systemd (219-8ubuntu1) wily; urgency=medium

Upgrade fixes, keep until 16.04 LTS release:
    - systemd Conflicts/Replaces/Provides systemd-services.
    - Remove obsolete systemd-logind upstart job.
    - Clean up obsolete /etc/udev/rules.d/README.

systemd (219-9) UNRELEASED; urgency=medium

* 75-persistent-net-generator.rules: Fix rules for ibmveth (it's a driver,
    not a subsystem). (LP: #1437375)
  * debian/tests/unit-config: Add tests for systemctl enable/disable on a
    SysV-only unit. Reproduces LP #1447807.
  * Fix systemctl enable for SysV scripts without a native unit. We must not
    try and enable the nonexisting unit then. (LP: #1447807)

systemd (219-8) experimental; urgency=medium

[ Michael Biebl ]
  * Skip filesystem check if already done by the initramfs. (Closes: #782522)
  * Drop hard-coded versioned dependency on libapparmor1. Bump the
    Build-Depends on libapparmor-dev instead. This ensures a proper versioned
    dependency via Build-Depends-Package.
  * Revert "Make apparmor run before networking". This causes dependency
    cycles while apparmor still depends on $remote_fs.
  * Cleanup hwclock-save.service symlinks when upgrading from the jessie
    version.

[ Martin Pitt ]
  * cryptsetup: Implement offset and skip options. (Closes: #751707,
    LP: #953875)
  * logind autopkgtest: Add test for suspending on lid switch close.
    This reproduces LP #1444166 (lid switch not working in the first few
    minutes after boot).
  * Reduce the initial suspend supression time from 3 minutes to 30 seconds,
    and make it configurable. (LP: #1444166)
  * Fix double free crash in "systemctl enable" when calling update-rc.d and
    the latter fails. (Closes: #764613, LP: #1426588)
  * hwdb: Fix wireless switch on Dell Latitude (LP: #1441849)
  * Fix assertion crash when reading a service file with missing ' and
    trailing space. (LP: #1447243)
  * ifup@.service: Set IgnoreOnIsolate, so that "systemctl default" does not
    shut down network interfaces. (Closes: #762953, LP: #1449380).
    Add PartOf=network.target, so that stopping network.target also stops
    network interfaces (so that isolating emergency.target and similar work as
    before).
  * Revert upstream commit 743970d which immediately SIGKILLs units during
    shutdown. This leads to problems like bash not being able to write its
    history, mosh not saving its state, and similar failed cleanup actions.
    (LP: #1448259)
  * Drop the reversion of "journald: allow restarting journald without losing
    stream connections", and replace with proper upstream fix for
    sd_pid_notify_with_fds(). (See Debian #778970, LP #1423811; LP: #1437896)

-- Martin Pitt <martin.pitt@ubuntu.com>  Thu, 07 May 2015 12:16:36 +0200

Changed in systemd (Ubuntu Wily):
status:	Fix Committed → Fix Released

Breno Leitão (breno-leitao) on 2015-05-08

tags:

added: verification-done
removed: verification-needed

bugproxy (bugproxy) on 2015-05-08

tags:

added: severity-critical
removed: severity-high

Revision history for this message

Breno Leitão (breno-leitao) wrote on 2015-05-11:

#24

Thanks. Still waiting this fix on 15.04.

Revision history for this message

Mathieu Trudel-Lapierre (cyphermox) wrote on 2015-05-11:

#25

Breno; stable updates normally take 7 days to transition from the -proposed repository (for testing and finding regressions) to the point they land in -updates for access by everyone. This would bring it to this Thursday, May 14th; at which point the package update can be manually accepted.

In the meantime, you may use the vivid-proposed repository (except that may bring in other updates you may not need or want installed).

Revision history for this message

Launchpad Janitor (janitor) wrote on 2015-05-14:

#26

This bug was fixed in the package systemd - 219-7ubuntu5

---------------
systemd (219-7ubuntu5) vivid; urgency=medium

  * Revert upstream commit 743970d which immediately SIGKILLs units during
    shutdown. This leads to problems like bash not being able to write its
    history, mosh not saving its state, and similar failed cleanup actions.
    (LP: #1448259)
  * ifup@.service: Set IgnoreOnIsolate, so that "systemctl default" does not
    shut down network interfaces. (LP: #1449380). Add PartOf=network.target,
    so that stopping network.target also stops network interfaces.
  * 75-persistent-net-generator.rules: Fix rules for ibmveth (it's a driver,
    not a subsystem). (LP: #1437375)
  * debian/tests/unit-config: Add tests for systemctl enable/disable on a
    SysV-only unit. Reproduces LP #1447807.
  * Fix systemctl enable for SysV scripts without a native unit. We must not
    try and enable the nonexisting unit then. (LP: #1447807)

-- Martin Pitt <email address hidden> Thu, 07 May 2015 07:45:34 +0200

Changed in systemd (Ubuntu Vivid):
status:	Fix Committed → Fix Released

Revision history for this message

Brian Murray (brian-murray) wrote on 2015-05-14: Update Released

#27

The verification of the Stable Release Update for systemd has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

Revision history for this message

bugproxy (bugproxy) wrote on 2015-05-18: Comment bridged from LTC Bugzilla

#28

------- Comment From <email address hidden> 2015-05-18 17:48 EDT-------
Closing as fixed, please reopen if the problem reappears.

tags:

added: severity-high
removed: severity-critical

Revision history for this message

bugproxy (bugproxy) wrote on 2015-06-25:

#29

------- Comment From <email address hidden> 2015-06-22 22:42 EDT-------
Hi Maryn, I logged into your LPAR br14p07 and took a quick look, and I saw the updated 75-persistent-net-generator.rules file, and it does contain Brian's patch. And sure enough when I issued the command "udevadm trigger --subsystem-match=net --action=add", it added a record for eth0 that did not exist before:

root@br14p07:~# cat /etc/udev/rules.d/70-persistent-net.rules
...
# LPAR virtual device at 30000003 (ibmveth)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="16:59:ce:bf:9b:03", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

I then rebooted the system but could not get back in since I did not have the PW for this node. However I could see that it was pingable after the reboot so I'm pretty sure the eth0 interface came back normally after the reboot. You can check that for me please.

So it looks like Brian's patch fixes it, at least as far a the udev rule in concerned. Now we need to know if you are still experiencing the problem you reported.

The above "udevadm trigger" simulates what happens when new interfaces are added or when the system first boots. For any interface we want to be persistent we should have a rule written to /etc/udev/rules.d/70-persistent-net.rules, and that should be working now for the partition LAN interfaces. Once the rule is there, the interface (eth0 in this case) should not move when other interfaces are added or removed, or the system is rebooted.

You can test various scenarios by deleting the /etc/udev/rules.d/70-persistent-net.rules file and allowing it to be recreated. So to test the scenario you reported here, I would delete the file and reboot the system, and ensure you have an entry for eth0 (like the one above) written to the 70-persistent-net.rules file after the reboot. Then, you should be able to hotplug the additional interfaces, and reboot, and eth0 should not move. If this does not happen let us know. Thx.

------- Comment From hellerda@us.ibm.com 2015-06-22 22:42 EDT-------
Hi Maryn, I logged into your LPAR br14p07 and took a quick look, and I saw the updated 75-persistent-net-generator.rules file, and it does contain Brian's patch.  And sure enough when I issued the command "udevadm trigger --subsystem-match=net --action=add", it added a record for eth0 that did not exist before:

I then rebooted the system but could not get back in since I did not have the PW for this node.  However I could see that it was pingable after the reboot so I'm pretty sure the eth0 interface came back normally after the reboot.  You can check that for me please.

So it looks like Brian's patch fixes it, at least as far a the udev rule in concerned.  Now we need to know if you are still experiencing the problem you reported.

The above "udevadm trigger" simulates what happens when new interfaces are added or when the system first boots.  For any interface we want to be persistent we should have a rule written to /etc/udev/rules.d/70-persistent-net.rules, and that should be working now for the partition LAN interfaces.  Once the rule is there, the interface (eth0 in this case) should not move when other interfaces are added or removed, or the system is rebooted.

You can test various scenarios by deleting the /etc/udev/rules.d/70-persistent-net.rules file and allowing it to be recreated.  So to test the scenario you reported here, I would delete the file and reboot the system, and ensure you have an entry for eth0 (like the one above) written to the 70-persistent-net.rules file after the reboot.  Then, you should be able to hotplug the additional interfaces, and reboot, and eth0 should not move.  If this does not happen let us know.  Thx.

Revision history for this message

bugproxy (bugproxy) wrote on 2015-06-25: 75-persistent-net-generator.rules

#30

75-persistent-net-generator.rules Edit (5.5 KiB, text/plain)

------- Comment on attachment From <email address hidden> 2015-06-22 16:49 EDT-------

Attaching the 75-persistent-net-generator.rules file.

Revision history for this message

bugproxy (bugproxy) wrote on 2015-07-02: Comment bridged from LTC Bugzilla

#31

------- Comment From <email address hidden> 2015-07-02 15:02 EDT-------
(In reply to comment #50)
> I tried suggested scenarios, adding/removing Austin adapter.
>
> I the original eth0 interface stayed. It fixed my reported problem. Thanks!

Thanks, I think this verifies the fix. Good catch, Brian.

For Wily, I see the version of system is well past 219 so I think we can safely assume it is integrated.

For Trusty however, I see the systemd version (204) is considerably behind. I did not look a the latest 14.02.3 daily build to check. Can someone do this please?

Canonical: is this patch in the latest Trusy?

tags:

added: targetmilestone-inin1510
removed: targetmilestone-inin1504

Revision history for this message

Mathieu Trudel-Lapierre (cyphermox) wrote on 2015-07-02:

#32

No, it's not. I'm adding the Trusty task now.

Revision history for this message

bugproxy (bugproxy) wrote on 2015-07-02: 75-persistent-net-generator.rules

#33

75-persistent-net-generator.rules Edit (5.5 KiB, text/plain)

------- Comment on attachment From <email address hidden> 2015-06-22 16:49 EDT-------

Attaching the 75-persistent-net-generator.rules file.

Mathieu Trudel-Lapierre (cyphermox) on 2015-07-03

Changed in systemd (Ubuntu Wily):
assignee:	nobody → Mathieu Trudel-Lapierre (mathieu-tl)

Mathieu Trudel-Lapierre (cyphermox) on 2015-07-08

Changed in systemd (Ubuntu Trusty):
status:	New → In Progress
assignee:	nobody → Mathieu Trudel-Lapierre (mathieu-tl)

Revision history for this message

bugproxy (bugproxy) wrote on 2015-07-10: Comment bridged from LTC Bugzilla

#34

------- Comment From <email address hidden> 2015-07-10 00:43 EDT-------
(In reply to comment #54)
> No, it's not. I'm adding the Trusty task now.

Excellent, thanks!

Revision history for this message

Chris J Arges (arges) wrote on 2015-07-15: Please test proposed package

#35

Hello bugproxy, or anyone else affected,

Accepted systemd into trusty-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/systemd/204-5ubuntu20.13 in a few hours, and then in the -proposed repository.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in systemd (Ubuntu Trusty):
status:	In Progress → Fix Committed
tags:	removed: verification-done
tags:	added: verification-needed

vaishnavi (vaishnavi) on 2015-07-20

tags:

added: verification-done
removed: verification-needed

Revision history for this message

Launchpad Janitor (janitor) wrote on 2015-07-28:

#36

This bug was fixed in the package systemd - 204-5ubuntu20.13

---------------
systemd (204-5ubuntu20.13) trusty; urgency=medium

  * debian/patches/ibmveth_persistent_mac.patch: fix the exception to locally
    administered MAC addresses for ibmveth; use DRIVERS rather than SUBSYSTEMS
    to point to ibmveth. (LP: #1437375)

-- Mathieu Trudel-Lapierre <email address hidden> Wed, 08 Jul 2015 13:34:18 -0400

Changed in systemd (Ubuntu Trusty):
status:	Fix Committed → Fix Released

Revision history for this message

bugproxy (bugproxy) wrote on 2022-07-23: Comment bridged from LTC Bugzilla

#37

------- Comment From <email address hidden> 2022-07-23 09:55 EDT-------
Re-open to move to diff. component.

#=#=# 2015-04-23 10:27:57 (CDT) #=#=#
New Fix_Potential = [GSI_HDW]
#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#

Any updates on this issue? Thanks!

Some "sync" issue between CQ and bugzilla.

Please see the bugzilla: https://bugzilla.linux.ibm.com/show_bug.cgi?id=122308
The approval '*** STG AUTO-GENERATED *** Verify Fix' has been removed because the following condition was met: perform the action Close

Report a bug

This report contains Public information

Everyone can see this information.

You are

Subscribing...

Edit bug mail

Other bug subscribers

Bug attachments

Add attachment

Remote bug watches

auto-bugzilla.linux.ibm.com #122308 Edit

Bug watches keep track of this bug in other bug trackers.

Ubuntusystemd package

[udev] Adding "Austin" adapter to Ubuntu partition take over system network interface

Bug Description

Other bug subscribers

Bug attachments

Remote bug watches

Ubuntu
systemd package