Slackware Kernel HOWTO


    I have endeavored to write a definitive HOWTO on compiling a kernel in slackware. This is written to people who are totally new to Slackware, or Linux, or both. I have borrowed from Sandman1's kernel documentation, located here. This will be a commentary on it. I will try to use his directions for a 2.4.x kernel family, which at writing was the best option, in my opinion, for a beginner with Slackware, due to the possible simplicity. First, since Slackware 9.1 uses 2.4.22 kernel, you can safely use its configuration on 2.4.25 and up kernels (i.e. kernels of the same family). You'll be using a configuration that you know is stable because you're using it right now. Second, at worst, you can go back and use your original.

Update 2.6.x Linux Kernel

    Now there is the new Linux Kernel, which will be default on Slackware after release 10.2.  However, many of us are using this kernel already.  I will put in italics advice pertaining to this kernel.

Getting the Source Code

    First, let's go locate a kernel. The best place to get the kernels is directly from their home page, here. When we find the kernel, we should see in its directory the LATEST_IS file, like this:

index of
          pub/linux/kernel/v2.4(click any thumbnail for the full picture)

This file is merely a pointer to what the latest kernel version is. This is sometimes used on other ftp servers to help users know what the latest release version of something is. Ok, so we know, now let's go get the file:

index of

As you can see, I've been here before :). Ok, so we can download the file. Notice that .bz2 and .gz files differ in size. I'll go over the file name and how you know what things are. Things with .tar extension in them are archives, i.e. a whole bunch of files contained in one bigger, but simpler file. The .bz2 and .gz extensions are merely different compression programs that were used to compress them, much like WinZip for Windows produces .zip files. Notice that .bz2 files are smaller than .gz files. They are (or should be) the same, in that they contain the same files. Bzip seems to have a better compression technique, however, because the file is smaller. Uncompressing either is still easy, so I go with the smaller of the two to reduce how long it takes to download. Ok, we download this as a user, to our home directory. For example, mine would be "/home/delahunt". Once it is done, I like to go to a console and unpack it by hand. There are several ways to do this, but I prefer the "old" way:

>bunzip2 linux-2.4.25.tar.bz2 tar -xf linux-2.4.25.tar

    Now we should see a subdirectory,linux-2.4.25. We can move to this directory and start the kernel compiling process:

>cd linux-2.4.25

Configuring the Kernel

    Ok, now we should have our kernel unpacked and ready to configure. There are many ways to do this by the way, so I'll briefly touch on them, but I'll focus on my favorite way. First, there's the very quick way: "make oldconfig". This won't always work, but it basically finds the configuration you're using right now, and uses that. I don't recommend this method. Second, there's the "make config" method. This goes through all the questions one by one, asking you each of them. I don't recommend this, because you might change your mind, and if you do, you'd have to start this process all over again. Third, there's "make menuconfig". This uses an ncurses (or text-menu) configuration program to allow you to view and modify the kernel config:


This method is, in my opinion, a good one. You can see the options and use the help option to get help on certain items. Also, usually in each help menu there's a phrase that goes something like this: "If you're unsure, select No." This is another good thing to watch for in options. If you don't see this phrase, in my opinion, you should not select "No", select "Module" or "Yes". The slackware bare.i config file is usually a good thing to use, or whichever you selected when you installed slackware. If you absolutely want to, you can manually download a config file from most slackware mirrors. The file is usually located in slackware-9.1/kernels/kernel-name, such as /slackware-9.1/kernels/bare.i or slackware-9.1/kernels/bareacpi.i. Usually the names are by name and extension, such as .i kernels are for ide systems (i.e. the main storage device, or hard drive, is ide), and .s kernels are for scsi systems. From there, the kernel names themselves, bare is the default, generic config, bareacpi is that plus ACPI support (power management), old_cd is for old cd drivers, jfs is for the JFS filesystem support, XFS is for the XFS file system support, pportide is for systems using a main hard drive over a parallel-to-IDE adapter, raid is for systems using RAID, etc. But anyways, enough about kernel choices. The next config I would suggest, for those of you using xwindows, is "make xconfig", which will build a graphical configuration tool. This one is nicer in my opinion, because you have the mouse, you can click help, and the pages are sorta linked together. You can start on one page and click next for the next page. Here's what make xconfig looks like:


