http://bugzilla.suse.com/show_bug.cgi?id=963241 http://bugzilla.suse.com/show_bug.cgi?id=963241#c7 Marius Tomaschewski <mt@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(suse.dev@fea.st) --- Comment #7 from Marius Tomaschewski <mt@suse.com> --- Ahm... before you continue reading further, see the following Urls about your NetworkCard, it seems the driver does not reset the hardware as needed: https://bbs.archlinux.org/viewtopic.php?pid=1491387#p1491387 https://bbs.archlinux.org/viewtopic.php?pid=1575719#p1575719 http://ubuntuforums.org/showthread.php?t=2280968 Hmm... best place for tweaks like this would be probably an udev rule to make it as early as possible. Call: udevadm info -q all -p /sys/class/net/eno1 -a and look at the 2nd entry (pci device / first one with KERNELS variable), e.g. [from my NIC here]: looking at device '/devices/pci0000:00/0000:00:1c.4/0000:04:00.0/net/eno1': KERNEL=="eno1" SUBSYSTEM=="net" looking at parent device '/devices/pci0000:00/0000:00:1c.4/0000:04:00.0': KERNELS=="0000:04:00.0" SUBSYSTEMS=="pci" DRIVERS=="e1000e" ... The path (with /sys in the front) should contain a "reset" file: ls /sys/devices/pci0000:00/0000:00:1c.4/0000:04:00.0/reset In your case, it should be something like this: # cat /etc/udev/rules.d/69-net-reset-hack.rules SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", KERNELS=="0000:00:19.0", ATTR{device/reset}+="1" Hmm... better would be perhaps a RUN+="/root/reset-nic.sh": SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", KERNELS=="0000:00:19.0", RUN+="/root/reset-nic.sh" with /root/reset-nic.sh (do not forget "chmod +x /root/reset-nic.sh"): #!/bin/bash p="/sys${DEVPATH/net\/*/reset}" echo 1 > "$p" /usr/bin/logger -t udev-hack -- "resetting '$p' done" to avoid the interface name in the path (eth0 -> eno1 rename). [BTW: An reset on the parent device using: SUBSYSTEM=="pci", ACTION=="add", DRIVERS=="e1000e", KERNELS=="0000:04:00.0", .... was too early / didn't worked, caused "The NVM Checksum Is Not Valid" and "probe of 0000:04:00.0 failed with error -5" ...] An "udevadm test -a add /sys/class/net/eno1" should show that the script is called. When this does not help, please do not remove it, but continue with the following steps: (In reply to sd fs from comment #5)
Reading that link under section
/proc/sys/net/ipv6/* Variables:
there's both
autoconf - BOOLEAN disable_ipv6 - BOOLEAN
And there is also accept_ra=0 [don't accept], 1 [accept if host], 2 [also accept if router, forwarding=1] While accept_ra=0 disables all autoconfig steps [also default route setup, note: dhcpv6 does not handle it!], autoconf=0 disables only _address_ autoconfig.
So what are the Opensuse ifcfg-* commands for those?
There aren't any -- we're using the sysctl's (avoids setting conflicts and allows to setup with all tweaks that the kernel supports). All autoconf steps -- except of dhcpv6 -- are preformed inside of the kernel, that is there are only DHCPv6 variables (man ifcfg-dhcp); we may define some in the future, but only for parts which are not already covered by sysctl settings.
Here, is some IMO much more important problem to investigate: wickedd start issue. I don't think it is because of the bridge parameter.
Can you set WICKED_DEBUG="all" in /etc/sysconfig/network/config together with systemd debug [as you already have], boot trying to run into such issue and attach the full journal dump using: "journalctl -b --short-precise > journal.txt"
THat command doesn't work.
I guess you mean
journalctl -b -o short-precise > tmp.txt
Yes, sorry.
journalctl -b -o short-precise > ~/tmp.txt egrep -i "eno1|br0|wicked" ~/tmp.txt
What makes them mostly useless... I cannot grep in them properly, see the context start orders of all services, kernel messages, ... I can see that something blocks.... so we have to investigate further. Please _attach_ [mark private], do _not_ paste and also do _not_ grep out things; when you mean that there are some strings you don't want to attach (e.g. IP address), XXXXXX them out, but not the context of them. BTW: Make sure, NetworkManager.service is not running & disabled. Also that "systemctl status NetworkManager.service" does not show any processes... Also, there should be not other network engine (systemd-networkd.service) or other dhcp clients (dhclient process). Please enable WICKED_DEBUG=all (WICKED_LOG_LEVEL=debug or empty), copy the /usr/lib/systemd/system/wickedd.service file to /etc/systemd/system/wickedd.service and modify to the /etc... copy to use: ExecStart=/usr/bin/strace -d -s 128 -o /run/wicked/strace.out /usr/sbin/wickedd --systemd --foreground then call "systemctl daemon-reload" and reboot (with kernel parameters: systemd.log_level=debug systemd.log_target=journal-or-kmsg). After login, remove /etc/systemd/system/wickedd.service again and call: systemctl daemon-reload systemctl stop wickedd journalctl -b -o short-precise > journal.txt And attach journal.txt and /run/wicked/strace.out then / move them to some persistent storage path so you can attach them later. After it, you can disable debugging and: systemctl restart wickedd systemctl start wicked wicked ifup all
Changing ONLY
cat /etc/sysconfig/network/config ... WICKED_DEBUG="" WICKED_LOG_LEVEL="notice"
then just rebooting, the system & network come up with NO error. Fully functional.
Hmm... very strange. This _could_ mean, it gets blocked why it is trying to log something...? and then killed by systemd [this is what happens] But I cannot see what happens without the full logs. Which log configuration are you using? Is there some syslog daemon running (systemctl status syslog), and user database in e.g. ldap? I cannot see whether this is the case or not, but I know, that there is a deadlock (were in the past): syslog daemon trying to resolve user id for user "foo" -> ldap query a locally running ldap server is trying to log the query -> deadlock because the glibc sets a lock / mutex (can be addressed only in glibc) to some global things [syslog() and getpwnam() function cause to set it]. -> Never use ldap users as file owners for log files in syslog daemons. -- You are receiving this mail because: You are on the CC list for the bug.