Good point.. I've always advised giving ranges in modprobe.conf and allowing for growth so you don't have to worry about initrd in most cases. Also - use the ranges as an indicator of what's there.. example:
100 -- /boot 101-110 -- swap 120-130 -- OS disks ( / ) - LVMs for the base OS 200-21F -- Application code LVMs, config, etc (often mounted /opt) 300-31F -- Data (database LVMs, whatever) Things often don't break down in such clean lines - but you get the idea. One advantage is that if you are dealing with LVMs -- and need to do some recovery -- you know by the ranges which disks you'll need to get to make sure you have all the disks for the Linux system LVMs you're trying to fix. I'm sure there are similar schemes buried in the archives, too ;-) Scott On Mon, Feb 23, 2009 at 7:11 AM, Hall, Ken (GTS) <ken_h...@ml.com> 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:linux-...@vm.marist.edu] On Behalf Of > Ivan Warren > Sent: Thursday, February 19, 2009 9:37 AM > To: LINUX-390@VM.MARIST.EDU > 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 lists...@vm.marist.edu 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 lists...@vm.marist.edu 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 lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
