[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?
Title: [Linux/390 under z/VM 4.2.0] more details on
problem with
Dear Stephen,
12/5/11
At 22:56 -0400 11/05/11, Stephen Powell wrote:
Wed, 11 May 2011 10:20:12 -0400 (EDT),
Christian Boitet wrote:
> At 7:42 -0400 11/05/11, Stephen Powell wrote:
>> 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
I see.
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.
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.
You are quite right.
> 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:
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.
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
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.
> Considering the source: yes we took
the files
> from "generic" ...
Good.
> ... and made sure to get a lenny version (5.0.8).
Good.
> SOMETHING is a bit strange and might help:
> immediately after the "IPL 00C" command is
> issued, what is read from the reader seems to
> cause another "CHANGE RDR ALL KEEP NOHOLD"
> as we get the message:
> 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.
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.
> 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?
We know... some infinite loop, at least on our machine! ;-)
> 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
> documentation:
>
> 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").
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.
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.
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".
-------------------------------------------------------------------------------
> 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
> whole list
(debian-s390@lists.debian.org) or to
> 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.
OK
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.
--
.''`. Stephen
Powell
: :' :
`. `'`
With best regards,
Xan
--
-------------------------------------------------------------------------
Christian Boitet
Reply to: