On Wed, Feb 19, 2014 at 2:15 PM, Stephen Powell <zlinux...@wowway.com>wrote:
> 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 debian-s390-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact > listmas...@lists.debian.org > Archive: > http://lists.debian.org/903639687.1034419.1392840906968.javamail.r...@md01.wow.synacor.com > > My initial response to your response was short, sharp and yes, crude, but.... I sent this problem report to the wrong group. There is no correct way to use debian. As I said in a post on my original issues with hercules and debian-390 testing, I use debian because it gives me what I need from a distro. I do not use the debian supplied version of hercules, it does not provide the functionality I need, so I use later versions from the github repo. I use bash as my default shell, for all non-root work, I do not use dash nor am I interested in why debian uses dash. I use later kernels to fix stall problems on my AMD cpus, I could go on and on. I use debian the way I want to, if I wanted to be dictated to about how I use my systems I would use OSX or Windows. My goal is to test new functionality in hercules, if this means I misuse or abuse debian and or it's tools then so be it. I worked with real mainframe boxes both as an engineer and a systems programmer for more than 40 years, during that time I always had the belief, philosophy if you like, that there was always some who knew more than I on any given subject. To summarize, please don't presume to lecture me, particularly as you said in your first sentence "I admit that I don't understand all that you have written", without first trying to ascertain the questioners level of expertise. If you feel you can help in the spirit the question was posed in, then great, otherwise.......