Any one of these configuration method will work fine, but I recommend menuconfig.

    Note: if you have a Linux kernel that's a 2.4.x kernel and you want to "make oldconfig", it will NOT work 100% properly on a 2.6.x kernel, as these have different config file formats (for lack of a better description as to why).  I highly suggest that you start from scratch, and/or use Patrick's /testing configuration as a starting point, located on slackware-10.2/testing/source/linux-2.6.13/config-2.6.13.  As of Slackware 10.2, installing a 2.6.x kernel is now an option in the installer, but before it was not.  Also, Patrick has stated that the next release, 11, will have the 2.6.x kernel as the default.

Getting Started

    Now we should inventory our system. This will allow us to "trim the fat" off the kernel config and/or add to it. Technically, the same configuration should work from the slackware kernel to this kernel, but I don't like to take changes. The idea is to find out what your system has and then remember to put that stuff into the kernel. If you go changing things in the kernel, however, the results are up to you. If you don't know a lot about your computer at this point, proceeding can break your system, so some of you may want to either read up on your system, use a different computer to learn and experiment with, or just forget about this whole ordeal. I must've screwed up my slackware system like five or more times before I figured out how to do things properly. One of the main tools you can use to see what hardware your system uses is lspci, which looks like this:


    In this example, I am compiling a kernel on a desktop that uses an Intel D815EFV motherboard.  I suggest "make menuconfig" and running more than one terminal in  Everyone's configurations will be different, but I'll go through some of the pitfalls I've found over the time I've used Slackware. Remember, in this section of my HOWTO, you're on your own: I can only show you what my experience is, but you must make the decisions from here.

Processor Type and Features: Processor family

    For this option, I dial in whatever processor that I am using, just answering the question truthfully.  If you are unsure, you can leave it i386 and it will not cause problems.

Processor Type and Features: Dell / Toshiba Laptop Support:

    This depends on if you're using such a laptop.  In this example, I am not using such a laptop, but on my Toshiba Satellite A55-S306 page, I actually use this in the kernel config.

CD-RW / DVD-RW drives:

    Right now, Linux kernel family 2.4.x needs IDE-SCSI emulation to work properly.  However, kernel 2.6.x does not, but you still can include it.  You just need to set up the rest of the operating system not to load IDE-SCSI emulation for CD-RW/DVD-RW drives upon boot if you use kernel family 2.6.x, and this is done in two ways: 1) by not using one append statement at the top of /etc/lilo.conf file, but instead a "per kernel image" method of using append, so that you're not telling 2.6.x kernels to load ide-scsi, 2) by making sure that /etc/rc.d/rc.modules isn't loading anything you don't want it to (by editing the file).

IDE Drives, or whichever your system is installed on:

    In my opinion, do NOT build the generic IDE driver as a module: say "Yes".  That, and if you find your IDE controller in the config, say "Yes" to that one too.  Modules are loaded into memory from off the hard drive, and the system has to be able to access the hard drive to load the kernel before it can load modules, right? To me it's sort of the "robot unplugged itself" dilemna.  Therefore, I strongly suggest that IDE controller support be set up as "Yes" to build it directly into the kernel, rather than as modules that have to be loaded from that drive.

Experimental stuff:

    I usually don't include things marked experimental in my configurations, unless it's as a module. However, experimental doesn't mean unstable, just not really well seasoned.  It's up to you.


    These are video drivers for the xwindows system.  I usually include these in my config, but you don't have to.  By the way, the xwindows video drivers also work just fine.  I do not ever use outside drivers such as offered by ATI or nVidia.


    EXT2, EXT3 and Reisers each must be included as Yes in the kernel config if you plan to use these filesystems.  For example, I use ReiserFS, so I say Yes to this option and make ext2 and ext3 support modules in my kernels.  Like the IDE "robot unplugged itself" scenario, if your system is on a filesystem, support for that filesystem needs to be built into the kernel.  If you want to use XFS file system, you should be using the xfs kernel, so you should make sure the XFS file system is included as "Yes", etc, same idea.  Usually, however, the others that I don't use, I keep these as modules anyways, just in case I ever need them.


    I include firewire support as all modules.  I don't own firewire products yet, but I might want to use some eventually, and it would not be cool to have to recompile the kernel just to add something that you may eventually use.  This, however, is up to you, and how much disk space you have.  The modules don't take up much, but you might be severely limited on disk space.


    This is for infrared devices.  I usually include this section as all modules, just in case I ever plan to use it.

Old CD-ROM drivers:

    I don't know of anyone, myself included, that uses CD-ROM drives that aren't either IDE or SCSI (or parallel/usb, and those are listed in the parallel device and usb device areas) CD-ROM drives, so I usually just say "No" to this section.


    As usual, I don't own anything like this, but I include it as modules just in case I ever plan on using it.


    I don't use RAID or LVM (Windows Logical Volume Manager), so I say "No" to this section.


    I don't need it, so I don't include it.  This isn't required to use Skype, for example.  However, it's up to you.

