[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [Linux/390 under z/VM 4.2.0] more details on problem with lenny, but we could install centos 4.6, maybe a bug in debian somewhere?



On Thu, 12 May 2011 19:22:53 -0400 (EDT), Christian Boitet wrote:
> Stephen Powell wrote:
>> ...
>> No, that's not right.  Did you try an unmodified file,
>> as I suggested?  Here is the unmodified PARMFILE DEBIAN
>> file, in hexadecimal ASCII.  For readability, I have added a blank
>> between each group of two hex digits:
>> ...
> 
> Yes we did. But we HAD to modify the file as it was in V format.

All you would have to do would be

   PIPE < PARMFILE DEBIAN A|FBLOCK 80 00|> PARMFILE DEBIAN2 A F
   ERASE PARMFILE DEBIAN A
   RENAME PARMFILE DEBIAN2 A = DEBIAN =

That does not require editing.  But if you use the CMS FTP client
and say "binary f 80", it should download as format F.  The only
file that needs to be downloaded in ascii mode is DEBIAN EXEC.
Then, to fix up DEBIAN EXEC you do something like:

   PIPE < DEBIAN EXEC A|JOIN *|SPLIT AT X25|> DEBIAN EXEC2 A
   ERASE DEBIAN EXEC A
   RENAME DEBIAN EXEC2 A = EXEC =

Note that the SPLIT stage of CMS Pipelines looks for X25 as the
terminator (the EBCDIC linefeed character) instead of X0A as the
terminator (the ASCII linefeed character), since downloading the
file in ascii mode using the CMS FTP client will result in an ASCII-
to-EBCDIC translation.

> 
> Was it wrong to put the terminator at position 80, after padding with
> spaces (X'20')?

Possibly.  There are two "terminators" here.  The linefeed and the null.
It may need both.  The linefeed ends a logical line, and a null terminates
a string of characters in C.
> 
> We'll check it again (no access from here), 
> because, if "par malheur" we produced something 
> like
> 
> 72 6f 20 6c 6f 63 61 6c 65 3d 43 00 00 00 00 00 00 00 00 00
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0A

No, there should not be embedded nulls in a line.

>> 
>> Apparently you don't have TCP/IP for z/VM installed on this
>> system?
> 
> TCP/IP works on our z/VM, under CMS, but ftp does 
> not work well on all virtual machines, for some 
> unidentified reasoon. For example, on our LINUX7 
> machine, ftp will not go down the hierarchy of 
> the mirror, while it does on LINUX3.

Something is fishy here.  Why would the CMS TCP/IP client work on
one virtual machine and not on another?  Perhaps you don't have
a disk accessed that you need, such as the TCP/IP client code disk
(TCPMAINT 592)?  My advice is to figure out why the CMS FTP client
doesn't work, fix it, and use the CMS FTP client to download the
files, with "binary f 80" in effect (except for debian.exec, which
requires "ascii").  Then try an install without touching
PARMFILE DEBIAN.

Your file transfer steps are too cumbersome, and your editing is
flawed.  Keep it simple.  Get the CMS FTP client working.
>>
>> At this point, I suspect the problem has something to do with how
>> the files get from the Debian mirror to the CMS disk.  But you also
>> might want to check to see if there are any APARS against the z/VM
>> 4.2.0 CP component that are Linux-related.  I'm not familiar with
>> the maintenance for 4.2.0 as I have not used it in nearly six years.
> 
> I don't think so as we succeeded in installing a 
> CentOS 4.6 on our LINUX7 today.
> As one of us is a fan of Debian, plus Centos 4.6 
> dates back to 2008 and seems to be the latest 
> available for s390 *and* s390x, we would like to 
> contribute to Debian in solving this small 
> mystery, and go back to it for several or all our 
> Linux/390 virtual machines.

Well, it's possible there is a bug in Lenny.  But if there is, it's
not going to be fixed.  It's two releases out of date.  And many
others have installed it successfully.

I just thought of something else to check.
Make sure that the CP directory says

   MACHINE XA

not

   MACHINE ESA

On some older releases of z/VM, "MACHINE ESA" meant a virtual
machine that was capable of being switched to z/Architecture
mode, while "MACHINE XA" meant a virtual machine that could not
be switched.  I may be grasping at straws here, but it's something
to check.

-- 
  .''`.     Stephen Powell    
 : :'  :
 `. `'`
   `-


Reply to: