Slackware Kernel HOWTO
I have endeavored to write a definitive
on compiling a
kernel in slackware. This is written to people who are totally
Slackware, or Linux, or both. I have borrowed from Sandman1's
documentation, located here.
will be a commentary on it. I will
try to use his directions for a 2.4.x kernel family, which at
was the best option, in my opinion, for a beginner with
to the possible simplicity. First, since Slackware 9.1 uses
kernel, you can safely use its configuration on 2.4.25 and up
(i.e. kernels of the same family). You'll be using a
you know is stable because you're using it right now. Second, at
you can go back and use your original.
Update 2.6.x Linux KernelNow 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:
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:
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:
Now we should see a subdirectory,linux-2.4.25. We can move to this directory and start the kernel compiling process:
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
you have a Linux kernel that's a 2.4.x kernel and you want
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
to why). I highly suggest that you start from scratch,
Patrick's /testing configuration as a starting point,
Slackware 10.2, installing a 2.6.x kernel is now an option
installer, but before it was not. Also, Patrick has
the next release, 11, will have the 2.6.x kernel as the
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 X.org. 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.
Right now, Linux kernel family 2.4.x
to work properly. However, kernel 2.6.x does not, but
can include it. You just need to set up the rest of the
system not to load IDE-SCSI emulation for CD-RW/DVD-RW drives
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,
instead a "per kernel image" method of using append, so that
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
editing the file).
In my opinion, do NOT build the
driver as a
module: say "Yes". That, and if you find your IDE
config, say "Yes" to that one too. Modules are loaded
off the hard drive, and the system has to be able to access
drive to load the kernel before it can load modules, right? To
sort of the "robot unplugged itself" dilemna. Therefore,
suggest that IDE controller support be set up as "Yes" to
directly into the kernel, rather than as modules that have to
from that drive.
I usually don't include things marked
experimental in my
configurations, unless it's as a module. However, experimental
mean unstable, just not really well seasoned. It's up to
These are video drivers for the
system. I usually
include these in my config, but you don't have to. By
xwindows video drivers also work just fine. I do not
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
modules in my kernels. Like the IDE "robot
unplugged itself" scenario, if your system is on a filesystem,
for that filesystem needs to be built into the kernel.
want to use XFS file system, you should be using the
xfs kernel, so you should make sure the XFS file system is
"Yes", etc, same idea. Usually, however, the others that
use, I keep these as modules anyways, just in case I ever need
I include firewire support as all
modules. I don't own firewire products yet, but I might
use some eventually, and it would not be cool to have to
kernel just to add something that you may eventually
however, is up to you, and how much disk space you have.
modules don't take up much, but you might be severely limited
This is for infrared devices. I
usually include this section as all modules, just in case I
to use it.
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
but I include it as modules just in case I ever plan on using
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.
it's up to you.
It's basically IDE+SCSI in some way or
something, but since I don't use it, usually I leave it out.
- 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.
- In filesystems, /proc file system should be "yes". That's
get the /proc directory with all that useful
now you can include the /sys file system, which is nice.
- Most home internet users don't need NFS support, Netware
(Novell) support, ARCNet, Apple's network, DECNet, Ethertap,
don't take my
word for it: I'm only suggesting what most people don't
is obsolete, token ring you'd know if you use it, if you don't
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.
- If you use IPTables for your firewall, you can safely not include support for ipchains.
- 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.
- 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.
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.
- make dep
- make bzImage
- make modules
- make modules_install
"make dep" makes the dependencies that are required for
kernel to compile properly. Note: this step is no longer
2.6.x family kernels. "make bzImage" makes a kernel image,
basically is the kernel. This is the file you see as
/boot/vmlinuz-ide-2.4.22 on Slackware 9.1. "make modules"
modules that you configured the kernel to use. "make
installs the modules you made to /lib/modules/2.4.25 (2.4.25
kernel version you're compiling). Honestly, if you didn't
versions, you can skip making modules or modules_install. This
because there should be enough kernel modules already, unless
changed them. If you're not sure, just make modules and
anyways. Now we can sit back and watch the kernel compile. I
put those commands on the same line as "make dep &&
bzImage modules modules_install". What to do if something goes
first, look at what happened.
2.6.x kernels, all that is really required is "make bzImage"
modules" then "make modules_install". This is how I do
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.
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 System.map, and the bzImage. What slackware developers use goes like this -- the System.map 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 System.map file is not needed by normal users, so we can leave System.map 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
find better resources
and documentation for LILO elsewhere, I would like to make the
following suggestions. First, use vga-normal, NOT frame
it might seem like a bummer, here is why: if you screw up
your kernel and something fails to load, without framebuffer
have nothing to look at. It's happened before that
and their screen would "vanish" because LILO tries using
but their framebuffer device didn't load. Another reason
framebuffer, either in kernel or in LILO. That's why I
other vga = blah settings in mine and went with normal "vga =
Second, do NOT change things in lilo.conf unless you're SURE
what you're doing. Read before you bleed (or #include
whatever, but read before you break things. We can see
kernel's configuration area, the one that starts with "image =
/boot/vmlinuz" and ends with "read-only". This is one
part points to the bzImage file for the kernel. In this case,
/boot/vmlinuz. The "root = /dev/hda4" part tells LILO
partition is. This should remain the same. The "label =
tells LILO what to label this kernel when the LILO boot menu
You can change that to just about anything, except you cannot
spaces on that. I recommend keeping it simple, like "label =
Linux_2.4.25". Lastly, the "read-only" part, according to the
lilo.conf" page, "This specifies that the root file system
mounted read-only. Typically, the system startup procedure
the root file system read-write later (e.g. after fsck'ing
want the root file system mounted read-only, trust me, so use
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.
- If you don't want a module to load when you boot, in
you can add that module's name to the end of
file to tell hotplug not to load it automatically.
- You can run "depmod -a" to make sure modules are updated before rebooting to the new kernel.
- You can run "generate-modprobe.conf" as root to update /etc/modprobe.conf, but this is optional.
- Slackware Home Page -- Great place to read up on Slackware, and includes quite a bit of useful information.
- The Linux Documentation Project -- Great place to find documentation for things. On a Slackware computer with linux-docs installed: "/usr/doc/Linux-HOWTOs", lots of knowledge here as well.
- My Configuring Linux page
- My Securing Slackware
Linux is a registered trademark of Linus Torvalds.
- Slackware is a registered trademark of Patrick Volkerding.
- LILO is a registered trademark of Werner Almesberger.
- Screen shots generated using the GIMP
- created by Peter Mattis, Spencer Kimball, Manish Singh, and the GIMP development team.
- Screen shots of programs Mozilla, XTerm, Gedit, "make xconfig", etc, are held by the related developers.