RE: [waldi@debian.org: Re: [tsec-gf] Re: will s390 have a working installer for sarge?]
On Wed, 2004-06-02 at 14:45, David Boyes wrote:
> > Okay, so the remaining problems are:
> > - zipl-installer, not available(?)
>
> OK, so this needs to be written/done.
What does this entail? It seems as if it should be a matter of putting
zipl on the base image and just feeding it the right parameters. Am I
missing something major here?
> > - cdebconf
> > - text frontend don't respect dumb terminal definition,
> > should disable
> > translations.
>
> This sounds like a general problem. TTY on serial console would have the
> same problem.
How deeply embedded are the generation of ANSI control codes or whatever
is generating that? I agree with David here--in the base case, you
ought to be able to install from an actual teletype if you wanted to.
> > - s390-netdevice
> > - iucv support.
>
> OK. We can look into this one. Adam, this should be similar to the
> bootparms stuff we did in terms of prompting for and supplying the right
> parms.
Yeah, I see where it's failing in the install script, but not why.
> > - fails silent the first time on the test machine, needs some debug
> > and the file /proc/chandev from the testmachine.
>
> Is this for IUCV or for CTC/etc? IUCV doesn't have a chandev entry
> because its not really a device (there's no channel associated with it).
As I recall, there are two pieces to the current IUCV driver: there's
iucv.o (.ko in 2.6, I guess), which provides the actual IUCV function,
and netiucv.o(.ko), which provides the IP-over-IUCV implementation. Are
both of them getting loaded? The iucv/netiucv split might be what's
tripping us up.
The questions IUCV needs answered are almost exactly those of CTC. You
don't need a device address, but in its place you do need a peer name:
the VM userid of whatever's at the other end of the link. "TCPIP" is
the right default for that. Other than that, you need your IP address
and the address of the other end of the IUCV link, and that should do
it. You need IUCV ALLOW statements, but there's no way to test that
from Linux, and since I doubt we have cpint in the base image, there's
really not even a way to test that the other end is logged on and
configured. I think really all you can do is bring up your interface
and then try pinging the other end to see whether traffic's getting
through.
My basic question is, where do we go to get the most recent
state-of-stuff to begin working from? Configuring the VM side of the
TCPIP links is no problem at all--we've got a secondary TCPIP user set
up for just such an eventuality, which we can bounce with impunity
without affecting any of our production work, so we can certainly test
different network configurations quite easily.
Adam
Reply to: