Smell of Fresh-Baked Kernels
Mon Dieu! François! Come out from under that table immédiatement! You are very lucky that our customers have not yet arrived. To see you hiding from the prospect of a kernel recompile. Qu'est-ce que je vai faire avec toi? Sit down and let me pour you a glass of wine to steady your nerves. There. Feeling better? Bien.
Log in and let me show you how easy it is. You know, François, that I have been collecting from other open-source chefs some wonderful recipes designed to make this whole kernel process that much more attractive to the palate, non? Quoi? Ah, mes amis. Welcome! François, what are you doing sitting there drinking? Show our guests to their seats. When you are done, bring up the 1996 Meursault Genevrieres from the cellar.
Pardon, mes amis. François and I were discussing the intricacies of Linux kernel builds. My faithful waiter was about to build his first kernel and, I must tell you, he is a little shy about the idea. It is for François and others like him that I have sought out some of the items on tonight's menu.
Building a kernel is not as much of an ordeal as it once was. Part of the reason, I must admit, is that the need to recompile your kernel is becoming less and less of a requirement for the average user. Out of the box, most modern distributions include support for more popular devices either in the kernel or through a collection of compile loadable modules. Still, there are times when the distributed kernel will not support your hardware. You may also need specific features that, while uncommon, are required in your environment.
This generally implies a requirement for the latest and greatest Linux has to offer. If you want to know what the latest version of the Linux kernel is, whether it is a stable release or a development version, try out the following finger command:
A few seconds later, the system responds with something like this:
[zeus.kernel.org] The latest stable version of the Linux kernel is: 2.2.17 The latest beta version of the Linux kernel is: 2.4.0-test10 The latest prepatch (alpha) version *appears* to be: 2.4.0-test11/pre5This assumes, of course, that you are currently connected to the Internet. I see that one of our diners is putting up their hands and mouthing the word always. Bravo, mon ami.
Armed with the latest kernel information, you can now visit your favorite kernel source mirrors and download what you need. Notice that I said mirrors. Getting to your local mirror is pretty simple. All you have to do is squeeze your country code in between the “ftp” or “www” of kernel.org. For instance, assume for a moment that I am in Canada (country code “ca”). The addresses for the ftp and www sites would be as follows:
Similarly, if I were in France, I would use these mirrors:
ftp.fr.kernel.org www.fr.kernel.orgIf you are unsure about any of these codes, visit www.kernel.org/pub/mirrors for a complete list.
Staying on top of all this can be a chore as well. You may have to follow kernel development quite closely (perhaps daily). Pretend for a moment that you have a new card that lets you input commands directly into your system via thought transmissions (Incroyable!) and kernel support is currently in development. Whatever your reasons, Darxus provides you with a nice little Perl script to help you out. It is called dlkern and is available from his web site (see Resources). With dlkern, you simply tell the script whether you want the stable version of the kernel (-s option), the development or beta version (-b option), or the pre-patch alpha version (-p option). That is all. Allow me to demonstrate. In the next example, I retrieve the latest stable kernel:
./dlkern -s -w
You'll notice that I used a -w option as well. This tells dlkern to use wget as the means of downloading my new kernel. The default is ncftpget. One or both of these programs is likely already on your system or included in your distribution. One quick note here; make sure you change the permissions on the script to executable (chmod 755 dlkern[). If you are indeed following the development of a specific driver, one option is to put dlkern into a crontab entry where the download can happen automatically (during the night or whenever makes sense).
So, now we have chosen and downloaded our kernel source distribution. The next step, of course, is to build the kernel. I realize that there are many documents explaining the steps to kernel compilations (other writers in this fine publication have and will, no doubt, cover it in the future). Nevertheless, to truly appreciate the work of our next chef, we should review the process briefly.
With source in hand, it is time to uncompress and extract that source. The usual and preferred location tends to be /usr/src. Kernels direct from any of the kernel.org mirrors tend to extract into a hierarchy called “Linux”. This would mean that your kernel sources lived in /usr/src/linux. However, you may find that /usr/src/linux is actually a symbolic link to where the actual kernel source lives. For instance, if I do an ls -l on one of my servers, I get something that looks like this:
# cd /usr/src # ls -l linux lrwxrwxrwx 1 1 root 11 Nov 14 1999 linux -> linux-2.2.5
Notice that it points to a directory called “linux-2.2.5”. If you want to extract directly from the source, start by renaming the link to something else, then extract the kernel. The tree will be called “Linux”. Now, change directory to the linux directory and type make config. Even before you type that command, I should tell you that this is the old, one might even say, classic, way of doing things. You will get a line-by-line question and answer session designed to help you through the configuration process for your new kernel. If you type make menuconfig, you will get a ncurses-based screen that is a bit friendlier, what you might call a GUI for the console set, non? The last option is make xconfig, which uses an X environment for building.
As I mentioned, this is the question and answer session. You decide what you want in your kernel by answering “Y” for yes, “N” for no and “M” for module. At any point in the process, you can ask for help if you don't know what a specific thing does. The kernel make process is pretty good at leading and helping out through this. If it tells you that you should include it, then do so.
Once this is done, you can actually go back and make some modifications if you want to double-check. In the /usr/src/linux directory, you will find a file called .config. Using pico, vi or whatever editor makes you happy, you can still make changes. Listing 1 is a sample of the .config file from a recent build.
The next step is to do a make depend (which handles all the dependencies and creates your Makefiles), followed by a make clean. If this is your first build, you will see messages claiming to be cleaning up and deleting files that aren't really there. Now, it's time to actually compile your kernel. You do this by executing make bzImage. This next step may take a while, depending on how fast your computer is, so consider sitting down with a nice Beaujolais while you wait. When all is done, you'll find your new kernel in the directory /usr/src/linux/arch/i386/boot. It is, as you might expect, called bzImage since that is what we told the system to make, non? Now, you want to include your new kernel image in LILO's list of bootable kernels. For this example, I built the 2.2.17 kernel directly from source. Once that was done, I used my vi editor to modify my /etc/lilo.conf file. Listing 2 shows what it looked like before I started.
You'll notice that I did not change anything else in this example. My default boot is still vmlinuz-2.2.14-5.0, which is the stock kernel that came with my system. The lines that start with image=/boot/vmlinuz-2.2.17 are the ones I added after the fact. I am now going to have my Linux system reread the configuration file by running this command:
After LILO has worked its way through your /etc/lilo.conf file, it should come back with something like this:
Added linux * Added linux-2.2.17Here is a quick tip from the kitchen, mes amis. From time to time, I have been known to say that too much garlic in a Caesar salad is impossible. I joke, but you understand, non? I tell you this so that you will better understand the following statement.
You can never run /sbin/lilo too many times, but you can run it too few. If you have made changes to your kernel or your /etc/lilo.conf file and you forget to run /sbin/lilo, your system will not boot. This is extremely important. If you are not sure whether you have run LILO, then run it again. Sometimes, I run it two or three times just to make sure. I joke, but only a bit, non?
We have only a couple of things left to do. Since you have, no doubt, defined several modules to include with your new kernel, you need to make them as well. You do this with the make modules command which you then follow up with make modules_install.
There you have it. All in all, it's not that the whole process is so complicated. It's just that there are quite a few things to remember, and forgetting that all-important LILO step can cost you a great deal of aggravation (not to mention that it could put a real dent in your wine cellar).
No matter what, building a kernel, for many (including François), is a daunting experience. This is where buildkernel comes into play. Written by William Stearns, this is a wonderful little (big) bourne shell script that pretty much automates the entire process. If you have local kernel source, it will use that, otherwise, buildkernel will download the latest stable kernel for you. You can, if you wish, ask the software to get the latest development version instead. It then extracts it, creates the appropriate links and starts the configuration process by launching make xconfig. Once you have decided what you want, your job is pretty much done.
Sometime after building the kernel modules, buildkernel will interrupt you and ask you to verify its changes to /etc/lilo.conf. It does this by putting you into your default editor and allowing you to make changes. Here's what it looks like at this point. This is not the whole file, but simply the changes added by buildkernel:
#The following boot section was added by #buildkernel on Wed Nov 8 13:06:21 EST 2000 #Please feel free to move this section, edit it #and remove these comments. image=/boot/bzImage-2.2.17-1 label=2.2.17-1 root=/dev/hda1 read-only #End of autoinstall
Once you are happy with this, exit the editor and let the program continue. It will complete the installation of your new kernel, run LILO and that will be that. No need to worry about whether you forgot some steps. Oui, it is true. Despite my assurances that I personally watched as buildkernel ran LILO, I still ran it again.
When you look at the resultant /etc/lilo.conf file, notice that the default boot configuration is your old kernel—buildkernel has left that intact. Merci. Now, to book your new kernel, simply shut down your system and type (in the case of my example above) 2.2.17-1 at the LILO prompt.
There are some parameters that you may be wise to pre-set. These are in a control (or config) file called /etc/bkrc, and they allow you to select defaults such as your local mirror download site (BKFTPSITE), the type of image (BKBUILDTYPE), or whether you want to use the stable or development kernels (BKKERNELTOBUILD).
It seems that closing time has arrived very quickly. Mon Dieu! Once again, I want to thank you all for visiting my restaurant. François, please, another glass of wine for our friends. As you can see, working with the Linux kernel need not be a frightening experience. With a little help from dedicated open-source chefs around the world, anybody can sample the Linux kernel up close and personal. Even François.
Until next time, your table will always be waiting here at Chez Marcel.
Â vôtre santé! Bon appétit!
Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report
August 27, 2015
12:00 PM CDT
DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.
Free to Linux Journal readers.Register Now!
- Hacking a Safe with Bash
- Django Models and Migrations
- Secure Server Deployments in Hostile Territory, Part II
- The Controversy Behind Canonical's Intellectual Property Policy
- Home Automation with Raspberry Pi
- Huge Package Overhaul for Debian and Ubuntu
- Shashlik - a Tasty New Android Simulator
- Embed Linux in Monitoring and Control Systems
- KDE Reveals Plasma Mobile
- diff -u: What's New in Kernel Development