- Version 2.4 of the LINUX KERNEL--Why Should a System Administrator Upgrade?
- Processor/Motherboard Support
- Networking Stack Enhancements
- Disk Subsystem Enhancements
- Notes on Upgrading to the 2.4 Kernel
I hope that by this point you're itching to give the 2.4 kernel a whirl on a test system. (If you're not, check your pulse and make sure that you're still breathing!) Building the 2.4 kernel is not much different than in the 2.0 and 2.2 days, but you need to be aware of a few things before you start:
The 2.4 kernel is BIG. The source archive is 19MB when compressed with bzip2, or 23.5MB with normal gzip compression. (It probably won't be long before we'll see architecture-specific tarballs.) Once you get the kernel extracted and built, you'll have used almost 140MB of disk space. Obviously, kernel builds take longer. Most folks have larger hard drives and faster processors, so many won't notice, but for smaller and/or slower systems, consider configuring the kernel for your target, but compiling on a beefier system.
Modules are installed into a different directory hierarchy underneath /lib/modules/$kernel_version. The change isn't drastic, but it's enough that you'll need to run the latest version of the modutils package; if you explicitly path out modules when loading them in scripts, you'll need to fix that too. (I'm running modutils version 2.3.19 with my 2.4 kernel. Don't worry; it still works with the 2.2 kernel.)
You'll need to have gcc version 2.9.5 installed; some older systems may have 2.7.2 (which builds 2.2 kernels just fine).
There are so many options now that if you're used to using make config to configure your kernel, you'll probably want to try either make menuconfig or make xconfig to more easily navigate the choices. These notes are obviously just a few hints. Follow the steps outlined either by your distribution or the Kernel-HOWTO if you need help. Keep in mind that if you're not familiar with the process, you end up with a system that will no longer boot directly from your boot loader. For this reason, you may want to test your 2.4 kernels by placing them on a floppy disk for platforms that support this. (Use the make bzdisk target on Intel platforms.) On the other hand, don't be paranoid about destroying your system. Even if you do generate a bad kernel, you can use a rescue floppy or installation CD to boot your system to the point where you can generate another kernel and try again.
As a system administrator, your primary foe is Murphy's Law (entropy in general, if you ask me), and your next-worse enemy is lack of knowledge or misinformation. Entropy is number one because, even when you're armed with all the right information, you'll still be fighting failed drives, power surges, and sunspots. I have often opted to stick with what I had working in production, resisting the temptation to deploy the "latest and greatest" version of foo because of the risk involved. However, the 2.4 kernel is simply too good to ignore. The new networking features make it a must for any router or firewall installation, and the device support justifies the effort to upgrade for desktop users. I heartily recommend that you go ahead and get acquainted with it; it's stable enough for serious testing, and knowing the feature set will help you plan your Linux strategy. Plus, you'll be ahead of the game when 2.4.1 is finally releasedhopefully any day now