Re: [waldi@debian.org: Re: [tsec-gf] Re: will s390 have a working installer for sarge?]
On Wed, Jun 02, 2004 at 03:45:29PM -0400, David Boyes wrote: - ssh (the support is finished in the glibc cvs and openssh package), this needs the possibility to restart cdebconf. ??? woody had ssh, and things haven't changed much for that. Maybe I'm misunderstanding what's needed here. The udeb is in the archive. The logic to build keys and start the server is not yet implemented. - 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. serial is mostly vt100 compatible which supports 8bit. - 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. The exists a debian-installer/kernel/parameter value in the debconf db which should be filed with the values. s390-dasd also needs to seed it. - 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). QETH, I don't know what the real problem is. Bastian -- Our missions are peaceful -- not for conquest. When we do battle, it is only because we have no choice. -- Kirk, The Squire of Gothos, stardate 2124.5 signature.asc Description: Digital signature
RE: [waldi@debian.org: Re: [tsec-gf] Re: will s390 have a working installer for sarge?]
Okay, so the remaining problems are: - zipl-installer, not available(?) OK, so this needs to be written/done. - ssh (the support is finished in the glibc cvs and openssh package), this needs the possibility to restart cdebconf. ??? woody had ssh, and things haven't changed much for that. Maybe I'm misunderstanding what's needed here. - language-/countrychooser at the begining is annoying - 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. - as discussed, default items should be prefixed with an asterisk or similar. Ditto. - 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. - 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). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [waldi@debian.org: Re: [tsec-gf] Re: will s390 have a working installer for sarge?]
... let's move this to the mailing list so other people can comment. * David Boyes [EMAIL PROTECTED] [2004-06-02 15:45]: Okay, so the remaining problems are: - zipl-installer, not available(?) OK, so this needs to be written/done. There seems to be some code in d-i/packages/arch/s390 for this, but I'm not sure how well it works. - ssh (the support is finished in the glibc cvs and openssh package), this needs the possibility to restart cdebconf. ??? woody had ssh, and things haven't changed much for that. Maybe I'm misunderstanding what's needed here. debian-installer is a completely new installer system; it uses udebs (micro debs), small .deb packages which only contain the bare minimum (and e.g no documentation). Up until recently, we didn't have a udeb for SSH at all, but this is in the archive now. - language-/countrychooser at the begining is annoying - 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. Maybe this is the bug that the install hangs on serial console installs when you choose a language other than english? Do you have any idea how to fix it. - as discussed, default items should be prefixed with an asterisk or similar. Ditto. I personally use colour on serial installs so I don't see this. - 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). waldi? -- Martin Michlmayr [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RE: [waldi@debian.org: Re: [tsec-gf] Re: will s390 have a working installer for sarge?]
- 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. Maybe this is the bug that the install hangs on serial console installs when you choose a language other than english? Do you have any idea how to fix it. Scanning through the boot log you sent, my first guess would be that some of the visual escape sequence crap is causing a flow control problem that is hanging the device. Not everything is a ANSI terminal, still, and an installer that assumes ANY terminal processing will lose on this big-time. How does the display process get the terminal type? Hmm. At this point things are probably still pretty braindead in terms of termcap/terminfo, but that may be a general fix for the problem (a stub /etc/termcap and/or /etc/terminfo with ANSI and TTY only, and examine the apps for direct escape sequence generation code, to be eliminated on sight...) - as discussed, default items should be prefixed with an asterisk or similar. Ditto. I personally use colour on serial installs so I don't see this. Eeeuw. Ick. Installers shouldn't assume ANYTHING but plain-text until they have enough brains to ask if the device can handle it. Question: how much screen-handling intelligence does this thing really need? IF it can get by with a clear-screen capability (and write lines to simulate cursor positioning), you may want to generate the boot image with the 3270 console driver active instead of the 3215 console. That would give you a limited terminal definition that is capable of a clear-screen sequence and some limited highlighting (stick to 3278 hi-lite/normal text, and it'll work on any 3270). A test would be to see if the installer works properly on something really ancient and brain-damaged like a ADM-1 terminal. If so, it could work on the 3270 console driver. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
