Alain Fauconnet wrote: >>>/etc/rc.sysinit and installing a foreign mkinitrd RPM (unless you >>>compile all the drivers you need to boot static). >>rpm? > Yes, you know, that file archive format used to package software by > several Linux distributions ;-)
har-de-har-har > Not sure I understand your question here, but as I mentioned in a question in long-form: why the hell would you need to install a foreign mkinitrd rpm? > previous posting, I installed a mkinitrd RPM from Fedora Core 3 > instead of the TSL 2.2 one to get support for .ko kernel modules. but you guessed my question right ;) > That was part of the "hacking". OK, my sentence was poor English, it's > TSL 2.2 that has been hacked, not the kernel (although I had to > patch it a bit too, to avoid the '/proc' permission error due to syslog > running non-root on TSL 2.2). well, if you are going to replace mkinitrd, why in heavens name would you pick one from *a different distro* when TSL 3 has one that works fine with 2.6 kernels? and why, if you're so concerned with a stable distro, would you upgrade the kernel to 2.6 when that isn't supported in the first place? and like I mentioned, I think initrds are a waste for custom-built kernels. simply compile the drivers needed to boot in, and remove initrd from the grub.conf entry for it. >>I believe the wiki recommends compiling the stuff you need in (that's >>what I wrote there way back when, in any case) >> >>no sense having the stuff you need as modules if your kernel is compiled >>specifically to your system.. > > While I would generally agree with this, there are many reasons > that might drive you otherwise: > - when you have more than one SCSI controller and the one that > connects the boot disk isn't detected first due to PCI IDs that you > may not be able to change (e.g. on-board controllers) then compile only that controller in, the rest as modules. when I say need, I do mean the stuff needed to get the box booted. > - when you have a set of slightly different servers in a farm and you > want to have a common, standardized .config to ease your work burden > etc. if they all have the same "primary controller" that isn't a problem. if they all have different primaries, but none of them have the primary controller of one of the others as a sexondary, no problem > - I'm quite familiar to TSL 2.2. TSL 3.0 introduces a lot of > new stuff (e.g. the 4-letter acronym boot thing - can't recall the > name now) that looks very hostile to me at this point. I just don't > have time to get acquainted to 3.0 now. what? grub? grub is great.. I've been using it since 2.2.. no more LILILILILILILILILILILILILILILILILILILILILILI ad naseum and TSL 3 still has the option of using lilo... -- Morten :wq _______________________________________________ tsl-discuss mailing list [email protected] http://lists.trustix.org/mailman/listinfo/tsl-discuss
