On Tue, 18 Feb 2014 21:14:53 -0500 (EST), David Clements wrote: > > I have been doing a lot of qeth testing both layer2 and layer3 and > have run into a problem when using the iface parameter on the qeth > definition. > ...
I admit that I don't understand all that you have written. For one thing, I'm using the version of Hercules that is packaged for Debian, which is release 3.07, and have no familiarity with the QETH driver in newer versions of Hercules at all. Consequently, I have no idea whether you have configured things properly on the Hercules side or not. It sounds to me like you are asking Debian s390x porters to debug Hercules for you. If you suspect a bug in Hercules, you should report this problem to the Hercules developers. As for Debian, I don't know enough about the tools you are using to be able to tell if there is a bug in Debian or not, but I can tell you that you are not using Debian the way it is designed to work. But before I get into that, let me say one thing. The default shell in Debian is no longer bash, but dash. /bin/sh is a symbolic link to /bin/dash on newer Debian systems. Consequently, any shell script which starts out with "#!/bin/sh" will be executed by dash, not bash. Consequently, any coding in the shell script which uses constructs supported only by bash is likely to fail. As of s390-tools 1.17.1, there are a couple of shell scripts which come with s390-tools that start out with "#!/bin/sh" but which contain "bashisms": code that only works with bash. The Debianized package contains patches to change this to "#!/bin/bash", but the upstream version that you are using may not have these changes. Check lstape and chiucvallow, and, if they start with "#!/bin/sh", change these to "#!/bin/bash", as these scripts contain bashisms. (At least at the 1.17.1 level they do.) Interestingly enough, chiucvallow is another command, which, like znetconf, is present in the Debian source package for s390-tools, but didn't make it to the binary version of the package for some reason. Now back to my main subject. For network devices in Debian for s390x, hardware configuration is designed to be done by sysconfig-hardware, and software configuration is designed to be done by ifupdown. These two packages "front-end" the lower level commands. If you use the network device during installation, the Debian installer will create the appropriate configuration file for you in /etc/sysconfig/hardware for sysconfig-hardware, and will also configure the device for you in /etc/network/interfaces for ifupdown. If you create a new network device after installation, or if the network device existed prior to installation but you did not use it during installation, then you will have to create these configurations manually. Here is an example from my system described on my "Debian Under Hercules" web page: http://users.wowway.com/~zlinuxman/hercules.htm. The file is called /etc/sysconfig/hardware/config-ccw-0.0.1000, and its contents are as follows: CCWGROUP_CHANS=(0.0.1000 0.0.1001) CTC_PROTOCOL=0 This is for a channel-to-channel adapter with device number 1000 as the read device, device number 1001 as the write device, and protocol 0 (s390). Here is another example for an Open Systems Adapter Express in QDIO layer 3 mode from another system. The file name is /etc/sysconfig/hardware/config-ccw-0.0.0300, and its contents are as follows: CCWGROUP_CHANS=(0.0.0300 0.0.0301 0.0.0302) Documentation for the contents of these files is, unfortunately, poor. The best way to find out is to use one of these devices for a Debian install. I don't know what the above file would look like if the device were a layer 2 device, but based on reading the source code, I'm guessing that it would be something like this: CCWGROUP_CHANS=(0.0.0300 0.0.0301 0.0.0302) QETH_OPTIONS=layer2 So, anyway, the first step is to create one of these configuration files with an appropriate name in /etc/sysconfig/hardware. sysconfig-hardware will then configure the device and bring it online during boot. By the way, while we're on the subject of sysconfig-hardware, I strongly recommend that you apply the patch for Debian bug number 620095 (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=620095) to sysconfig-hardware. Otherwise, you will never be able to get a device offline that was configured by sysconfig-hardware. The patch basically consists of changing SUBSYSTEM=="ccw", RUN+="/sbin/hwup -A -D $devpath $env{SUBSYSTEM} $kernel" to SUBSYSTEM=="ccw", ACTION=="add", RUN+="/sbin/hwup -A -D $devpath $env{SUBSYSTEM} $kernel" in /lib/udev/rules.d/85-sysconfig-hardware.rules. On the software side, all interfaces are configured in /etc/network/interfaces. for example, here is what the definition for my layer3 QETH device looks like: # The primary network interface auto eth0 iface eth0 inet static address 10.14.80.48 netmask 255.255.255.0 network 10.14.80.0 broadcast 10.14.80.255 gateway 10.14.80.1 # dns-* options are implemented by the resolvconf package, if installed dns-nameservers 10.14.80.5 10.14.80.9 10.14.6.24 dns-search my.employers.network.us (Well, OK, I lied about the dns-search option. That's not the real domain name. The name was changed to protect my employer's identity.) Here is what my CTCA device in protocol 0 mode looks like on one of my home Debian system under Hercules: # The primary network interface auto ctc0 iface ctc0 inet static address 192.168.1.9 netmask 255.255.255.252 network 192.168.1.8 broadcast 192.168.1.11 gateway 192.168.1.10 pointopoint 192.168.1.10 mtu 1500 # dns-* options are implemented by the resolvconf package, if installed dns-nameservers 192.168.0.1 dns-search my.home.network.us (Again, I lied about the domain name for anonymity's sake.) As you can see, the options are about the same. I had to add "pointopoint" as an option for this device, since it is a point-to-point connection. And I added "mtu" for technical reasons. "mtu" could have been specified for the eth0 interface too, but I chose to leave it off. Some of the above options are not used or are ignored for this device, such as broadcast, but it doesn't hurt to specify them for documentation purposes. If you have two QETH devices defined at the same time, one layer 3 and one layer 2, for example, then one of them will be called eth0 and the other will be called eth1. The trick is to figure out which is which. This is controlled by a file called /etc/udev/rules.d/70-persistent-net.rules. On the i386 or amd64 platform, devices are generally identified by MAC address. But on the s390x platform, they are generally identified by device number. If this file is missing, you can determine the correspondence from sysfs. For example, cat /sys/bus/ccwgroup/devices/0.0.0300/ifname might produce eth0 Once you know the correspondence between device numbers and interface names, you will know how to configure the interface names in /etc/network/interfaces. If you want the interface to come up automatically during boot, you can add an "auto" statement to the file, such as auto eth0 If not, you can manually bring the interface up by means of ifup eth0 You can manually take an interface down with ifdown eth0 In short, I recommend that you configure these network devices the way Debian was designed to work. If Hercules is working properly, and you have configured your interfaces properly in both Hercules and Debian, it should "just work". If not, asking for help on this list with your devices configured the "Debian way" will likely cause better recognition of the problem by Debian users. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/903639687.1034419.1392840906968.javamail.r...@md01.wow.synacor.com
