Hi,
anybody noticed issues with persistent nic renaming (aka /etc/udev/rules.d/70-
persistent-net.rules) on fresh installations/hardware upgrades of TW lately?
I haven't got to the bottom of this, but it seems like the renaming of
interfaces fails randomly. On one system, I "fixed" this by force loading of
the "eth0" driver in initrd. Apparently, the issue is somewhat related with
the order of driver loads. This is accompanied with some behavioral changes
related to MTU. Without specifying a proper MTU (eg. 1500) static interface
setups aren't performed correctly.
So far, yast, systemd and wickedd seems to be involved.
This is the working state:
19: PCI 800.0: 0200 Ethernet controller
[Created at pci.386]
Unique ID: rBUF.qdX+b0QYyl2
Parent ID: Phdb.8EPKPINKVS0
SysFS ID: /devices/
pci0000:00/0000:00:01.3/0000:02:00.2/0000:03:07.0/0000:08:00.0
SysFS BusID: 0000:08:00.0
Hardware Class: network
Model: "Intel PRO/1000 PT Desktop Adapter"
Vendor: pci 0x8086 "Intel Corporation"
Device: pci 0x10b9 "82572EI Gigabit Ethernet Controller (Copper)"
SubVendor: pci 0x8086 "Intel Corporation"
SubDevice: pci 0x1083 "PRO/1000 PT Desktop Adapter"
Revision: 0x06
Driver: "e1000e"
Driver Modules: "e1000e"
Device File: eth0
Memory Range: 0xf6540000-0xf655ffff (rw,non-prefetchable)
Memory Range: 0xf6520000-0xf653ffff (rw,non-prefetchable)
I/O Ports: 0xd000-0xefff (rw,disabled)
Memory Range: 0xf6500000-0xf651ffff (ro,non-prefetchable,disabled)
IRQ: 52 (382935 events)
HW Address: 00:15:17:23:eb:a2
Permanent HW Address: 00:15:17:23:eb:a2
Link detected: yes
Module Alias: "pci:v00008086d000010B9sv00008086sd00001083bc02sc00i00"
Driver Info #0:
Driver Status: e1000e is active
Driver Activation Cmd: "modprobe e1000e"
Config Status: cfg=no, avail=yes, need=no, active=unknown
Attached to: #47 (PCI bridge)
43: PCI 400.0: 0200 Ethernet controller
[Created at pci.386]
Unique ID: JNkJ.eyqrN5GWcA7
Parent ID: svHJ.8EPKPINKVS0
SysFS ID: /devices/
pci0000:00/0000:00:01.3/0000:02:00.2/0000:03:00.0/0000:04:00.0
SysFS BusID: 0000:04:00.0
Hardware Class: network
Model: "Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller"
Vendor: pci 0x10ec "Realtek Semiconductor Co., Ltd."
Device: pci 0x8168 "RTL8111/8168/8411 PCI Express Gigabit Ethernet
Controller"
SubVendor: pci 0x1043 "ASUSTeK Computer Inc."
SubDevice: pci 0x8677
Revision: 0x15
Driver: "r8169"
Driver Modules: "r8169"
Device File: eth1
I/O Ports: 0xe000-0xefff (rw)
Memory Range: 0xf6604000-0xf6604fff (rw,non-prefetchable)
Memory Range: 0xf6600000-0xf6603fff (rw,non-prefetchable)
IRQ: 35 (no events)
HW Address: 24:4b:fe:50:69:13
Permanent HW Address: 24:4b:fe:50:69:13
Link detected: yes
Module Alias: "pci:v000010ECd00008168sv00001043sd00008677bc02sc00i00"
Driver Info #0:
Driver Status: r8169 is active
Driver Activation Cmd: "modprobe r8169"
Config Status: cfg=no, avail=yes, need=no, active=unknown
Attached to: #7 (PCI bridge)
In the non-working state, wicked will setup lo only, resulting in "no net"
state. Since this is a remote system, that state isn't exactly funny...
Does that rings a bell for anybody here?
Will create a #boo after have collecting enough infos.
Cheers,
Pete