*** Reply to note of Thu, 08 Jul 2004 15:01:24 -0500 (EST/CDT) *** by [EMAIL PROTECTED]
The latest issue of The Journal of Research and Dev. has an article on SCSI IPL (real and VM): http://www.research.ibm.com/journal/rd/483/banzhaf.pdf It would be nice if you could use SET LOADDEV on regular IPL disks. Richard Troth <[EMAIL PROTECTED]> writes: >We're running into an unnecessary ugliness in zSeries >with respect to booting and configuration. We need "the PARM parm". > >There's a concept of a "boot command-line". This is good. >Often, the boot command-line can be overridden at boot time. >This is VERY good. But support for override is slipping away from >zSeries Linux. > >On Thu, 2004-07-08 at 10:37, Arty Ecock wrote: >> > Something in >> > initrd wants that disk R/W. Adam suggested changing the parmline to >> > something like "DASD=150(ro), ..." but once that is done, you lose the >> > ability to update the basevol root disk (or a copy of it). > >On Thu, 8 Jul 2004, Adam Thornton wrote: >> Use multiple parmlines. There's the older Lucius Leland PARM LINE >> stuff, which I really like, which lets you do it very flexibly from CMS, >> and there's also actual official multiboot support in newer s390-tools. > >We really need proper support for parm handling. >For those who do not know, VM has long time supported a PARM parm >on the IPL command which effects a 64-byte parm string whether booting >from device or from named saved system (NSS). SAN support breaks it. >So when you're booting Linux on z/VM, you can append parameters, >as long as you're on traditional disk or booting from NSS. > > ipl mylinux parm root=/dev/other init=/sbin/blahblah > -or- > ipl 2345 clear parm root=/dev/another mem=1024m > -or- > ipl 1AE clear parm dasd=1AC-1AF root=/dev/dasdc1 > >You get the idea. >64 bytes is small, but quite sufficient for most overrides. > >LOADPARM is another thing, and is seen in the hardware, so you >z/OS folks are more familiar with that one. I don't like LOADPARM. >At only 8 bytes, it doesn't foster entry of arbitrary boot parm text. >The above examples do not fit into LOARPARM space. Any alternate >boot parameters must be pre-set and stamped into a collection. > >SAN is good. But the z/VM support for SAN makes "PARM" an >illegal option if the IPL device is SAN. Why is this? But while >SAN support breaks ye olde PARM parm, it supplies a new thing. >IBM calls it SCPDATA, but it looks like an arbitrar buffer >which gets passed to the boot loader. I can't find mention of this >outside of IBM (and SHARE) documentation, so I don't know if it is >architected outside of zSeries. But it's there. > >IPL from SAN should pack a PARM string into SCPDATA space, >OR SOMETHING LIKE THAT. There's a lot of value in managed systems >having boot-time overrides containing arbitrary details. > >SUMMARY > >When booting Linux, there is the concept of a boot parameter line. >We all know and love this as the "parmfile" used by ZIPL, LILO, GRUB. >In many situations, some stage of the bootstrap will allow overrides >to what is stamped on disk. THIS IS A GOOD THING. One such >override is Leland's "vmparm" patch for 2.4.19. > >-- R; > >---------------------------------------------------------------------- >For LINUX-390 subscribe / signoff / archive access instructions, >send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit >http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
