The recently released Linux 2.6 kernel is going to be the heart of future enterprise Linux offerings. Taking it...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
on a road test enables your IT shop to evaluate its hardware and software upgrade and replacement policies as well as its claims of improved peripheral connectivity.
A real-life test is a better idea than committing to an enterprise solution based on the ticks stated on a shrink-wrapped packet. As a technology buyer, you need to be informed. This column explains how you can test 2.6 without having to commit to a full install or destroying the test box you put to the task.
Take a deep breath, we're off into kernel compile land.
If you've never done this before, then don't worry, it's a highly-automated process, no programming required. The tricky part is traditional IT -- namely managing a few dependencies and having the right tools in place. The goal is to produce a running kernel without disturbing the rest of the test box much.
For this test any old Linux box will do; but there's special reference here to Red Hat, since it's both common and different. You do need a box that uses the GRUB boot loader; that's different to LILO. If you have a /boot/grub directory, then you have grub. You'll also need an Internet connection, several Gb of free disk space and something else to do while lengthy processes complete.
The first step is to grab the downloads. Only a few downloads are required. These few downloads are source code downloads -- the latest official releases available at this time. Don't grab any experimental versions. Here is a brief list of the most important items to grab:
- Linux kernel 2.6.4
- GCC Compiler Tools 3.3.3 (mirrors noted on gcc.gnu.org)
- procps 3.2.1 (procps.sourceforge.net)
Here we're not trying to build a whole distribution; we just want a quick test. In the Linux kernel source distribution, the file Documentation/Changes describes every minimum version you ought to have. We don't follow that advice, which is naughty. We just go ahead anyway. It's a fairly safe tactic, but you ought to make sure the box isn't a critical one. Don't use a box that programmers rely on for software development either. You can add 'e2fsprogs' and 'binutils' to the list of downloads if you're feeling cautious. You could even ignore 'procps' if you wish, but that's not recommended here.
The big, big problem with this process is the compiler. The GCC compiler has to be reasonably modern. The ones Red Hat supply (usually 2.96) are different and old. Documentation on exactly which minor version is needed isn't correct, either. You can waste a lot of time chasing that documentation. Take my word for it.
So firstly you need a new compiler. The latest at this time, GCC 3.3.3, is advertised on the gcc.gnu.org website, but it isn't available for download from there. You have to go to one of the mirror sites to find it. I live Down Under, so for me that's the first mirror link: mirror.aarnet.edu.au. Any mirror will do, though. The GNU people must have a big download bill to manage, otherwise the download would be directly available.
When we construct this new compiler (using the one that comes with your existing Linux installation), it'll go under /usr/local/bin. The existing one in /usr/bin won't be removed or damaged, but it's a bad idea to do this on a box that sees heavy use for software development, as standard headers are affected. Also note that gcc and cc are the same thing on most Linux installations. To get the new compiler, move to an empty directory and run these shell commands:
tar --bzip2 -xvf gcc-3.3.3.tar.bz2
./configure && make && make install
Now, go get several coffees.
When that's all done, the new compiler is installed. If you get any errors, you must have a very old version of Linux to start with; this all worked with a box that had the now-ancient Red Hat 7.2.
Next, you can repeat these steps for any other updates that you think are important, like 'procps' (recommended -- so do this), or the other tools documented in the Changes file noted earlier. But as we'll see, you don't strictly need to do those tools.
Now it's time to make the kernel. This needs to be done away from the root environment -- you should compile it as a normal user. To pick up the new compiler and make the kernel with it, here are the steps, which assume a bash or ksh shell:
tar --bzip2 -xvf linux-2.6.4.tar.bz2
Several more coffees are then required -- it's hard work.
The "export" commands pick up the new compiler and its libraries. The "make gconfig" command (you can alternately use "make config") configures the kernel-to-be using a tree-style interface. In my case, all the default looked fine, except that I tweaked the option under "Processor Type and Features" and "Processor Family" to pick up the el-cheapo AMD Duron chipset I happened to be using. I had to click several times for no apparent reason; if only this GUI was build using my favorite technology -- Mozilla. Oh well. I also saved the changes. It's all pretty automatic, really.
Finally, we want to put the new kernel in place without ruining the utility of the box. Note that we didn't mess around with modules at all in this case, so we don't expect support for video capture cards or other non-standard specials. Copy the kernel to the boot area:
cp arch/i386/boot/bzImage /boot/bzImage-2.6.4
Permissions aren't important since the kernel runs on the bare metal, not within an operating system. The final change required is to grub. We change the box from supporting a single operating system to being a dual-boot box. Here's a new /boot/grub/grub.conf file:
title Linux - RH 7.2 (2.4.7-10)
kernel /vmlinuz-2.4.7-10 ro root=/dev/hda2
title Linux - 2.6 www.kernel.org (2.6.4) gcc 3.3.3
kernel /bzImage-2.6.4 ro root=/dev/hda2
It's the same as the original file with the first two and last three lines added. Using this configuration, the box will boot up to a menu. If no response is had from the user within five seconds, the existing, Red Hat 7.2 will be booted -- no change. If the user picks the second menu option, then our new kernel will be used. So, you need to have a console display and mouse/keyboard plugged into the box. The new kernel will use all the files and filesystems from the existing install, from /etc/password to /bin/ls. We've effectively bolted a new kernel onto the current install. Don't extensively re-configure the box under the new kernel, though.
Before booting, copy the output of the 'dmesg' command to a temporary file. Since the kernel is mostly concerned with hardware, it's the hardware detection process that we're most interested in. Reboot, and when (whew) the box is up, copy the new output of 'dmesg' to a second temporary file. If there's a disaster, just reboot with the old kernel - no sweat. From here on in, it's all about the hardware you have at hand.
I use a handy little tool called tkdiff; it allows comparison of two files side to side with changes marked. It's perfect for the dmesg outputs. For my test, the 2.6 kernel rated my CPU 0.138 MHz faster than 2.4 did. It gave me 13.6 Mb of additional user memory. It spoke extensively about USB detection - all new. Best of all, it was entirely silent about IRQs. I've hated IRQ issues since Windows was naught but a gleam in Bill Gates' eye. I'm glad that the kernel has swallowed that issue for me. If only they'd disappear from the BIOS as well.
Using the command 'ps -eH', it's clear that internally the kernel processes have changed a bit. I'm super-happy no IRQ listeners are listed there anymore, either. My mouse is a new one, so it's USB. Under the new kernel I can throw away the PS/2 adaptor that came with it and just plug it in directly. But I have to put it back if I reboot under 2.4.
Under the new kernel, you can run whatever applications you like and attempt to measure the improvement -- not easy to see except for in a highly-threaded or highly parallel processing environment. If you have many, many dumb terminal users, though, then a user response time improvement might be noticeable.
In any event, compiling and testing the kernel yourself is a very empowering project to undertake. It make the difference between Windows and Linux crystal clear to anyone with an ounce of technical know-how. It also goes a long way to demystifying enterprise Linux brand strategies.
The kernel isn't sacred; you can mess with it just as you can with any piece of software. For production changes, a bit more care than is used here is definitely required!