[Linux/390 under z/VM 4.2.0] CP works forever (Lenny): new attempt

Discussion:

(too old to reply)

Stephen Powell

2011-05-12 03:00:02 UTC

First, please do not "top post" on this list. (See
http://en.wikipedia.org/wiki/Top-posting#Top-posting for
more details.) Please use the usenet, or "bottom posting" style.

I don't see how Jean-Claude could "top-post" as he wrote a new message.
I take it as an advice for later messages such as this one.

I don't think you understand. Look at Jean-Claude's post:

http://lists.debian.org/debian-s390/2011/05/msg00005.html

The new material is at the top. The quoted material is at the
bottom. That's top-posting.

This post is an illustration
of the posting technique that we prefer on this list (and all
the Debian lists). Questions and answers are interleaved,
and the question appears before the answer. Not all material
from the earlier post need be quoted if it is not needed to
establish a context to the replies in the new post. That's called,
"trimming your posts".

To answer you: yes we know well about binary and F 80 etc.
I myself edited under Xedit the ASCII version of
PARMFILE (already put in F 80).
I replaced the last character (X'20', a space), in position
80, by X'0A'. We both know CMS and XEDIT quite well.
Jean-Claude wrote a tree editor all in REXX for
use under XEDIT for his PhD, and I wrote many
XEDIT macros... I can't see which mistake we
could have done. But we sure did one!

I'm not questioning anyone's competence in general z/VM matters:
I'm only giving you a check list of common causes of problems.

To be sure, we retransferred the PARMFILE (in
binary, by ftp) on a Mac under MacOSX and
verified that the file was indeed in ASCII and
had the terminator in position 80 (only ONE
character, not 2 like under Windows).

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:

72 6f 20 6c 6f 63 61 6c 65 3d 43 0a 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

That's "ro locale=C" (without the quotes), followed by a
linefeed character, followed by 68 nulls. Before you try
monkeying with the file at all, just try the raw binary download,
with no modifications. I know you want to add extra stuff
when you do your actual install, but this is a diagnostic step.

Considering the source: yes we took the files
from "generic" ...

Good.

... and made sure to get a lenny version (5.0.8).

Good.

immediately after the "IPL 00C" command is
issued, what is read from the reader seems to
cause another "CHANGE RDR ALL KEEP NOHOLD"
0000003 FILES CHANGED

That is a normal message. You didn't change the DEBIAN EXEC
file, did you, to eliminate the "PURGE RDR ALL" command?
Otherwise, you will keep accumulating reader files but you
will always IPL the oldest ones, which of course never change.

Another question is, if the PARMFILE were wrong,
could it put the IPL process in a loop?

If it doesn't see the terminator it expects, it may read part
of the initial RAM disk as parmfile information. Thus, the
initial RAM disk will be corrupted and unusable. Who knows
what will happen then?

In order to get the KERNEL and INITRD files
(already transferred in binary) in F80, we used
the CMS PIPE command as shown in the IBM
PIPE < fn1 ft1 fm1 | FBLOCKS 80 | > fn2 ft2 fm2 F 80

Almost. Try

PIPE < fn1 ft1 fm1 | FBLOCK 80 00 | > fn2 ft2 fm2 F 80

Apparently you don't have TCP/IP for z/VM installed on this
system? I'm used to using the CMS FTP client to transfer the
files. It makes things much easier. In newer versions of z/VM,
TCP/IP for z/VM comes bundled with z/VM at no extra charge. But
at the z/VM 4.2.0 level, perhaps TCP/IP is still a separate product?
I don't remember.

Please explain the EXACT steps you go through to transfer the file
to a CMS minidisk, in detail, plus all post-processing you do on
the file once it arrives on the CMS disk but before you run the
DEBIAN EXEC file.

If there is a problem there, maybe you could help
us detect it by comparing the lengths?