Fusion MPT:

    It's basically IDE+SCSI in some way or something, but since I don't use it, usually I leave it out.

Other suggestions:

  1. If you use usb mice or keyboards, you need to include support for the Human Interface Devices (HID). I found this one out the hard way.
  2. In filesystems, /proc file system should be "yes". That's how you get the /proc directory with all that useful information.  Also, now you can include the /sys file system, which is nice.
  3. Most home internet users don't need NFS support, Netware (Novell) support, ARCNet, Apple's network, DECNet, Ethertap, or Token don't take my word for it: I'm only suggesting what most people don't use.  Ethertap is obsolete, token ring you'd know if you use it, if you don't have Macs on your LAN you don't need AppleTalk, etc.  You don't have to leave this stuff out, but it's up to you.
  4. If you use IPTables for your firewall, you can safely not include support for ipchains.
  5. For USB devices, you may want to make all the device drivers for the separate usb devices into modules, since you don't need them loaded in the kernel at all times (unless maybe you need your USB hard drive).  I usually make the entire USB section in modules.
  6. Modules make the kernel take longer to compile, as in the more devices you set up as modules, the longer it takes to compile them all. If you know, for example, that you don't use any devices made by a certain company, or you don't like that company, you can safely say "No" to these devices.

When you're done configuring the kernel, you can select Save and Exit, or Exit (and then say "Yes" to saving the settings), and start compiling.

Compiling the kernel

Now that you're done configuring the kernel, let's build it. You should at this point read the kernel INSTALL manual that comes with the kernel. I've put it here so that you can read it quickly. This is the file that comes with 2.4.25 kernel, and was written by the kernel development team.

Here's the sequence you should usually do it in (2.4.x kernels):

"make dep" makes the dependencies that are required for the kernel to compile properly. Note: this step is no longer needed on 2.6.x family kernels. "make bzImage" makes a kernel image, which basically is the kernel. This is the file you see as /boot/vmlinuz-ide-2.4.22 on Slackware 9.1. "make modules" makes all modules that you configured the kernel to use. "make modules_install" installs the modules you made to /lib/modules/2.4.25 (2.4.25 being the kernel version you're compiling). Honestly, if you didn't change kernel versions, you can skip making modules or modules_install. This is because there should be enough kernel modules already, unless you changed them. If you're not sure, just make modules and modules_install anyways. Now we can sit back and watch the kernel compile. I usually put those commands on the same line as "make dep && make bzImage modules modules_install". What to do if something goes wrong: first, look at what happened.

    Note: for 2.6.x kernels, all that is really required is "make bzImage" then "make modules" then "make modules_install".  This is how I do it on 2.6.x kernels.

Let's first try this example:


In this example, I intentionally caused an error. You can get the "no rule to make target" error when you accidentally misspell something. Ok, now let's try another example:


This isn't really an error, it's just telling you that the kernel isn't small enough to fit on a floppy disk (1.4MB).  (Note: 2.6.x kernels no longer tell you this)  Lastly, there's the module problem:


First, you see me trying to generate this error. I tried "make modules" without any configuration. Then I cheated and tried to make modules without "make dep". The point is that errors, you'll see where and what the problem is. With this one, you see the autoconf module having the problems. With other module problems you should see what and where it is, such as scsi/emultk or whatever. Either find out what the problem is by going back into the config, or else you can also just remove the module, if you don't need it. I tend to do that a lot with SiS device modules. Lastly, the above errors are being reported by the make program, which is why you see "make: *** No rule to make target ...." and such. One thing that can happen is depmod could say it has "unresolved dependencies" or such. This usually means that a module wants to depend on other modules, and that the dependencies aren't satisfied. In this case, you could either find the missing dependencies, or you could also just remove it (if you don't need it). Anyways, you should be done compiling now. Now let's move on to installing it.

Installing the Kernel

