Slackware Kernel HOWTO
Introduction
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:
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 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 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 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).
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.
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.
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.
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 how you
get the /proc directory with all that useful information. Also,
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, 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.
- 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 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.
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 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.
image = /boot/vmlinuz-ide-2.4.25
root = /dev/hda4
label = Linux_2.4.25
read-only
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 Slackware
you can add that module's name to the end of /etc/hotplug/blacklist
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
page
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.