LinuxFox, by Alan Mackey Tux the penguin, the Linux mascot

Patching and Compiling the Kernel

Now that you've got Linux installed on your system, you're ready to patch and recompile the kernel. This is a necessary step towards a fully functioning system; Chris Beauregard's Slackware MCA Installation Instructions make note of this on the last page. In fact, one of the "many other things that'll contribute to an enjoyable Linux experience" that I found missing from the bootdisk kernel was serial, or at least modem, support. I found myself unable to use my modem to dial up anywhere until I had patched and recompiled the kernel. So, do yourself a favor and take this step as soon as you can.

There are three things you absolutely must have to do this step -- the kernel source, the development tools, and the latest patch from the MCA Linux homepage. I also strongly recommend having the kernel HOWTO, although you can just read and remember it if you like. Depending on how you got your Linux installation packages (CD or download) and what you actually installed, you may already have some or all of these things. The kernel HOWTO, if you have it, will be in the folder /usr/doc/Linux-HOWTOs and is named Kernel-HOWTO; it was put there when you installed the FAQ (f1) packages. Just in case you don't have something, here they all are again:

You don't have to download the kernel HOWTO unless you really want to, since it's usually put on your system when you install the FAQs. Just print it out, read it, and keep it handy. It's full of very useful information that you're going to need, which, just like the installation instructions that I guided you to, I'm not presently reproducing here. Instead, I'll refer to the HOWTO as I try to walk you through what you're going to see as you proceed along the patch/compile process path.

Also note that the patch set has one of those really long filenames. If you're downloading to a DOS/Windows 3.1 system, you'll have to rename it using 8.3 file name conventions. pach2035.gz worked for me, but you can use something else if you like.

Now, you'll have to install the kernel and development packages, (unless you did this when you first installed Linux). The easiest way that I know to do this is with the setup command that you used when you did the installation. So, type

at the command prompt and press enter. You'll get the same setup menu that is presented for the Linux installation.

This time, however, you're going to use the PKGTOOL selection. Choose it; you'll be presented with another menu. Unless you happened to run setup from the directory that your packages are in, you'll choose the Other selection. In the "SELECT SOURCE DIRECTORY" box that's presented, type in the full path to the directory where the package is located. Note that you'll have to install the packages one at a time.

I actually had to do this when I did my installation, as part of my download didn't make it to my system intact, so I'll use my experiences (yet again :-) ) as an example. In my system setup, my DOS partition is mounted, under root (/) on a filesystem named c-drive, and all of the packages I downloaded were located in a subdirectory structure there. So, when I installed the kernel source, the path I entered in the "SELECT SOURCE DIRECTORY" box was:

and for the development package was:
Pkgtool will find the diskk1 and diskd1 files, and prompt you through the different packages in the d1 and k1 package sets. Install the entire k1 package set -- you'll need it all. You may want to also install the entire d1 package set to avoid figuring out which packages you need and which ones you don't. If you don't want to install the entire set, make sure you do install anything and everything necessary that has to do with compiling C/C++ programs. This includes the binutils, gcc, gmake, and libc packages at a minimum. You may want to include things like gdb (the gcc debugger), libcinfo (the info files for the C library), and anything else that mentions C/C++, just in case you need them. You can safely skip the three egcs* packages. Of course, if you're into program development, you'll probably wind up installing this whole package set anyway, won't you? :-)

Using the above method to install the kernel source on my system, I found some differences than what was discussed in section 3.2 of the kernel HOWTO. The kernel source was installed into a directory with the name of the kernel version. When I did a cd to /usr/src, I discovered that the directory named "linux" was simply a link to the directory named "linux-2.0.35," which is what the kernel HOWTO recommends changing the "linux" directory to before unpacking the source into a new "linux" directory. What I did, then, was to copy the entire "linux-2.0.35" directory to another directory named "linux." That way I had a backup for the source tree in case something went wrong (it didn't). If this is the first time you've ever done something like this, I recommend you do the same, if only for the peace of mind it gives you. :-) Note that if you install your kernel source this way, you don't have to worry about knowing anything about the 'tar' command used in section 3.2 of the kernel HOWTO. Don't worry -- you'll have plenty of time to learn.