Now we're done compiling, but what good does our kernel do? Let's install it! Slackware usually works using the following naming convention in the /boot area:


    Here you see my boot area that I was using a while back. The light-blue colored files are symbolic links. There are three important files in a linux kernel: the config, the, and the bzImage. What slackware developers use goes like this -- the files are renamed to indicate the type system (IDE) and the kernel version (2.4.24) that they are. The bzImage file, in linux/arch/i386/boot/, is renamed vmlinuz. From here, I was told that the file is not needed by normal users, so we can leave alone. If we really want to save the configuration, we can save it to /boot as /boot/config-ide-2.4.25 or whatever fits in the naming scheme. Another thing is that I have been told that, if you know what you're doing, you can remove all the kernel packages that are installed with slackware, except the kernel-headers package (do not remove that!). Then one can build the kernel like normal and then install it. This is only for the elite, and I do not recommend doing that unless you're sure you know what you're doing. So we would copy where_we_built_kernel/arch/i386/boot/bzImage to /boot/vmlinuz-ide-2.4.25 (or whatever the kernel version is, etc), making SURE we don't want to over-write files unless that's our intent. Nothing worse than accidentally overwriting a known-good kernel (say, slack 9.1 vmlinuz-ide-2.4.22) with one we don't know is good yet. There is nothing wrong with putting as many kernels as we want in /boot/, naming them what we want, so long as we watch what we're doing.

    So, let me run over an example of a lilo.conf file with you. The original lilo.conf file should look something like this:


    Mine has been edited, and while you can find better resources and documentation for LILO elsewhere, I would like to make the following suggestions.  First, use vga-normal, NOT frame buffer.  While it might seem like a bummer, here is why: if you screw up something in your kernel and something fails to load, without framebuffer you'll have nothing to look at.  It's happened before that people would reboot and their screen would "vanish" because LILO tries using framebuffer, but their framebuffer device didn't load.  Another reason I don't use framebuffer, either in kernel or in LILO.  That's why I removed all the other vga = blah settings in mine and went with normal "vga = normal".  Second, do NOT change things in lilo.conf unless you're SURE you know what you're doing.  Read before you bleed (or #include RTFM.o), or whatever, but read before you break things.  We can see the previous kernel's configuration area, the one that starts with "image = /boot/vmlinuz" and ends with "read-only".  This is one kerne l. The image part points to the bzImage file for the kernel. In this case, it's /boot/vmlinuz.  The "root = /dev/hda4" part tells LILO what the /boot partition is.  This should remain the same. The "label = Linux" part tells LILO what to label this kernel when the LILO boot menu comes up. You can change that to just about anything, except you cannot use spaces on that. I recommend keeping it simple, like "label = Linux_2.4.25". Lastly, the "read-only" part, according to the "man lilo.conf" page, "This specifies that the root file system should be mounted read-only. Typically, the system startup procedure re-mounts the root file system read-write later (e.g. after fsck'ing it)." You want the root file system mounted read-only, trust me, so use that.
    So we could add our own kernels AFTER the one that's already in lilo.conf by putting this after "read-only":

image = /boot/vmlinuz-ide-2.4.25
   root = /dev/hda4
   label = Linux_2.4.25

This should add our kernel. Now, as root, we need to re-run LILO. As root, just run "lilo". You should see it tell you what kernels it has added, i.e. the ones we have in lilo.conf, if they were configured properly. At times, you will hear it say things like "Warning: LBA32 addressing assumed", etc. This is because your hard drive uses Large Block Addressing mode, 32bit, and LILO can see that it does, but you didn't include "lba32" in lilo.conf file to tell it. If it does, you can just add "lba32" in lilo.conf after the "timeout =" command at the top of the lilo.conf file. That is per the example lilo.conf file in the "man lilo.conf" page. Also, notice that of the kernels that are listed by LILO, one has an asterisk in front of it. This means it's the default kernel (i.e. if you leave the keyboard alone long enough and the seconds run out, it would boot that kernel, and it when LILO runs at the beginning this kernel will already be selected so that you only have to press the enter key to boot it). The default kernel is the first one in the lilo.conf file, so you could add your kernel above the old kernel portion in lilo.conf if you truly trust your config. I usually leave the default kernel alone and just add kernels to it. If LILO finds faults, it will not update the config, so you should troubleshoot it from there if you run into problems. Without LILO reconfiguring itself, you won't be able to boot the new kernel should work. If not, this is why you keep the old kernel in lilo.conf -- so that you can boot it if your new kernel fails.

Other personal notices:

  1. If you don't want a module to load when you boot, in Slackware you can add that module's name to the end of /etc/hotplug/blacklist file to tell hotplug not to load it automatically.
  2. You can run "depmod -a" to make sure modules are updated before rebooting to the new kernel.
  3. You can run "generate-modprobe.conf" as root to update /etc/modprobe.conf, but this is optional.

Further recommended reading:


Linux is a registered trademark of Linus Torvalds.

Valid HTML 4.01 Strict