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" 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.
Your assumption is correct - the additional IPL records are stored inside the bootmap file, along with the location data. > 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. 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 the non-standard way that Linux prepares CMS formatted DASDs for IPL.. > 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. Once the RECOMP area is represented as separate partition inside Linux (which it most likely will be in the near future, according to the DASD device driver owner), you can still achieve your goal: create a Linux filesystem inside that partion, mount it and use that as the target directory for zipl. As a result, the bootmap file will be created inside the RECOMP area, with a little additional filesystem overhead, but separated from the actual CMS file nontheless. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