Now you've got the kernel source installed, and the development tools you need as well. You're going to need one more thing -- the README in /usr/src/linux you're told to look at in section 3.2 of the kernel HOWTO. Instead of just reading over it, you may find that you want to print it out. This will be kind of difficult on your new Linux system -- parallel printing support is one of the things that Chris Beauregard told you that would be missing in the kernel you installed from your bootdisk. That's why you're patching and recompiling immediately after installing, remember? It's OK, though. You can get that file printed out without much problem. It's just a plain ASCII text file.

If you left a DOS/Windows partition on your Linux system, and you're mounting that partition (you told setup you wanted to do this, right?), you can just copy the README into a directory there, then boot to that partition and print it out from there. At the Linux command prompt, in the /usr/src/linux directory, type:

cp README /[your DOS partition name]/[some directory(s) there]
where [your DOS partition name] is whatever you're mounting your DOS partition as, and [some directory(s) there] is exactly that, some directory off of your DOS root directory, or a subdirectory underneath (my personal favorite for stuff like this is TEMP). So, for example, on my system this would be:
cp README /c-drive/temp
Then, you'll boot to your DOS/Windows partition and use whatever you like to use to print ASCII text.

If you don't have a DOS/Windows partition left on your Linux system, you'll have to copy the file onto a floppy disk and take it to a computer that can print. First, you'll have to tell Linux that you want to use the floppy drive. This is called mounting the drive (actually you're mounting the filesystem for the drive). Here's what to do:

This mounts the floppy and makes it ready for use. The directory /somefoldername is called the mount point. It's empty until you mount some filesystem onto it. And it probably needs to stay empty if you intend to mount future filesystems onto it. You could put files into this directory, but the next time you mount a filesystem onto it, the files will be inaccessible; you won't even be able to list their names. It probably works out better if you just leave it as an empty directory.

One popular directory name for a mount point is /mnt. Several sets of instructions for using mount use /mnt or a subdirectory under /mnt as a mount point. I personally wanted something familiar, something that I would recognize as the location for mounting my floppies, so I named the directory I created for my floppy mount point /a-drive.

Anyway, once you've mounted your floppy disk, you'll copy the README to it in the same way as above:

cp README /somefoldername
and then take it to another system to print it out.

And remember, you don't have to go through all this (although it does give you some good practice at using your Linux system). You can just look at the file, and try to remember the important points, or take notes. The thing is, the kernel HOWTO refers to it, and I'm referring to the kernel HOWTO, so I want to make sure that you've at least seen all of the information available to you for this procedure.

And you will be using information from the README for the next step. Just as the kernel HOWTO says, you want to use the section entitled "INSTALLING the kernel" for patching the kernel source, setting links, and removing stale dependencies. Just follow the steps listed in the README for doing those things. Type in the commands just as they are given; a few notes on them follow.

First make sure you're in the right directory, if you changed to print the README:

cd ..
This changes you to the parent directory. Don't do this unless you changed directories to print the README. Also make sure you include the space between the "cd" and the "..". You should now be in /usr/src. If you just plain lost, just enter
cd /usr/src
and you'll be in the right directory.

You're only going to apply one patch, the one from the MCA Linux homepage you downloaded. Also, if it isn't glaringly obvious with the font you used to view or print the README, notice the following about the patching command(s) (which I've duplicated here):

gzip -cd patchXX.gz | patch -p0  <-- This is a zero!

Actually, all you've done here is use your (now) old friend gzip to unzip the patch file, then feed the output to the patch utility, using a pipe. This may actually be familiar to you, as DOS uses pipes, too. Just make sure that you do include the spaces between the commands and the pipe symbol (|). While you can get away with omitting the spaces in DOS, they are necessary in Linux (Unix).

You can also try the patch-kernel script discussed in the README if you like. And section 5 of the kernel HOWTO gives additional information on applying a patch.

Now, you can just type in the next two sets of commands from the README without really worrying about the details of how they work. The ln command creates symbolic links (that's what "symlinks" means) to the appropriate include files. You'll most likely learn more about this utility as you work with your Linux system -- Unix uses links to do all kinds of things. You can get more information about it from the man pages. You'll have them if you installed the applications package set (ap1). Just type

man ln
at the command line, and you'll get several pages of information.

The make command invokes the make utility on Makefile(s) that are installed along with the rest of the kernel source. The Makefile(s) actually contain all of the commands and switches that the compiler needs to do its work. So, when you enter

make mrproper
as specified in the README (after changing to the correct directory), you're using certain commands and switches in a certain Makefile to do some preparatory cleanup. If you are interested in programming and/or understand about invoking a compiler from the command line, you can get more information about the make utility from the man pages, too; additional information can come from reading the Makefiles themselves.

Now that you've applied the patch and finished setting everything up, the next step is to configure the kernel. For me, this was probably the most time-consuming part; but then again, I read and reread everything that was presented to me, so you wouldn't have to. ;-) I also had to do this several times, as I made some mistakes the first time through, and my kernel compile failed. So much the better for you. :-)

The alternate configuration commands that the kernel HOWTO and README discuss are most likely meant to be used on a fully functioning system. I know that you won't be able to use "make xconfig" unless you've been able to wave a magic wand and get X Windows running. And, as far as I know, you won't be able to do that until you get finished with this procedure.

On the other hand, you did install ncurses if you installed all of the development packages. You're welcome to try "make menuconfig" if you like; I was somehow under the impression that there was some additional setup needed for ncurses and didn't mess with it.

The kernel HOWTO and README also emphasize "make config" needs bash to work. You may be wondering what "bash" is. bash is your command shell. The shell is the process that supplies your command environment. DOS has a similar concept, one you may recognize if you've ever put a SHELL= line in your config.sys file. That's the idea here, except you have several choices for your shell, and a Linux shell environment is significantly more powerful than the DOS command line.

Anyway, bash is the default shell that you get when you first install Linux, and it's the one that starts up when you start your system. You have to give a command that invokes another shell to be using one, and you would have to make some configuration changes to have another shell start up on system startup. Unless you've played with the base system for a while and figured this out, you don't have to worry about this right now.

The README doesn't refer to the individual kernel configuration options at all; the kernel HOWTO discusses many of them, but not necessarily in the order in which you will encounter them. Since I'm assuming that this is the first time you've ever done something like this, I will try to at least mention each one, except for a few that you are very unlikely to see, in the order in which I saw them. In some cases I'll have something to say about the option, in others I won't; and in yet other instances I'll simply refer to the kernel HOWTO, if that's where the best description of what you're doing is. I'll also note what response I gave for each option, and why, if I think it'll help you.

The responses you'll make for most of the options will be of one of two forms, either

As noted in the kernel HOWTO, the ? will give you some help in the form of a description of the option; m will cause the option to be compiled as a loadable module; y is for yes and n is for no. The order of the responses varies, I guess according to how strongly recommended a particular response is. And the help descriptions actually were pretty helpful, at least to me, even if I did read some of them more than once. So you may want to look at them, too. Also, several of the options had the word 'NEW" in brackets next to them the first time I did this. I believe these were options that were added during the patch of the kernel source.

So, you're going to type

cd linux
and press enter to be in the /usr/src/linux directory; and then
make config
and press enter. Here is approximately what you'll be asked.

Now will be some general setup options.

Next are options for various block devices. Block devices are things like floppy drives and hard drives. This group of options covers floppies, IDE, ESDI, etc. SCSI will come later.

Next are options for networking. These are basic options, like protocols, not the actual devices, which come a little later. Many of these will get only a brief mention, as I didn't enable them and there are others which need to be enabled, and therefore discussed. I will try to go into more depth about these options.

