> I can think of the following alternative places and I'd like to hear
> your opinion on whether you consider them appropriate and if you would
> have looked in that place for general information about the IPL process:
> - man page for zipl or zipl.conf
> - "Device Drivers, Features and Commands"
Stephen Powell <[EMAIL PROTECTED]> wrote on 16.07.2008 21:46:51:
> > A "How zLinux boots" paper which describes not only how Linux does
> > things, but how its fits into the VM/CMS/zOS world and compares and
> > contrasts those booth paths with Linux's, and with a nice glossary
> > that translates
> A "How zLinux boots" paper which describes not only how Linux does
> things, but how its fits into the VM/CMS/zOS world and compares and
> contrasts those booth paths with Linux's, and with a nice glossary
> that translates between the two, would no doubt be highly helpful.
>
> Stephen, maybe th
On Wed, Jul 16, 2008 at 11:16:47AM +0200, Peter 1 Oberparleiter wrote:
> Ok, now I understand the core of your point. I must admit that with my
> Linux background I haven't been aware of this association at all. I'm
> wondering if some kind of documentation would help clear up any confusion
> about
Stephen Powell <[EMAIL PROTECTED]> wrote on 15.07.2008 22:51:17:
> I know about the /boot/bootmap file, but I assumed that it contained
data
> only - location information for the kernel and initial RAM disk. From
> what you're telling me, it sounds like what you call the "second stage
> loader" o
One of the problems with Linux for System z is that there are people who
know Linux well and there are people who know mainframes well, but there
are very few who know both well. I don't claim to be one of the few who
know both well. I know mainframes and z/VM pretty well, I think, but I'm
still
Stephen Powell <[EMAIL PROTECTED]> wrote on 14.07.2008 20:58:36:
> The problem is that the IPL records (other than the first two) are being
> written, architecturally speaking, to the wrong place. I don't know
where
> zipl is writing its IPL records, other than the first two, but I am
> assuming
Peter, I tried your scenario and it works as you say. I can use a CMS
minidisk, RESERVEd or non-RESERVEd, as a /boot partition. I can even use
the dasd_diag driver against it, provided I don't run zipl. (If I need
to run zipl, I can switch to the dasd_eckd driver, then run zipl, then
switch back
Stephen,
as the current maintainer of zipl I'm trying to understand the reasoning
behind your enhancement requests. The way I understand it you want to be
able to use zipl on a CMS formatted disk to enable it for IPL. zipl does
support CMS formatted disks (although not with the DIAG access meth
It looks like our updates are crossing in the mail.
Sorry about that. I'll try to answer your additional questions.
The following is an oversimplification, but it gets the point across.
A CMS minidisk on a CKD device has the following logical format:
- /dev/dasda
FYI,
I just got connected to the right people in the zSeries Linux group in
Germany, and they are suggesting to me that the CMS label is really
more of a partition thing, and the right fix may be in the kernel, to
restrict the partition seen by mke2fs to exclude the RECOMP area.
Their only concern
One thing I forgot to mention. CMS minidisks in EDF format have four
possible block sizes: 512, 1024, 2048, and 4096.
(Oh dear, I've introduced another undefined acronym. EDF stands for
Enhanced Disk Format. It is the only format of CMS minidisk that is
currently supported. There is an older fo
I've floated your request to some colleagues of mine at the IBM Linux
Technology Center, and one of them sent back this reply.
>Have spent some time mulling this over with some VM sysprog
>buddies of mine we've come to the conclusion that it is not clear
>what this request is trying to ac
On Wed, Jul 09, 2008 at 09:20:52AM -0700, Stephen Powell wrote:
> The structure I sent to you maps the CMS label record. For FBA
> devices, the label record is the second 512-byte block of the
> minidisk. For CKD devices, the label record is cylinder 0, track 0,
> record 3, which would be the thi
DASD is an acronym for Direct Access Storage Device. It is a storage
device in which the blocks can be accessed randomly, in any order,
without reading the blocks in between. In the history of mainframes,
a DASD device was not necessarily a disk device. At one time, there
were drum devices too,
I've looked at the patch, and there are too many acronyms!
Where is this CMSFSADT label supposed to be found? According to some
comments, for "FBA DASD's" it is located at offset 512 bytes. I know
that DASD is a mainframe-encrypted word for "disk", but what is "FBA"?
And then there are these st
> I'm sorry, but I have absolutely no idea what this
> means.
>
> From the rationale it sounds like s390 stashes some kind of
> label or
> bootable area at the end of a minidisk, which is visible to
> the Linux
> program accessing the device file, and that mke2fs is
> supposed to
> somehow recog
On Mon, Jun 16, 2008 at 08:44:23AM -0700, Stephen Powell wrote:
> Package: e2fsprogs
> Version: 1.39+1.40-WIP-2006.11.14+dfsg-2etch1
> Severity: wishlist
>
> This is an enhancement request that applies to the s390 and s390x
> architectures only. Currently, when mke2fs is run against the
> single
Package: e2fsprogs
Version: 1.39+1.40-WIP-2006.11.14+dfsg-2etch1
Severity: wishlist
This is an enhancement request that applies to the s390 and s390x architectures
only. Currently, when mke2fs is run against the single implicit partition of a
CMS minidisk, and the minidisk has been formatted by
19 matches
Mail list logo
