This is probally oversimplified and incorrect on one level or another, but
this list is open discussion, so these comments may be freely modified and
what have you.
The Linux kernel is a part of your Linux OS, I'd say you wouldn't have an OS
with out it, but the kernel by itself is not the OS. From the kernel you get
support for you hardware (drivers for your ethernet, modems, printer ports,
agp, scsi, hard disks, filesystems, etc...), but without tools like cp,
mount, mkfs, fsck, etc, the kernel is pretty worthless. (from the end-user
perspective anyway.)
In the case of Linux the OS itself is pretty basic. Consider a complete
Linux OS to be something containing all the tools you need to boot, login
to, and install software. For the sake of argument, this is a pretty useless
system. (Compare it to a plain DOS install.) So, all you have is the kernel,
a handful of admin tools, a shell, package management tools (apt, dpkg,
rpm), probally perl, and a small editor. (nvi, elvis, ae).
At this point there is nothing really useful, but you are to the point where
you can install the real useful stuff like XFree86, development tools,
GNOME, etc.
This kind of seperation is good and bad. Good in that it makes Linux very
flexible. It's easy to get a headless webserver or a X-based workstation
from this point. (Most users won't actually see just this as various
distribution installers tend to hide this from the user, more on distros
later...) Bad in that it may just scare the new user who, *GASP* have never
used a command line only os. But hey, I'm all for scaring users. Break the
mold, not every system has to have a pretty face.
So there you have a very ruff definition of the Linux Operating System.
Now we move on to a Linux Distribution. Distro War all you want, but what a
Distribution boils down to is Linux OS bundled with all the software you
could ever want and then some. (Well, I'm sure you'll find some excetions.)
Software including dev tools, webservers, Xservers, Xclients, etc. Each
distribution has different ways of installing, package managment,
administration, and what have you. Some things are common, some things
should be more common across Linux distributions (See Linux Standards Base,
a totally seperate rant. :)
So now we've got a ruff idea of what we're dealing with. So, why is it that
we have to compile this kernel thing and how do we go about doing so? Well,
quite often you don't have to compile the kernel. Your distribution
prepackages pre-compiled kernels that have just about every option turned on
(or at least compiled as modules) so you should have a rather functional
kernel out of the box.
Some situations call for a new kernel to be compiled. New versions of the
kernel support new hardware, and other new features such as ReiserFS. And
then theres the geekish drive to run the latest and greatest, so we compile
a new kernel!
The first thing to do is to get your kernel source code from
ftp.us.kernel.org (or a mirror). The latest kernel is 2.4.1. Most people are
probally still running on a 2.2 series kernel. (For most a 2.2 series kernel
is just dandy anyway.) You'll want to get 2.2.18 unless there is something
preventing you from going to this kernel (RedHat + Dell often ship biniary
only drivers for Adaptec RAID cards. Other hardware vendors may only support
certin versions of the kernel, other stuff like that.)
So you have your kernel source, the next step is to extract it. The debate
as to where has been going on for some time now, and I've mentioned this in
the past. Linus says that the kernel source should be extracted to a users
home directory and compiled there as a normal user and should be installed
by root. (For fear of overwriting the header glibc was compiled agnist.)
Most distributions put these headers in /usr/lib/include, and thus
invalidating the /usr/src/ arguement. In most cases, it is safe to extract
and compile kernel source in /usr/src. Doing it as a normal user or as root
is a matter of personal preference. I usually use fakeroot (as a normal
user) to build a Debianized kernel package, and install said package as
root. In the end, the easiest way is to just logon as root and do it.
So your sitting in /usr/src/linux
Now what? Well, go with these two options.
make menuconfig or make xconfig
Use menuconfig to use the curses based kernel configuration. xconfig will
throw you into the xbased configuration, but if you don't have a good grasp
of how X works you probally want to stick with the curses based config.
(Some distributions prevent root from logging in via XDM/KDM/GDM.) Here
again the root/non-root arguement comes into play. Well, get your kernel
configured. In X, you will probally see a bunch of ? buttons leading to
"help." In the curses config, hit the ? key to bring up the help. Not all
paramaters are documented however.
So you've configured your kernel source. Time to compile. I belive the
correct sequence is make dep && make clean && make bzImage && make modules
&& make modules_install
This process compiles the C source code into a biniary kernel. This would be
the actual compilation process. The rest is configuration and installation.
I perfer to use Debian's make-kpkg. Again, this is my personal preference,
but it's kinda nice to lump all of the above into one command.
You should also backup your current kernel by moving it to a new location.
(mv /boot/vmlinuz-2.2.14 /boot/vmlinuz-2.2.14.old or something.) Usually the
/vmlinuz and /vmlinuz.old files are sym links to files under /boot. Lilo
usually references the /vmlinuz file however. (I perfer to reference
/boot/vmlinuz-version in lilo.conf and remove the /vmlinuz* sym links on /)
A basic lilo.conf entry may look something like this:
image=/boot/vmlinuz-2.2.18
label=2.2.18
(Perhaps you will have other options such as the root device. I don't, I
have stuff like that defined on a global basis instead of a per-kernel
basis.)
After editing and saving lilo.conf, run lilo as root. Now the moment of
truth is opon you. Will your system boot on the new kernel? Cross your
fingers and give your box the three fingure salute. (Do both at the same
time for bonus points.)
Well, hopefully that cleared some things up. Maybe it added to the
confusion. Maybe parts were just plain wrong. Feel free to add to the
discussion. :)
--
Andy Zbikowski, Sys Admin | (WEB) http://www.ltiflex.com
LTI Flexible Products, Inc. | (PH) 763-428-9119 (EX) 132
21801 Industrial Blvd | (FX) 763-428-9126
Rogers, MN 55374 | (PCS) 612-306-6055
-------------- next part --------------
A non-text attachment was scrubbed...
Name: andyzb.vcf
Type: text/x-vcard
Size: 367 bytes
Desc: Card for Andy Zbikowski
Url : http://shadowknight.real-time.com/pipermail/tclug-list/attachments/20010212/a05e6d78/andyzb.vcf