Linux Performance Tuning for the Faint of Heart
'Kernel profiling support' CONFIG_PROFILE :
This is used only by seasoned kernel hackers. You don't need this if you need to read this article...
'Selection (cut and paste for virtual consoles)' :
Self explanatory. If you want to be able to use your mouse in any of your VC's, then you would select YES. Note that this requires a separate selection program to work. Your mouse will be inactive without this program. This has nothing to do with X-windows.
The last section of the configuration process that needs insight has to do with sound card options. If you want sound card support, then you would definitely select YES. The confusing part are the next two questions; confusing because of the order they fall in.
Full driver? NO. I select NO because I want to configure my kernel to handle only my particular sound card. I don't want to enable drivers for cards I don't have. This simply wastes space.
Immediately following is: Disable? NO. It seemed strange to me that the driver question would come before a question about disabling the sound drivers altogether. Nonetheless, you should select NO, and answer the questions that follow accordingly, depending on what hardware you have.
That was the last part of the configuration process. All that remains is to make the system dependencies. After that, the actual kernel compile!
There isn't any confusing part about making the dependencies. All you do is type make depend (in the /usr/src/linux directory, which you should already be in); this sets up the system dependencies that all the files have. This allows make to intelligently recompile only the right files if you have to make changes to the source code.
After the system dependencies have been created, you are ready to compile the newly configured kernel. At this point, you should type make zImage to create a compressed kernel. This helps in the process of keeping your kernel small. Depending on the speed of your machine, the amount of memory you have, and how many things you are compiling into your kernel, your compile could take anywhere from around 15 minutes on a fast 486 or Pentium to several hours on a slow 386sx with 4MB of memory.
When the compiling process is complete, you will find a newly created kernel, zImage, in the /usr/src/linux directory. The process of installing the new kernel however is not yet complete. If you reboot right now, even though you have compiled a new kernel, you will still boot your old kernel. You still need to install the new kernel.
Before you install the new kernel, you should rename your old kernel, so that you can use it in the case of an emergency. In the / directory, there should be an image of your old kernel (zImage). Simply rename it to zImage.old using the mv command. This will be useful in the event that your new kernel will not boot up; you at least have a backup that still allows for a functional system.
Now, you must edit (if necessary) the LILO configuration file, so that it will accept your new kernel. It is most often found in the file /etc/lilo/config, but may be found as /etc/lilo.conf. Basically, editing the configuration file and running lilo tells the LILO which kernel to use upon bootup. The first image to be set up in the config file will be the default. By putting the new kernel image first, we will ensure that the new kernel boots by default; if we were to put the DOS entry first, DOS would boot by default. Here's an example:
boot = /dev/hda
#This is the path to the NEW kernel image to be bootedimage = /zImagelabel = linux
#This is the path to the OLD kernel image to be booted#if the other should fail to bootimage = /zImage.oldlabel = linux.old
#This is the path to the DOS operating systemother = /dev/hda1table = /dev/hdalabel = dos
Once you've edited the configuration file, copy or move the new kernel image to the / directory. Make sure that /zImage and /zImage.old are present before going any further. Next, you need to go back into the /etc/lilo directory and type ./lilo to run lilo. Alternately (if /etc/lilo doesn't exit), you may need to cd to /etc and run /sbin/lilo. In either case, this is the “installation” step which makes it possible for you to boot your new kernel.
You are now ready to boot your new kernel. To do this, type shutdown -r now.
If you have not installed your new kernel as the default kernel by making it the first entry in /etc/lilo/config, you will need to manually select your new kernel as you boot up. You activate the LILO menu by pressing <shift>, <control>, or <alt keys> as LILO is starting, or by pressing the <CapsLock> or <ScrollLock> key before LILO starts.
At the LILO prompt, make sure you type the label of the image, and not the filename of the image. If LILO can't find the image you ask for, it will tell you. Typing ? will give you a list of labels to choose from.
During the boot process, be sure to look at the information that relates the version of the kernel being booted, and the day that it was compiled (it's all on the same line). Mine looks like this:
Linux version 1.0.9 (root@HoMiEz.ShOpPiN.NeT) Thu Jul 14 22:45:16 1994
This particular line tells which version of the kernel is being booted, and the date and time that it was last compiled. The information shown here should coincide with the compile process you just recently completed. If there is an inconsistency, be sure to check your /etc/lilo/config file. Make sure that you put the proper label name for the particular table on the hard drive.
Once the new kernel is booted, you are free to hack away. Kernel compiling can be a confusing process. Some new administrators are intimidated by compiling a new kernel, but it is a prerequisite to running an optimized system. After a few kernel upgrades, you can become skilled in maintaining your system optimally. Then you can pass that knowledge to those who are as unsure as you once were. Remember, the more you know about your own system, the more optimized you become in using it.
Before you unpack the kernel source, it is a good idea first to backup you old kernel. You should do this, just for the moment, until you completely get the new kernel functioning properly. You can even shrink the size of the old kernel source by using tar and then compressing it. It is better to use both, as a double strength method:
cd /usr/srctar cvf linux-old.tar linuxgzip -9 linux-old.tar
The resulting file should be linux-old.tar.gz. After you've done this, it is safe to remove the old source directory by typing:
rm -rf linux
After you've done this, you can uncompress the new kernel. You must first move the new kernel source to /usr/src. Then type the following:
gunzip -c new-kernel-name.gz | tar xvof -
Once this process is complete, you are ready to move on. I'd also suggest keeping the new compressed kernel source in a backup directory. This way, if an error occurs in the process of upgrading and compiling your new kernel, you always have un-patched, “virgin” source to start over with. This eliminates the time it takes to download the kernel source again and also leaves you more time to concentrate on the task at hand.
Webinar: 8 Signs You’re Beyond Cron
11am CDT, April 29th
Join Linux Journal and Pat Cameron, Director of Automation Technology at HelpSystems, as they discuss the eight primary advantages of moving beyond cron job scheduling. In this webinar, you’ll learn about integrating cron with an enterprise scheduler.Join us!
|Android Candy: Intercoms||Apr 23, 2015|
|"No Reboot" Kernel Patching - And Why You Should Care||Apr 22, 2015|
|Return of the Mac||Apr 20, 2015|
|DevOps: Better Than the Sum of Its Parts||Apr 20, 2015|
|Play for Me, Jarvis||Apr 16, 2015|
|Drupageddon: SQL Injection, Database Abstraction and Hundreds of Thousands of Web Sites||Apr 15, 2015|
- Tips for Optimizing Linux Memory Usage
- "No Reboot" Kernel Patching - And Why You Should Care
- Return of the Mac
- DevOps: Better Than the Sum of Its Parts
- Drupageddon: SQL Injection, Database Abstraction and Hundreds of Thousands of Web Sites
- Android Candy: Intercoms
- Non-Linux FOSS: .NET?
- New GeekGuide: Beyond Cron
- Consent That Goes Both Ways