1. Al Tourlakes' Completely Unauthorized Introduction

I bought Red Hat 5.1 (Intel) in October of 98, after about 16 years of
experience with Windows and OS/2. Linux was a whole new environment for
me; indeed, at one point I felt I would have to get off the train. But I
felt this train was the future, so I hung on.

Early on, one of the things I could only fantasize about was kernel
updating and customization. I read some of the available material on the
subject, and to me it was all nuts--Linuxese at its worst. So I figured
"some day, maybe in a few years."

Then I came across the buildkernel program. Wow--if it could do what its
developer said it could do, maybe I could update and customize my kernel
without actually knowing what the h___ I was doing! And that's exactly how
it turned out.

I downloaded the program, and did a cursory reading of the docs. Cursory
in the fullest, sloppiest sense. One of the first things my eyes glazed
over was the need for a whole laundry list of packages (files) that had to
be on the system in order for buildkernel to work. To a newbie, it was
overwhelming, and just too much work. "Maybe in a few years . . . "

But, it turned out that many, if not most, of the packages were already on
my system, either from the original install or from packages which had to
be installed for other programs. Which brings me to the first of my
recommendations: instead of fretting about all the programs you think
you'll need, just go ahead and run buildkernel and you'll be able to find
out what you need from the program's error messages. Many would think this
a slipshod way of doing things, but it worked great for this here newbie.
For me it turned out to be THE EASIER WAY.

You have to dial up the Net so buildkernel can access the newest kernel
and download the compressed file to your system. Incidentally, it's not
necessary to turn Netscape or any other browser on. Buildkernel needs only
a connection. Nor is it necessary to maintain the connection throughout
the time the program is running.

I entered "buildkernel" as root from an X terminal, sat back about 6" and
waited for my box to blow up. Immediately the program sprang into action,
like an origami pro.

As it did its thing, it displayed all kinds of wondrous messages, very few
of which had any meaning for me.

At a couple of points, it required human intervention, which involved use
of the Linux text editor called pico, which is the program's default
editor. Don't start buildkernel if you don't know how to run pico, at
least how to save and exit.

Also, don't start the program unless you have 2-3 hours to devote to it,
and have an idea of what kinds of Linux capabilities you want to "compile"
into your new kernel. About halfway into the party, you get the
opportunity to compile a very wide range of capabilities into your new
kernel--it's great.

For each of the capabilities, there's a help dialog. One of the nicest
things about the help is that toward the end it says, in effect: "if you
don't know what you're doing, say yes (or no)." In my case, for example, I
knew I wanted generic SCSI support, parallel port support, Net access
support, and so on. Beyond that, I didn't know what I was doing. But you
can't really go wrong with the defaults. It's good, though, to have an
idea of what you need for your particular usage before you start
buildkernel.

Oh--I have to remember to suggest to Bill Stearns, the developer of the
program, that he include speaker beeps at those points where human
intervention is required. So that I'll know when to come away from working
at my other box.

I had to run buildkernel several times, and get Bill's help before I
realized there's an EASIER WAY.

Nobody's asked me, but if someone were foolish enough to ask, here's what
I would say, based on my own successful experience:

(1) Know how to save and exit pico
(2) Have a rough idea of the capabilities you want in your new kernel.
(3) Connect to the Net (No browser needed.)
(4) Get an X terminal running, as root.
(5) Start buildkernel.
(6) When the program is over, it will tell you that the new kernel is
installed, and where it's installed. But aha! Be aware that it might be
lying, and you might not have a new kernel at all! Look where it says the
new kernel is; if it's not there, Henry, you don't have it. The build has
failed. It failed at first for me, and for a simple reason: my system
lacked some necessary files.
(7) Do the following; it worked quite well for me.  
		
Call up the bklog file in a text editor. Search for every instance of
words like "not found," or "no such." What you're looking for is every
case where a file, directory or command was needed by buildkernel but not
found by buildkernel. These are the missing files you need to install on
your system for buildkernel to sing; you don't have to laboriously go
through that long list of required files. You only have to install the
files you have to install. (What kind of writing is that?) Once you've
installed these files, buildkernel will work beautifully. (It did for me,
with Red Hat 5.1 on an old computer.)

Specifically, here are the packages I had to install. I went to my
favorite rpm downloading joint and scooped 'em up in the latest rpm
versions I could find.
		
		Gnu (gcc)
		autofs
		ipxutils (needed by ncpfs)
		ncpfs
		net-tools
		ppp.rpm
		procinfo
		procps-X11
		util-linux
		kernel-headers (needed by glibc-devel)
		glibc-devel
		bin86

That was it--after I rpm'ed these into my system, buildkernel worked
beautifully. The new kernel was where the program said it was. I had to
manually edit lilo.conf a little, but that wasn't buildkernel's fault.

Now, when the next kernel update is out, I'll just fire up buildkernel and
look like I know what I'm doing. While I do something else.

Now read the rest of this doc, and don't fret if you don't understand it.
I didn't; I still don't; and I may not care. But I have a new kernel, and
I care a lot about that. Bill Stearns' buildkernel has made Linux a lot
more promising for me. (How do these guys do it?) . . . Al Tourlakes