On Tue, Nov 25, 2008 at 12:07 PM, Rick Troth <[EMAIL PROTECTED]> wrote:
>> +) It automagically builds a initrd for every installed kernel in >> /boot, unless given just a specific kernel by command line options. Not >> having mandatory options for mkinitrd is sweet. > > > The latter is "okay". The former is not. (Listening Novell?) I don't think it is "good" to rebuild the initrd for other kernels. It is *not* helpful to modify my back-out configuration when I am planning to upgrade the kernel. It just does not fit the change control that some installations want to adhere. I believe the 'uname -r' is fortunately back to include the dash-level etc so /lib/modules is unique per kernel. Earlier releases would fold all into a single directory and thus build an initrd with kernel modules that were not compatible with the kernel. > Abuse of INITRD is possibly the single worst feature of the current > releases. (RedHat abuses it too, and they were probably the first.) > In the case of SuSE's mkinitrd tool, yes, it automagically pulls the > current list of activated DASD subchannels, but that's NOT an advantage > when you're running hundreds of identical penquins. I already dislike the entire initrd because it creates additional complexity that we don't need with Linux on z/VM. But even worse is the mechanism to attempt building something that looks like my current configuration (which may in some situations not be what I want, and maybe the reason I wanted a new kernel to become active). Rob ---------------------------------------------------------------------- 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
