A comment about "INITRD abuse" ...
On Mon, 24 Nov 2008, Patrick Spinler wrote: > A couple of other notes about s390 integration, since I didn't want to > put everything in my first message: > > *) mkinitrd > > mkinitrd in SuSE is notably more convenient, in two ways. One s390 > specific way, and one architecture neutral way: > > +) It automagically pulls the current list of activated DASD channel > numbers, and includes those in the ramdisk image it builds for > activation at next IPL. No forgetting to edit /etc/modules.conf when > extending a machine with more DASD. > > +) 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?) 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. When running virtual, you WILL WANT slots of unused disk (and various other devices) and you do NOT want those slots to move around or disappear. You also DO NOT want the initial ramdisk to change from guest to guest, which can happen (notably for SAN addressing in SLES9, what else?). The initial ramdisk started out as a way to load exactly those kernel modules which are needed, avoiding pre-compiling statically. But it has turned into a scatter point for configuration. It should NOT be used for configuration, but only for module loading. (Granted, when you have as many I/O addresses as we do, it's hard to not have "configuration" in there too.) This initrd pain would be lessened if you could turn the cussed thing off, but that's nigh unto impossible. (I continue to try.) But hey ... I never asked this forum. Can someone point me at that switch? Other comments ... > On the flip side, a real strength of AIX's SMIT and SMITTY > administration tools compared to YaST is that they show you exactly what > they are changing and what commands they're running. > > Would it really be so hard to throw a "--show-action" flag on the > system-config toolchain, and a simple GUI front end on top of them? Sweet! Now that WOULD be a teriffic enhancement. > One area where both Redhat and SLES need some work is in terms of > putting out discrete, reversible patch sets. Yes. But also, the distributors need to wake up to the concept of read-only media, that we (customers) might have our own maint methods and have the committment to push according to schedule and the like. In that case, the reversibility burden would not be on the distributors but on us. (Put the old disk back into place.) Still, there will always be pieces which fall outside the maint space (eg: config files) which need to be backward and forward compatible. But if you want to compare with AIX it is (was) no better about this. Sun does seem to have a clue. (last time I looked, more years ago than I want to admit) -- Rick; <>< ---------------------------------------------------------------------- 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