Next is support for SCSI devices. Note that almost all of these options can be compiled as modules.

Now we get to the support for network devices.

Next is support for ISDN devices. I don't have ISDN, so I didn't use this option. I can say that there is some PPP support, and that there aren't very many devices supported. If you have ISDN, hopefully pressing ? and the READMEs it references will tell you all you need to know.

After that comes support for non-SCSI/IDE/ATAPI CD-ROM drives. There's only a handful of devices here, too. You'll probably just say no here, but you can always press ? to get more information.

Next you'll configure the filesystems you're going to use. This sets up the filesystem formats that your Linux system will recognize as valid. At the least, you'll be able to read and list files in formats other than the Linux native format, and in some cases you'll be able to write the files (as in moving and copying) to disk. Note that any of these filesystems can be compiled as a module, but in many cases you'll run across restrictions on how you can use them. I recommend you decide what you need and just compile it directly into the kernel.

One way to determine what filesystems you'll need to support is to get a list of those you are currently using. These were probably set up when you installed Linux, and should be an accurate indicator of your needs. So if you type

at the command prompt, and press enter, you'll see a list that resembles the one in section of the kernel HOWTO. The listed "types" are the filesystems you need to support in your kernel. The only exceptions would be if you were planning for some future need (i.e. including VFAT support for a planned Windows95 installation on an existing DOS FAT-16 partition); or including support for one of the more obscure filesystems that you know is on another partition, but the installation bootdisk wouldn't recognize.

Section 3.3.9 of the kernel HOWTO describes some of the supported filesystems; pressing ? will get an explanation of each of them. And if you haven't gotten tired of reading so much stuff by this time, I would suggest that you do read those explanations. There are little bits and pieces of interesting information scattered about all over in there.

Next is support for character devices. These are things like the serial and parallel ports, and the mouse. Remember from the MCA Linux yinstallation instructions that parallel printing and mouse support aren't included on the installation bootdisk. And I discovered that serial support wasn't there either -- at least it wasn't for me. So this set of options is just about as important as hard drive and networking support. There's a little information on character devices in section 3.3.10 of the kernel HOWTO.

Other character devices include multiport serial adapters and certain kinds of tape drives. Also included here are miscellaneous devices, Advanced Power Management, a Watchdog timer device (a special file that causes the computer to reboot if it's not written to in a certain amount of time), and the Real Time Clock. There are only a few things that are of any real interest, however.

Next is sound card support. I won't go into a great deal of detail here, since I don't have one and can't document this from experience. As near as I can tell, you'll need to have the specifications and configuration of your card readily available. There seem to be a few basic kinds, such as SoundBlaster, that you select from; then you set things like it's IRQ, DMA and I/O address. I did not notice any of the PS/2 sound cards with which I am familiar, so unless they are 100% compatible with the cards in the list, they may not be supported. I just don't know. There's some additional information in section 3.3.11 of the kernel HOWTO.

The final options are the kernel hacking options. These are discussed in section 3.3.13 of the kernel HOWTO. This is also an option to which you'll just want to say no.

You can check the top-level Makefile now if you wish (since a message telling you to appears), but if you don't understand anything you see, you can just skip this part.

There's just a couple of things left to do to be ready for the actual kernel compilation. The first is to set up dependencies correctly so things like include files are in all the right places. The second is to clean out any old file versions. So you'll type

make dep
make clean
and let the compiler do it's preparation thing.

Now you're finally ready to compile the kernel itself. Get yourself a book or something, because this could take a while. (Mine took about 45 minutes or so.) Type

make zImage
press enter, and sit back and hang out. You'll want to keep half an eye on your system so you can see if any error messages come up. We don't expect them, but just in case . . . .

You'll know that you were successful if you didn't see any error messages and there is a nice, new kernel image in the directory /usr/src/linux/arch/i386/boot. So type

cd /usr/src/linux/arch/i386/boot
to change directories. Then type
ls -l
to get a directory listing. There at the bottom of the list should be a file named zImage.

There's no reason to panic if the compile does fail the first time around. There can be lots of fairly simple reasons for it that are easily fixed by running "make config" again, and rethinking the original configuration decisions. For example, on my first pass through the kernel configuration I put in all kinds of stuff that I didn't really need, but thought might be useful. In addition, I didn't support ELF binaries properly, or compile the kernel as an ELF binary. As a result, my first attempt at compiling failed. Horribly.

I tried "make zImage" again, this time watching for the error messages, but alot of what I saw went by too quickly on the screen. Fortunately, there's a way to simultaneously send the output to both the screen and a file. Discussed in section 11.1 of the kernel HOWTO, it's called the tee utility, and I used it with "make zImage" (yet again) like this:

make zImage 2>&1 | tee somefilename
where "somefilename" is the name of the file to be sent the output of the "make zImage" command. In my case the file was named "kernelerrs.txt". Since the file is just plain ASCII text, you can name it pretty much anything you want.

Taking advantage of the tee utility as above allows you to read any error messages you got when you "made zImage". You'll use the cat command to do this, and you'll most likely have to pipe that output throught the more utility. This is used like this:

cat [somefilename] | more
You'd then go through the file line by line using the enter key, or page by page using the space bar. When you're through looking at the file, press q to quit.

Another way to accomplish the same thing is the less utility. You'd call it on the file name, like so:

less [somefilename]
and then move through the file the same as above. The nice thing about the less utility is that you can scroll up and down through the file using the up and down arrow keys.

Unfortunately for you, I'll have to leave you on your own here. I can't see your error messages, so I can't tell you what went wrong. :-) You'll just have to read and interpret them on your own. I believe most of them explain themselves in a fairly straightforward manner -- at least the ones I got did. Section 7.3 of the kernel HOWTO discusses some of the reasons a compile may fail.

Once you've compiled the kernel successfully, you're almost finished. First you'll do a "make modules" in the same manner to compile all the options you chose to use as modules. Then you'll do a "make modules_install" (as noted in the kernel README) to install those modules. The "make modules_install" mostly puts them in the right places and does some set up for them, like making insmod and rmmod, among others, available for use. Section 9 of the kernel HOWTO has a discussion of the modules.

And, of course, you'll want to install your new kernel. This basically involves copying it over the old one and rerunning LILO, as discussed in the kernel README and section 4.4 of the kernel HOWTO.

You might want to back the old one first up just to be safe. This really isn't necessary, I suppose, but it sure gave me some peace of mind when I did it. If you want to do this, type

cd /
to get to the root filesystem, then copy the "vmlinuz" you find there to a safe place. The location of that safe place is up to you. I created a directory named "bootbak" or something like that and copied it there:
cp vmlinuz ./bootbak
Then, I installed the new kernel by changing to the directory (mentioned above) that it was in and copying it over the old kernel.
cd /usr/src/linux/arch/i386/boot
cp zImage /vmlinuz
Alternatively, you can just leave the new kernel where it is, and just add it to lilo.conf in that location before rerunning lilo. This conditional kernel install is discussed in section 11.2 of the kernel HOWTO.

Once the new kernel is installed in root, you'll need to reconfigure and rerun lilo. You should already be a little familiar with LILO, since you got an introduction to it when you did your Linux install. You can look at /etc/lilo.conf if you want, and you'll have to add the backup kernel image, or the new one if you didn't install it in root, if you want to have them as additional options. Once you've got lilo.conf set up the way you want it, just run the "lilo" command to install the new configuration.

And that's basically it. You can now reboot your system. You might want to have a tested boot floppy on hand just in case, but you should be able to just boot to the new kernel. If you do have trouble, section 7 of the kernel HOWTO lists several things that can cause problems, and how to deal with them.

But hey, you're good at this right? You won't need any of that stuff, now will you? :-)

Back to my main PS/2 page

MCA Mafia Banner