Slashdot Mirror

← Back to Stories (view on slashdot.org)

Building ATA RAID and SMP Support into Slackware 9

Posted by timothy on from the tomorrow's-computer-today dept.

TheMadPenguin writes "This HOWTO will describe the steps necessary to build support into Slackware Linux 9.0 for Symmetric multiprocessing (SMP) and a Promise Ultra ATA RAID redundant drive array. By default, there is no support for these configurations unless specified through a kernel recompilation after the initial install."

3 of 171 comments (clear)

  1. Why Slackware by MBCook · · Score: 4, Informative
    Why is this Slackware specific. These instructions would work on most distros (with one or two small changes of where the boot kernel is kept). A better title would have been:

    Building ATA RAID and SMP Support into Your Kernel

    Those complaints asside, the guy knows what he's doing, so if you want to run RAID or SMP on your kernel, give it a read.

    --
    Comment forecast: Bits of genius surrounded by a sea of mediocrity.
  2. Use Slackware's kernel source package. by volkerdi · · Score: 5, Informative

    It's better to use Slackware's kernel-source-2.4.20-noarch-5.tgz package, since it already contains patches for some ext3 bugs as well as the recent ptrace exploit.

    If you do use the original 2.4.20 tarball in the source/k directory, you will need to apply the linux-2.4.20.ptrace.diff.gz that you'll find in the same directory, and if you use ext3, you'll also want to apply the patches from the ext3-patches directory.

  3. mistake, imho by doodleboy · · Score: 5, Informative
    article says: #> mv /lib/modules/2.4.20 /lib/modules/orig
    Bad bad bad. Now the original config is unbootable, a bad thing when you're monkeying around with the kernel. What you do is edit the kernel Makefile and add something to the extraversion parameter, i.e.:

    EXTRAVERSION = -smp_raid

    Then you'll have two entries under /lib/modules, 2.4.20 and 2.4.20-smp_raid. Make the appropriate entries in /etc/lilo.conf and you can boot either one. Disabling a stock, working kernel config is lunacy. Using extraversion is obviously the safer method, that's what it's for. This is all mentioned in the kernel HOWTO, iirc.