[Bug 908736] New: wicked breaks usage of Predictable Network Interface Names with kernel-xen+xen
http://bugzilla.suse.com/show_bug.cgi?id=908736 Bug ID: 908736 Summary: wicked breaks usage of Predictable Network Interface Names with kernel-xen+xen Classification: openSUSE Product: openSUSE Distribution Version: 13.2 Hardware: x86-64 OS: openSUSE 13.2 Status: NEW Severity: Normal Priority: P5 - None Component: Network Assignee: bnc-team-screening@forge.provo.novell.com Reporter: grantksupport@operamail.com QA Contact: qa-bugs@suse.de Found By: --- Blocker: --- a 13.2 server, booted to kernel-default, works with auto interface naming. re-booting to xen host Linux lab003 3.17.4-3.gbde0c3f-xen #1 SMP Fri Dec 5 16:20:27 UTC 2014 (bde0c3f) x86_64 x86_64 x86_64 GNU/Linux with xen-4.4.1_06-342.1.x86_64 physical/ethernet devices using automated interface naming, and the bridges that use them, are no longer brought up ... Dec 06 21:23:13 lab003 wickedd[1480]: failed to install generic settings Dec 06 21:23:13 lab003 ModemManager[1430]: <warn> Couldn't find support for device at '/sys/devices/pci0000:00/0000:00:04.0/0000:02:00.0': not supported by any plugin Dec 06 21:23:13 lab003 ModemManager[1430]: <warn> Couldn't find support for device at '/sys/devices/pci0000:00/0000:00:06.0/0000:03:00.0': not supported by any plugin Dec 06 21:23:15 lab003 kernel: Unable to read sysrq code in control/sysrq Dec 06 21:23:16 lab003 systemd[1]: xend.service: Supervising process 1577 which is not our child. We'll most likely not notice when it exits. Dec 06 21:23:16 lab003 systemd[1]: Starting Xen-watchdog - run xen watchdog daemon... Dec 06 21:23:41 lab003 wicked[1495]: device brA failed: operation timed out Dec 06 21:23:41 lab003 wicked[1495]: device brB failed: operation timed out Dec 06 21:23:41 lab003 wicked[1495]: device enp3s0 failed: operation timed out Dec 06 21:23:41 lab003 wicked[1495]: device enp2s0 failed: operation timed out Dec 06 21:23:41 lab003 systemd-journal[801]: Forwarding to syslog missed 26 messages. Dec 06 21:23:41 lab003 wicked[1495]: lo up Dec 06 21:23:41 lab003 wicked[1495]: brA device-not-running Dec 06 21:23:41 lab003 wicked[1495]: brB device-not-running Dec 06 21:23:41 lab003 wicked[1495]: enp2s0 no-device Dec 06 21:23:41 lab003 wicked[1495]: enp3s0 no-device Dec 06 21:23:41 lab003 systemd[1]: Starting Network. Dec 06 21:23:41 lab003 systemd[1]: Reached target Network. ... the system reaches shell, but with no eth/bridge interfaces -- no external/lan networking disabling ifname'ing by adding to grub net.ifnames=0 adding a persistent udev rule ls -al /etc/udev/rules.d/70-persistent-net.rules (empty) cat << EOF > /etc/udev/rules.d/70-persistent-net.rules SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="xx:xx:xx:xx:xx:xx", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1" SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="yy:yy:yy:yy:yy:yy", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0" EOF and renaming instances of enp2s0 -> eth0 enp3s0 -> eth1 in /etc/sysconfig/network/* fixes the problem; system now boots correctly, with fully functional networking ip link 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master brB state UP mode DEFAULT group default qlen 1000 link/ether yy:yy:yy:yy:yy:yy brd ff:ff:ff:ff:ff:ff 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master brA state UP mode DEFAULT group default qlen 1000 link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff 4: brA: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff 5: brB: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default link/ether yy:yy:yy:yy:yy:yy brd ff:ff:ff:ff:ff:ff -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=908736 grant k <grantksupport@operamail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Found By|--- |Community User Assignee|bnc-team-screening@forge.pr |wicked-maintainers@suse.de |ovo.novell.com | Target Milestone|--- |13.2 QA Contact|qa-bugs@suse.de | Severity|Normal |Major -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=908736 Marius Tomaschewski <mt@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mt@suse.com --- Comment #1 from Marius Tomaschewski <mt@suse.com> --- Wicked has _nothing_ to do with interface names except that it needs them stable. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=908736 Marius Tomaschewski <mt@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|wicked-maintainers@suse.de |systemd-maintainers@suse.de --- Comment #2 from Marius Tomaschewski <mt@suse.com> --- Reassign to (systemd-)udev maintainer as the behavior which name scheme is used seems to be kernel depending / inconsistent. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=908736 Robert Milasan <rmilasan@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rmilasan@suse.com Flags| |needinfo?(mt@suse.com) --- Comment #3 from Robert Milasan <rmilasan@suse.com> --- Marius, how is this udev? if by using the classic naming, it works? I see from the logs that udev has named the devices, enp2s0 and enp3s0, udev's job is done, wicked needs to setup whatever there is. If I misunderstood the issue, please explain. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=908736 --- Comment #4 from grant k <grantksupport@operamail.com> --- (In reply to Robert Milasan from comment #3)
Marius, how is this udev? if by using the classic naming, it works?
I see from the logs that udev has named the devices, enp2s0 and enp3s0,
that's correct. they're named, just not used.
udev's job is done, wicked needs to setup whatever there is.
If I misunderstood the issue, please explain.
which component is this? systemd, wicked, (kernel-)xen, or other? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=908736 --- Comment #5 from Robert Milasan <rmilasan@suse.com> --- I should be wicked, that what handles the network setup. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=908736 Andrei Borzenkov <arvidjaar@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |arvidjaar@gmail.com, | |grantksupport@operamail.com Flags| |needinfo?(grantksupport@ope | |ramail.com) --- Comment #6 from Andrei Borzenkov <arvidjaar@gmail.com> --- (In reply to Robert Milasan from comment #3)
I see from the logs that udev has named the devices, enp2s0 and enp3s0,
Which logs? There is nothing attached; and if you mean part quoted in original message, I can only see that wicked tries to bring up devices ep2s0 and enp3s0. I see no indications that these names actually exist (and wicked failure is strong hint they do not).
If I misunderstood the issue, please explain.
See above. (In reply to grant k from comment #0) Please show output of "ifconfig -a" and "ls -l /sys/class/net" without your custom rule. Booting with udev.log-priority=debug and attaching output of "journalctl -b" may be helpful. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=908736 --- Comment #7 from grant k <grantksupport@operamail.com> --- after upgrade to rpm -qa | grep -i wicked wicked-service-0.6.15-8.1.x86_64 libwicked-0-6-0.6.15-8.1.x86_64 wicked-0.6.15-8.1.x86_64 systems are, once again, unbootable. editing @ grub - net.ifnames=0 + net.ifnames=1 allows the system to boot a lucky 'bonus' is that this is still broken enough that the system still comes up with specified interface names (eth0, eth1, eth2), NOT the auto-named interfaces. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=908736 --- Comment #8 from grant k <grantksupport@operamail.com> --- The wicked upgrade, plus any/all concurrent upgrades, apparently have (at least) increased timing of boot stages. This apparently causes failures in device mount & local-fs service dependencies. Those failures wrought havoc with wicked's startup. This fix is relevant https://bbs.archlinux.org/viewtopic.php?pid=1180367#p1180367 and solves the problem. Here, all !/boot partitions are on LVM-on-RAID. Specifically creating a delaying systemd unit for required fstab mounts does the trick. Not clean, but works. With that in place, switching back to net.ifnames=0 @ boot now completes successfully, using my net name assignments, and without any boot issues, so far. disabling that unit reproduces the problem. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=908736 http://bugzilla.suse.com/show_bug.cgi?id=908736#c9 Franck Bui <fbui@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |fbui@suse.com Resolution|--- |WONTFIX --- Comment #9 from Franck Bui <fbui@suse.com> --- 13.2 is EOL now so I'm closing it. Feel free to re-open it if you're still facing this issue with a supported distro. -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠novell.com