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!
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script
- Google's SwiftShader Released
- Rogue Wave Software's Zend Server
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide