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 not as proficient in Linux as I'd like to be. I think in part we
are struggling to understand each other's differing terminology.
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" or what I am calling "additional IPL records" are placed inside
the /boot/bootmap file under certain conditions. You state that this is
the case for FBA disks and for ldl CKD disks. You don't state if this is
the case for CMS disks. I am assuming that it is true for CMS disks as
well. Please let me know if my assumption is correct or not.
For CKD cdl disks you state that the "second stage loader" is
stored in records 4 to the end of track 0, outside the filesystem, and
that is the correct place for what I am calling "additional IPL records",
architecturally speaking, for disks in this format. A disk in this
format is what an old mainframer would call an "OS disk". And that's
the right place for IPL records for this kind of disk format.
For a CMS minidisk, the "right" place for "additional IPL records", or
what you call the "second stage loader", is the RECOMP area. If a
CMS minidisk does not have a RECOMP area, it's not supposed to be
bootable (unless the boot program is extremely small and will fit in the
first two IPL records). That is why SALIPL fails if it is run against
a CMS minidisk without a RECOMP area.
You have come up with a non-standard solution, which is to include the
"additional IPL records" or "second stage loader" as part of the
/boot/bootmap file. While this is not the "right" place for them,
architecturally speaking, on a CMS minidisk, I believe it will meet my
requirements, as long as the CMS minidisk is RESERVEd. Keep in mind
that when I first opened this bug report I was under the mistaken
impression that CMS minidisks were not bootable at all under Linux.
With my VM/CMS background, a CMS minidisk without a RECOMP area means
it's not bootable. And if it does have a RECOMP area but the Linux
filesystem does not respect it, but skates over the top of it, that
also means it's not bootable. But my assumption turned out not to be
correct.
When I learned that you had found a way to make CMS minidisks
bootable without a RECOMP area, the first thing that went through my
mind was, "Where is he hiding those additional IPL records?"
I was afraid that you were hiding them in the CMS metadata somewhere,
such as the allocation map, which would destroy the integrity of the
CMS file system. But as long as the minidisk is RESERVEd, the partition,
and hence the Linux filesystem, is confined to the CMS reserved file.
If it is true that, for RESERVEd CMS minidisks, the second stage loader
is included in the /boot/bootmap file, then my basic requirements have
been met. They haven't been met in the way I would have expected or
in the way I would have preferred. But they have been met.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
