Ken --
In the thread, we may have not specifically mentioned that list of devices. Nice catch. But ... be aware that the list-o-devices may not always be needed. In particular, once the root is mounted, especially if UDEV is then also available, additional disks can be marked online via magical stuff under /etc/sysconfig. (I speak from SLES experience having been away from RH for a while, though I know RH generally does also utilize /etc/sysconfig.) I find it immensely useful to have the devices listed in an after-the-initrd kind of file. The value of NOT having to re-stamp INITRD for some 500 penguins is ... well ... it's huge. Also, just FYI, somewhere in the history of 2.6, the dasda-dasdp slots became less consistent. What I mean is that even if I code 100-10F, the latter disks are NOT slotted where I expect them if they do not exist when the driver is loaded. Bad bad ... but water under the bridge now. [sigh] UDEV helps. (But this is a whole nutha subject and thread.) -- Rick; <>< Q: Isn't filtering stupidity elitist? A: Yes. Yes, it is. That's sort of the whole point. -- Ortiz and Starr On Mon, Feb 23, 2009 at 9:11 AM, Hall, Ken (GTS) <[email protected]> wrote: > If this was covered in previous notes, sorry, but I didn't see it, and > I've been out for a few days so I didn't get into this at the beginning. > > In Red Hat (and probably Suse too), there's a chicken-egg problem. The > DASD driver gets its list of valid devices from a parm that's passed to > the driver in /etc/modprobe.conf. But at the time the module is loaded, > the running root filesystem is the initrd. The regular root filesystem > can't be mounted till AFTER the dasd driver is loaded. You only need to > make the initrd if you change the list of devices. > > We coded a list of placeholder device numbers in our base configuration > going out to dasdzz, so we don't have to fiddle going forward. Note > that this list is ONLY devices that are visible automatically at boot > time, and reserves the device node assignments for them. Additional > devices outside the range can be added later via attach and chccwdev, > and device nodes will be built starting after the list built from the > parameter. (i.e., if modprobe.conf contains 100-10F, that reserves > dasda-dasdp, even if some of them don't exist, and the first dynamically > added disk will be dasdq.) > > As far as bare metal goes, we did try some tests in a bare LPAR, and it > works fine with thousands of devices visible, but it takes a LONG time > to scan them all. Also, at the time we tested, there was some quirk > with coding the actual devices in modprobe.conf, and filtering that way > caused the system to hang coming up. It might have been an error in > configuration somewhere, we were on a schedule, so we simply removed the > filter, and brought it up seeing all devices. > > -----Original Message----- > From: Linux on 390 Port [mailto:[email protected]] On Behalf Of > Ivan Warren > Sent: Thursday, February 19, 2009 9:37 AM > To: [email protected] > Subject: Re: [LINUX-390] Why does one need to mkinitrd/zipl ? (WAS : > Broken logical volume group) > > Richard Troth wrote: >> Ivan ... hear this: >> With SLES10, unless you are changing something about the root FS, you >> do not need to re-stamp your INITRD. It is exactly as you say it >> should be. >> >> >> -- R; <>< >> >> > That's good enough for me ;) > > At least the idea that I would have gave me fodder for a tantrum :P > > --Ivan > > ---------------------------------------------------------------------- > 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 > > -------------------------------------------------------------------------- > This message w/attachments (message) may be privileged, confidential or > proprietary, and if you are not an intended recipient, please notify the > sender, do not use or share it and delete it. Unless specifically indicated, > this message is not an offer to sell or a solicitation of any investment > products or other financial product or service, an official confirmation of > any transaction, or an official statement of Merrill Lynch. Subject to > applicable law, Merrill Lynch may monitor, review and retain e-communications > (EC) traveling through its networks/systems. The laws of the country of each > sender/recipient may impact the handling of EC, and EC may be archived, > supervised and produced in countries other than the country in which you are > located. This message cannot be guaranteed to be secure or error-free. > References to "Merrill Lynch" are references to any company in the Merrill > Lynch & Co., Inc. group of companies, which are wholly-owned by Bank of > America Corporation. Securities and Insurance Products: * Are Not FDIC > Insured * Are Not Bank Guaranteed * May Lose Value * Are Not a Bank Deposit * > Are Not a Condition to Any Banking Service or Activity * Are Not Insured by > Any Federal Government Agency. Attachments that are part of this > E-communication may have additional important disclosures and disclaimers, > which you should read. This message is subject to terms available at the > following link: http://www.ml.com/e-communications_terms/. By messaging with > Merrill Lynch you consent to the foregoing. > -------------------------------------------------------------------------- > > > ---------------------------------------------------------------------- > 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
