Bugzilla – Bug 677251
"rcnetwork stop" skips eth0/wlan0 (misconfigured as STARTMODE=nfsroot)
Last modified: 2012-01-31 16:20:01 UTC
I cannot use "rcnetwork stop" to shutdown my network interfaces on openSUSE 11.4 anymore. hp2510p:~ # rcnetwork stop Shutting down network interfaces: eth0 device: Intel Corporation 82566MM Gigabit Network Connection (rev 03) eth0 serves root filesystem. Leave it up. eth0 skipped wlan0 device: Intel Corporation PRO/Wireless 4965 AG or AGN [Kedron] Network Connection (rev 61) wlan0 serves root filesystem. Leave it up. wlan0 skipped Shutting down service network . . . . . . . . . done I don't know why the system thinks that one of these devices serve the root filesystem, but the ifcfg-$dev files for both devices in /etc/sysconfig/network contain a string STARTMODE='nfsroot' which cause these behavior. Is it intended or a bug? Can I change the STARTMODE value back to 'onboot' which was used in openSUSE 11.3?
I don't know why they were changed to "nfsroot", but you can certainly change them back to "onboot".
(In reply to comment #0) > I cannot use "rcnetwork stop" to shutdown my network interfaces on openSUSE > 11.4 anymore. [...] > I don't know why the system thinks that one of these devices serve the root > filesystem, but the ifcfg-$dev files for both devices in /etc/sysconfig/network > contain a string STARTMODE='nfsroot' which cause these behavior. Yes, this is the job of 'nfsroot' to avoid that the network gets stopped. > Is it intended or a bug? Can I change the STARTMODE value back to 'onboot' > which was used in openSUSE 11.3? IMO a bug. YaST2 should not use 'nfsroot' when there is no reason for. It forces the users to reboot for any network config change or to manually revert to use STARTMODE='auto' (or onboot). Martin, would you take a look why yast2 sets 'nfsroot' here?
Christopher, do you have YaST logs going back to the installation time? If yes, please attach them. http://en.opensuse.org/openSUSE:Bugreport_YaST
Created attachment 417891 [details] yast2 logs Having the same here with an 11.4 install on a laptop.
2011-03-02 17:53:06 <1> linux(2735) [YCP] LanItems.ycp:622 is item 0 configured? false ... 2011-03-02 17:53:06 <1> linux(2735) [YCP] LanItems.ycp:968 Product startmode: ifplugd ^^^^^^^ 2011-03-02 17:53:06 <1> linux(2735) [YCP] LanItems.ycp:977 For NetworkManager will not prefer ifplugd 2011-03-02 17:53:06 <1> linux(2735) [YCP] network/complex.ycp:276 hwname= 2011-03-02 17:53:06 <1> linux(2735) [YCP] network/complex.ycp:276 hwname= 2011-03-02 17:53:06 <1> linux(2735) [YCP] network/complex.ycp:276 hwname= 2011-03-02 17:53:06 <1> linux(2735) [YCP] LanItems.ycp:788 SetDefaultsForHW type wlan 2011-03-02 17:53:06 <1> linux(2735) [YCP] NetworkStorage.ycp:20 mountpoint found $["exit":0, "stderr":"", "stdout":"/dev/sda7 / ext4 rw,relatime,user_xattr,acl,barrier=1,data=ordered 0 0"] 2011-03-02 17:53:06 <1> linux(2735) [YCP] NetworkStorage.ycp:25 / is on device: /dev/sda7 2011-03-02 17:53:06 <1> linux(2735) [YCP] NetworkStorage.ycp:35 begin isDiskOnNetwork(/dev/sda7) function 2011-03-02 17:53:07 <2> linux(2735) [YCP] NetworkStorage.ycp:119 FCoE detected! ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 2011-03-02 17:53:07 <1> linux(2735) [YCP] LanItems.ycp:1412 startmode nfsroot ^^^^^^^ 2011-03-02 17:53:07 <1> linux(2735) [YCP] network/complex.ycp:276 hwname=PRO/Wireless 3945ABG [Golan] Network Connection Looking at the logs, I'd say it is caused by the recently added FCoE support...
So isDiskOnNetwork(/dev/sda7) tries to detect FCoE by grepping for "target" in `ls -la /sys/class/block/sda7`. But that is a false positive, since the output on my 11.3 is lrwxrwxrwx 1 root root 0 8. bře 09.52 /sys/class/block/sda2 -> ../../devices/pci0000:00/0000:00:12.0/host0/target0:0:0/0:0:0:0/block/sda/sda2/ The misconfiguration occurs during the Automatic Configuration phase of the second installation stage (both DVD and Live CD).
Notes to myself as I map the offending feature: The FCoE feature is https://fate.novell.com/306855 , implemented in commits 63006 to 63014: http://svn.opensuse.org/viewcvs/yast?rev=63014&view=rev Released: SLE11 SP1: yast2-network-2.17.151 yast2-2.17.93 11.4: yast2-network-2.20.9 yast2-2.20.6
Hannes, how can I properly detect whether a block device is backed by FCoE? The method in comment 6 is wrong and causes this bug. More broadly, what do I need to get and learn to be able to test this bug and the original feature?
Hehe, grepping for 'target' is most definitely wrong; each SCSI device will have a 'target' string somewhere in the syspath. The thing with FCoE devices is that they'll have an 'ethX' device somewhere in the SCSI syspath. Hmm. Sadly I've thrashed my FCoE setup so that currently no FCoE disks are available. Need to reconfigure that before I can give you an example.
BTW: In my last installation two ifcfg files have been written: "ifcfg-eth0": BOOTPROTO='dhcp4' STARTMODE='nfsroot' NAME='MCP77 Ethernet' "ifcfg-": BOOTPROTO="static" STARTMODE="nfsroot" ETHERDEVICE="" USERCONTROL="no" The second one is crap and will be ignored by rcnetwork, but it may potentially cause some trouble in another places ...
So, fixed up my FCoE setup. The device path for an FCoE device is eg /sys/devices/virtual/net/eth3.200/host6/rport-6:0-4/target6:0:2/6:0:2:1 as mentioned, all SCSI devices have a 'target' bit in it, but only the FCoE ones will have an 'eth' bit.
(In reply to comment #11) > /sys/devices/virtual/net/eth3.200/host6/rport-6:0-4/target6:0:2/6:0:2:1 ^^^^^^^^ Ah... this explains the "ifcfg-" file. When there is FCoE in use, there have to be two ifcfg files: ifcfg-eth3: BOOTPROTO='dhcp4' STARTMODE='nfsroot' USERCONTROL="no" ifcfg-eth3.200: BOOTPROTO="static" STARTMODE="nfsroot" ETHERDEVICE="eth3" USERCONTROL="no" Iteressting would be to know if there is somewhere a link in the FCoE devpath directory pointing directly to the .../eth3.200 directory ...
> Iteressting would be to know if there is somewhere a link in the FCoE > devpath directory pointing directly to the .../eth3.200 directory ... ??? What exactly do you mean with that? The devpath contains the eth3.200 directory, check comment #11.
(In reply to comment #13) > > Iteressting would be to know if there is somewhere a link in the FCoE > > devpath directory pointing directly to the .../eth3.200 directory ... > > ??? What exactly do you mean with that? > The devpath contains the eth3.200 directory, check comment #11. You've just provided the (expanded) path. A grep "/eth2.300/" $fcoepath may be not so good to find it out ... It would be interessting to know, if there is a (back reference to FCoE) link bellow of /sys/class/net/eth3.200/, that points to FCoE and/or if there is also a reference link bellow of the FCoE devipath pointing to the interface path /sys/class/net/eth3.200 (or /sys/devices/virtual/net/eth3.200). It seems, there is one: /sys/devices/virtual/net/eth3.200/<some path> points to the /sys/devices/virtual/net/eth3.200/host6/rport-6:0-4/target6:0:2/6:0:2:1 path -- it would make sense to know the name of <some path>. Analogue to /sys/class/net/$ifname/brport/bridge and /sys/class/net/$bridge/brif/$ifname "basename $(readlink /sys/class/net/$ifname/brport/bridge)" => bridge name. Could you attach "ls -lR /sys/class/net/eth3.200" and "ls -lR $fcoepath" output or something like that? Or give us access to the FCoE machine?
OK ... AFAIS, there is a /sys/class/net/eth3.200/host6 directory that can be checked; another (vlan) interfaces don't have any. The directories under host6, seem to be FCoE device specific. When there is always a vlan interface used for FCoE , this script will show all FCoE vlans and the underlying devices: for v in $(ls -1 /proc/net/vlan/ 2>/dev/null) ; do case $v in ""|config) continue ;; esac test -f "/proc/net/vlan/$v" || continue if test -d "/sys/class/net/$v" -a \ -d "/sys/class/net/$v/host6" ; then echo "vlanif=$v" while read key val ; do case $key in Device:) echo "device=$val" ;; esac done < "/proc/net/vlan/$v" 2>/dev/null echo "" fi done Example output: vlanif=eth3.200 device=eth3
OK, I interviewed Hannes a bit by phone. - A vlan interface is not mandatory for FCoE -- it may also go directly over the eth interface - The interface dir may be contain also subdirs with another host numbers, that is, it is needed to check if there is a /sys/class/net/$v/host* dir (at least host[0-9]+). Better seems to check if there are /sys/class/net/$ifname/host*/fc_host directories. So this code should be better to show all interfaces used by FCoE: for i in $(ls -1 /sys/class/net/ 2>/dev/null) ; do d="/sys/class/net/$i" test "x$i" != x -a -d "$d" || continue h=$(ls -1d "$d/"host*/fc_host 2>/dev/null) if test "x$h" != x ; then if test -f "/proc/net/vlan/$i" ; then e='' while read key val ; do case $key in Device:) e=$val ;; esac done < "/proc/net/vlan/$i" 2>/dev/null echo "$i $e" else echo "$i" fi fi done It ouputs "<vlan-interface> <ether device>" in case FCoE makes use of a vlan interface, and "<interface>" when not. OK, Martin, your turn :-)
This is an autogenerated message for OBS integration: This bug (677251) was mentioned in https://build.opensuse.org/request/show/76788 Factory / yast2
I ended up fixing it differently, as Hannes suggested in https://fate.novell.com/306855#comment_22 : """ you need to check the _resulting_ device patch you'll end up with when evaluating cd -P /sys/block/sdX/device. IE you need to grep for 'target' over for path in /sys/block/* ; do cd -P $path/device; echo $PWD; done """ http://svn.opensuse.org/viewvc/yast/trunk/yast2/library/network/src/NetworkStorage.ycp?annotate=64960&pathrev=64960#l118 for SP2 it is in Beta1 already: - yast2-network-2.17.158 (sr #12917) - yast2-2.17.99 (sr #12920) Trunk: - http://svn.opensuse.org/viewvc/yast?view=revision&revision=64960 - http://svn.opensuse.org/viewvc/yast?view=revision&revision=64967 12.1: - yast2-2.21.6, https://build.opensuse.org/request/show/76788 - yast2-network-2.21.0 https://build.opensuse.org/request/show/76800
*** Bug 721203 has been marked as a duplicate of this bug. ***
*** Bug 711713 has been marked as a duplicate of this bug. ***
*** Bug 672075 has been marked as a duplicate of this bug. ***