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 that they are written to the "CMS metadata" somewhere or else > to a special file in the filesystem in the first partition.
zipl is writing all of the additional boot data to a file inside the (Linux) filesystem. The file is named "bootmap" and it contains a list of pointers to records on disk (C/H/S for ECKD, blocknumbers for FBA/SCSI) that make up the files (kernel, ramdisk, etc.) to be loaded during IPL. This is true for all disk layouts supported by zipl. For FBA and LDL formatted ECKD DASDs, the bootmap file also contains the so called "second stage loader", i.e. the assembler program that interprets the disk pointer list. For CDL formatted ECKD DASDs, the second stage loader is located at records 4 to end of track 0, i.e. outside of the partition containing the actual filesystem. While it would certainly be the most clean approach if all IPL tools available under VM shared the same type of data layout, I think in practice this would not be feasible. For once, setting up the RECOMP area is a new step which introduces new ways for an installation to fail. Also the size of Linux IPL data is not static, but depends on varying factors like the contents of the zipl.conf file, the number and size of kernel modules and programs included in a ramdisk as well as the actual kernel size. Resizing a RECOMP area after a filesystem has been established would be rather complicated and error-prone. > Having the above support in Linux for CMS minidisks with a RECOMP area, > plus the modification above to the CMS RESERVE command (which I can do > myself) meets all of my goals. Those goals are as follows: > > 1. The minidisk is completely usable under CMS, with no CMS file system > corruption. > 2. The minidisk is completely usable under Linux, with no Linux file > system corruption. I think these are the actual core requirements that are the basis for your change requests. Unfortunately I still haven't fully understood where the current solution of using zipl on an ECKD DASD prepared by CMS FORMAT + RESERVE (without recomp) would not meet these requirements. > This will allow me to leverage existing z/VM tools for CMS disk > administration, such as backup and recovery, incremental backups, etc. > at a logical backup level (CMS files) or a physical backup level (disk > images). I don't understand how incremental, file-level backup would be possible from CMS, even if the RECOMP area of /boot would be used to store zipl's boot data. Regards, Peter -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
