Linux Kernel Installation
Linux is many users' introduction to a truly powerful, configurable operating system. In the past, a Unix-like operating system was out of reach for most. If it wasn't the operating system's 4-digit price tag, it was the hardware. Even the now free-for-personal-use SCO Unixware requires a system with SCSI drives, and most of us are using IDE to keep costs down. Along with the power that Linux brings comes the need to perform a task users have not had to do on simpler operating systems: configure the kernel to your hardware and operations.
Previous installation kernels from 1.2.x and before suggested that you rebuild; however, with the new 2.0.x kernel, rebuilding has almost become a necessity. The kernel that comes with the installation packages from Red Hat, Caldera, Debian and most others, is a generic, “almost everything is included” kernel. While rebuilding a kernel may seem like a daunting task and living with the installed kernel may not be too bad, rebuilding is a good introduction to your system.
The standard installation kernels are an attempt to make as many systems as possible usable for the task of installing a workable Linux system. As such, the kernel is bloated and has a lot of unnecessary code in it for the average machine. It also does not have some code a lot of users want.
Then, of course, there's always the need to upgrade the kernel because you've bought new hardware, etc. Upgrading within a series is usually very straightforward. When it comes to upgrading, say from 1.2.something to 2.0.something, now the task is beyond the scope of this article and requires some savvy. Better to get a new distribution CD and start fresh—this is also true for upgrading to the experimental 2.1.x kernels.
All Linux kernel version numbers contain three numbers separated by periods (dots). The first number is the kernel version. We are now on the third kernel version, 2. Some of you may be running a version 1 kernel, and I am aware of at least one running version 0 kernel.
The second number is the kernel major number. Major numbers which are even numbers (0 is considered an even number) are said to be stable. That is, these kernels should not have any crippling bugs, as they have been fairly heavily tested. While some contain small bugs, they can usually be upgraded for hardware compatibility or to armor the kernel against system crackers. For example, kernel 2.0.30, shunned by some in favor of 2.0.29 because of reported bugs, contains several patches including one to protect against SYN denial of service attacks. The kernels with odd major numbers are developmental kernels. These have not been tested and often as not will break any software packages you may be running. Occasionally, one works well enough that it will be adopted by users needing the latest and greatest support before the next stable release. This is the exception rather than the rule, and it requires substantial changes to a system.
The last number is the minor number and is increased by one for each release. If you see kernel version 2.0.8, you know it's a kernel 2.0, stable kernel, and it is the ninth release (we begin counting with 0).
I hate to make any assumptions; they always seem to come back to bite me. So I need to mention a few things so that we're working off the same sheet of music. In order to compile a kernel, you'll need a few things. First, I'll assume you've installed a distribution with a 2.0.x kernel, all the base packages and perhaps a few more. You'll also need to have installed gcc version 2.7 and all the supporting gcc libraries. You'll also need the libc-dev library and the binutils and bin86 packages (normally installed as part of a standard distribution install). If you download the source or copy it from a CD, you'll also need the tar and gunzip packages. Also, you'll need lots of disk real estate. Plan on 7MB to download, another 20MB to unpack this monster and a few more to compile it.
Needless to say, many of the things we will discuss require you to be logged in as root. If you've downloaded the kernel as a non-privileged user and you have write permission to the /usr/src subdirectory, you can still do much of this task without becoming root. For the newcomers to Linux, I highly recommend you do as much as possible as a non-privileged user and become root (type: su - face) only for those jobs that require it. One day, you'll be glad you acquired this habit. Remember, there are two kinds of systems administrators, those who have totally wrecked a running setup inadvertently while logged in as root, and those who will.
Free DevOps eBooks, Videos, and more!
Regardless of where you are in your DevOps process, Linux Journal can help!
We offer here the DEFINITIVE DevOps for Dummies, a mobile Application Development Primer, and advice & help from the expert sources like:
- Linux Journal
- New Products
- Flexible Access Control with Squid Proxy
- Users, Permissions and Multitenant Sites
- Security in Three Ds: Detect, Decide and Deny
- High-Availability Storage with HA-LVM
- Tighten Up SSH
- DevOps: Everything You Need to Know
- Solving ODEs on Linux
- Non-Linux FOSS: MenuMeters
- diff -u: What's New in Kernel Development