PARMFILE DEBIAN is 1 record (fixed length, 80 bytes).
INITRD DEBIAN is 34861 records (fixed length, 80 bytes)
KERNEL DEBIAN is 42020 records (fixed length, 80 bytes)

Should we post an e-mail of this sort to the
you alone ?

Send it to the list only, please. I am subscribed to the list
and I will get a copy automatically. Keep it on the list in case
someone else has something to add, and so that, once the problem
is solved, the solution will benefit someone else.

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.
--
.''`. Stephen Powell
: :' :
`. `'`
`-

--
To UNSUBSCRIBE, email to debian-s390-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@md01.wow.synacor.com

Christian Boitet

2011-05-13 00:30:01 UTC

Permalink

Dear Stephen, 12/5/11

Post by Stephen Powell

First, please do not "top post" on this list. (See
http://en.wikipedia.org/wiki/Top-posting#Top-posting for
more details.) Please use the usenet, or "bottom posting" style.

I don't see how Jean-Claude could "top-post" as he wrote a new message.
I take it as an advice for later messages such as this one.

http://lists.debian.org/debian-s390/2011/05/msg00005.html

I see.

Post by Stephen Powell
The new material is at the top. The quoted material is at the
bottom. That's top-posting.

OK, I interleave -- that is also my favourite method.

Post by Stephen Powell
This post is an illustration
of the posting technique that we prefer on this list (and all
the Debian lists). Questions and answers are interleaved,
and the question appears before the answer. Not all material
from the earlier post need be quoted if it is not needed to
establish a context to the replies in the new post. That's called,
"trimming your posts".

I'm only giving you a check list of common causes of problems.

You are quite right.

Post by Stephen Powell

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

Yes we did. But we HAD to modify the file as it was in V format.

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

I want to say an important thing: we have tried
another distribution, Centos 4.6, and succeeded
(today). It seems their PARMFILE can remain in
EBCDIC, which can remove a source of manipulation
errors.

Post by Stephen Powell
72 6f 20 6c 6f 63 61 6c 65 3d 43 0a 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

From memory, PARMFILE was rather (after XLATING to ASCII and xediting in hex):

72 6f 20 6c 6f 63 61 6c 65 3d 43 20 20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 0A

Post by Stephen Powell
That's "ro locale=C" (without the quotes), followed by a
linefeed character, followed by 68 nulls. Before you try
monkeying with the file at all, just try the raw binary download,
with no modifications. I know you want to add extra stuff
when you do your actual install, but this is a diagnostic step.

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

I understand that the ipl could play havoc with these unexpected nulls.

The documentation insisted that we should
transfer PARMFILE.DEBIAN in ascii, as for
DEBIAN.EXEC, hence we did not consider
transferring it in binary.
We will retry to make sure.

Post by Stephen Powell

Considering the source: yes we took the files
from "generic" ...

Good.

... and made sure to get a lenny version (5.0.8).

Good.

immediately after the "IPL 00C" command is
issued, what is read from the reader seems to
cause another "CHANGE RDR ALL KEEP NOHOLD"
0000003 FILES CHANGED

Of course not. We left this command in DEBIAN EXEC.
At each trial, we checked manually the reader and
it never contained more than 3 files after we
stopped the execution.

Our impression is that one of the first steps of
the ipl is to change all RDR files to KEEP
NOHOLD, in fact repeating the one before last
command of DEBIAN EXEC.

Post by Stephen Powell

Another question is, if the PARMFILE were wrong,
could it put the IPL process in a loop?

We know... some infinite loop, at least on our machine! ;-)

Post by Stephen Powell

In order to get the KERNEL and INITRD files
(already transferred in binary) in F80, we used
the CMS PIPE command as shown in the IBM
PIPE < fn1 ft1 fm1 | FBLOCKS 80 | > fn2 ft2 fm2 F 80

Almost. Try
PIPE < fn1 ft1 fm1 | FBLOCK 80 00 | > fn2 ft2 fm2 F 80

Yes (we did that, I forgot to copy "00").

Post by Stephen Powell
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.

At some point, we downloaded the files using
"binary f 80" on a VM where ftp works normally
(our LINUX3), and did a COPYFILE (attaching disk
191 A of LINUX3 as 192 B to LINUX7) to the
machine on which we wanted to install a recent
Debian (LINUX7).
But that was cumbersome, so that we preferred to
do a ftp PUT from a Mac to LINUX7 (which appears
as tupai-x9.imag.fr on the network), and then to
reblock -- and that works well. The only hitch is
that we must reboot (i cms) to see the files
appear in the reader, but that takes 10 seconds.

Post by Stephen Powell
I'm used to using the CMS FTP client to transfer the
files. It makes things much easier. In newer versions of z/VM,
TCP/IP for z/VM comes bundled with z/VM at no extra charge. But
at the z/VM 4.2.0 level, perhaps TCP/IP is still a separate product?
I don't remember.

No no. We always had it. We bought z/VM in "one
shot" or "one time charge" -- OTC -- back in
2001, and TCP/IP was there, as SMTP and an array
of services implemented on dedicated virtual
machines.

We plan to get a second-hand z800 in June or
September, and then we will have a S390x and will
upgrade to a newer z/VM... and probably get rid
of those problems.

Post by Stephen Powell
Please explain the EXACT steps you go through to transfer the file
to a CMS minidisk, in detail, plus all post-processing you do on
the file once it arrives on the CMS disk but before you run the
DEBIAN EXEC file.

Here it is.
-------------------------------------------------------------------------------
- Transfer in binary kernel.debian to KERNEL DEBIANBV
- Transfer in binary initrd.debian to INITRD DEBIANBV
- Reblock them:
1) PIPE < KERNEL DEBIANBV A | FBLOCK 80 00 | > KERNEL DEBIAN F 80
2) PIPE < INITRD DEBIANBV A | FBLOCK 80 00 | > INITRD DEBIAN F 80

- Transfer in ascii parmfile.debian to PARMFILE DEBIANEV A (V 80), then
1) xedit PARMFILE DEBIANEV A: recfm F, file PARMFILE DEBIANEF A
2) PIPE < PARMFILE DEBIANEF A | XLATE E2A | > PARMFILE DEBIAN A
3) xedit PARMFILE DEBIAN A: v h1 80, then replace '20' by '0A' in last
position (80), then file.

- Check the PARMFILE under MacOSX (TextWrangler) after ftp-ing in binary.
It seemed OK, but the linefeed in position 80
may be preceded by nulls (X'00') and not by
spaces (X'20'), we have to check that.

- Transfer in ascii debian.exec to DEBIAN EXEC,
then xedit it and add 1 line with "TRACE A".
-------------------------------------------------------------------------------

Post by Stephen Powell

If there is a problem there, maybe you could help
us detect it by comparing the lengths?

PARMFILE DEBIAN is 1 record (fixed length, 80 bytes).
INITRD DEBIAN is 34861 records (fixed length, 80 bytes)
KERNEL DEBIAN is 42020 records (fixed length, 80 bytes)

Should we post an e-mail of this sort to the
you alone ?

Post by Stephen Powell
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.

Post by Stephen Powell
--
.''`. Stephen Powell
`. `'`

With best regards,

Xan

--
-------------------------------------------------------------------------
Christian Boitet

Stephen Powell

2011-05-14 00:50:02 UTC

Permalink

Post by Christian Boitet

Post by Stephen Powell
...
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
...

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.

Post by Christian Boitet
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.

Post by Christian Boitet
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.

Post by Christian Boitet

Post by Stephen Powell
Apparently you don't have TCP/IP for z/VM installed on this
system?

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.

Post by Christian Boitet

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
: :' :
`. `'`
`-

--
To UNSUBSCRIBE, email to debian-s390-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@md01.wow.synacor.com