[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#684766: persistent-net-generator broken on s390(x)



Package: udev
Version: 175-3.1
Severity: important

The network devices on s390(x) seem to increase their dev_id by one on every
reboot. Hence we get something like this with a new device coming up whenever
the VM is rebooted:

| # S/390 device at 0.0.0300 (qeth)  
| SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="e4:1f:13:4e:25:1a", ATTR{dev_id}=="0x14", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"  
|
| # S/390 device at 0.0.0300 (qeth)  
| SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="e4:1f:13:4e:25:1a", ATTR{dev_id}=="0x15", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"  
|
| # S/390 device at 0.0.0300 (qeth)  
| SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="e4:1f:13:4e:25:1a", ATTR{dev_id}=="0x16", ATTR{type}=="1", KERNEL=="eth*", NAME="eth2"  

This is not overly helpful. The persistent-net-generator has these rules
commented out:

| # S/390 interfaces are matched only by id
| SUBSYSTEMS=="ccwgroup", \
|         ENV{MATCHDRV}="$driver", ENV{MATCHID}="$id", ENV{MATCHADDR}=""

This establishes persistent naming based on the device ID, which is stable on
s390(x). That's the "0.0.0300" listed in the comment. I don't think it should
match on the MAC address, as this is not configured explicitly by default.
Instead the commented out matching rules make more sense. However they alone
are not sufficient as this rule creates dev_id matching unconditionally:

| ATTR{dev_id}=="?*", ENV{MATCHDEVID}="$attr{dev_id}"

With this rule commented out I get this (two NIC case):

| # S/390 device at 0.0.0300 (qeth)
| SUBSYSTEM=="net", ACTION=="add", DRIVERS=="qeth", KERNELS=="0.0.0300", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
|
| # S/390 device at 0.0.0304 (qeth)
| SUBSYSTEM=="net", ACTION=="add", DRIVERS=="qeth", KERNELS=="0.0.0304", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"

This seems to be stable.

Marco, could you come up with a fix that rearranges the dev_id properly so that
it's not added to the matching rules for ccwgroup devices? The only "solution"
so far for squeeze and wheezy is to delete the persistent-net-generator, but I
don't agree with that one. And I don't suppose that we want to add
SUBSYSTEM!="ccwgroup" to that dev_id rule.

Thanks in advance
Philipp Kern


Reply to: