Linux Kernel Installation
Kernel sources for Linux are available from a large number of ftp sites and on almost every Linux distribution CD-ROM. For starters, you can go to ftp.funet.fi, the primary site for the Linux kernel. This site has a list of mirror sites from which you can download the kernel. Choosing the site nearest you helps decrease overall Internet traffic.
Once you've obtained the source, put it in the /usr/src directory. Create a subdirectory to hold the source files once they are unpacked using tar. I recommend naming the directories something like linux-2.0.30 or kernel-2.0.30, substituting your version numbers. Create a link to this subdirectory called linux using the following command:
ln -sf linux-2.0.30 linux
I included the -f in the link command because if you already have a kernel source in /usr/src, it will contain this link too, and we want to force it to look in our subdirectory.1 The only time you may have a problem is if linux is a subdirectory name, not a link. If you have this problem, you'll have to rename the subdirectory before continuing:
mv linux linux-2.0.8Now issue the command:
tar xzvf linux-kernel-source.tar.gzI have a habit of always including w (wait for confirmation) in the tar option string, then when I see that the .tar.gz or .tgz file is going to unpack into its own subdirectory, I ctrl-C out and reissue the command without the w. This way I can prevent corrupted archives from unpacking into the current directory.
On some versions of ln (notably version 3.13), the force option (-f) does not work. You'll have to first remove the link then establish it again. This works correctly by version 3.16.
Once you have the kernel unpacked, if you have any patches you wish to apply, now is a good time. Let's say you don't wish to run kernel 2.0.30, but you do want the tcp-syn-cookies. Copy the patch (called tcp-syn-cookies-patch-1) into the /usr/src directory and issue the command:
patch < tcp-syn-cookies-patch-1
This command applies the patch to the kernel. Look for files with an .rej extension in in the /usr/src directory. These files didn't patch properly. They may be unimportant, but peruse them anyway. If you installed a Red Hat system with some but not all of the kernel source (SPARC, PowerPC, etc.), you'll see some of these files. As long as they're not for your architecture, you're okay.
As a final note, before we change (cd) into the kernel source directory and start building our new kernel, let's check some links that are needed. In your /usr/include directory, make sure you have the following soft links:
asm - /usr/src/linux/include/asm linux - /usr/src/linux/include/linux scsi - /usr/src/linux/include/scsi
Now, you see another reason to standardize the location of the kernel. If you don't put the latest kernel you wish to install in /usr/src/linux (via a link), the above links will not reach their intended target (dangling links), and the kernel may fail to compile.
Once everything else is set up, change directories into /usr/src/linux. Although you may want to stop off and peruse some of the documentation in the Documentation directory, particularly if you have any special hardware needs. Also, several of the CD-ROM drivers need to be built with customized settings. While they usually work as is, these drivers may give warning messages when loaded. If this doesn't bother you and they work as they should, don't worry. Otherwise, read the appropriate .txt, .h (header) files and .c (c code) files. For the most part, I have found them to be well commented and easy to configure. If you don't feel brave, you don't have to do it. Just remember you can always restore the original file by unpacking the gzipped tar file (or reinstalling the .rpm files) again.
The first command I recommend you issue is:
While this command is not necessary when the kernel source is in pristine condition, it is a good habit to cultivate. This command ensures that old object files are not littering the source tree and are not used or in the way.
Now, you're ready to configure the kernel. Before starting, you'll need to understand a little about modules. Think of a module as something you can plug into the kernel for a special purpose. If you have a small network at home and sometimes want to use it (but not always), maybe you'll want to compile your Ethernet card as a module. To use the module, the machine must be running and have access to the /lib/modules This means that the drive (IDE, SCSI, etc., but could be an ethernet card in the case of nfs), the file system (normally ext2 but could be nfs) and the kernel type (hopefully elf) must be compiled in and cannot be modules. Modules aren't available until the kernel is loaded, the drive (or network) accessed, and the file system mounted. These files must be compiled into the kernel or it will not be able to mount the root partition. If you're mounting the root partition over the network, you'll need the network file system module, and your Ethernet card compiled.
Why use modules? Modules make the kernel smaller. This reduces the amount of protected space never given up by the kernel. Modules load and unload and that memory can be reallocated. If you use a module more than about 90% of the time the machine is up, compile it. Using a module in this case can be wasteful of memory, because while the module takes up the same amount of memory as if it were compiled, the kernel needs a little more code to have a hook for the module. Remember, the kernel runs in protected space, but the modules don't. That said, I don't often follow my own advice. I compile in: ext2, IDE and elf support only. While I use an Ethernet card almost all the time, I compile everything else as modules: a.out, java, floppy, iso9660, msdos, minix, vfat, smb, nfs, smc-ultra (Ethernet card), serial, printer, sound, ppp, etc. Many of these only run for a few minutes at a time here and there.
The next step is to configure the kernel. Here we have three choices—while all do the same thing, I recommend using one of the graphical methods. The old way was to simply type: make config. This begins a long series of questions. However, if you make a mistake, your only option is to press ctrl-C and begin again. You also can't go back in the sequence, and some questions depend on previous answers. If for some reason you absolutely can't use either of the graphical methods, be my guest.
I recommend using either make menuconfig or make xconfig. In order to use menuconfig, you must have installed the ncurses-dev and the tk4-dev libraries. If you didn't install them and you don't want to use the next method, I highly recommend that you install them now. You can always uninstall them later.
To run make xconfig, you must install and configure X. Since X is such a memory hog, I install, configure and startx only for this portion of the process, going back to a console while the kernel compiles so it can have all the memory it needs. The xconfig menu is, in my opinion, the best and easiest way to configure the kernel. Under menuconfig, if you disable an option, any subordinate options are not shown. Under xconfig, if you disable an option, subordinate options still show, they are just greyed out. I like this because I can see what's been added since the last kernel. I may want to enable an option to get one of the new sub-options in order to to experiment with it.
I'm going to take some space here to describe the sections in the kernel configuration and tell you some of the things I've discovered—mostly the hard way.
The first section is the code-maturity-level option. The only question is whether you want to use developmental drivers and code. You may not have a choice if you have some bleeding edge hardware. If you choose “no”, the experimental code is greyed out or not shown. If you use this kernel for commercial production purposes, you'll probably want to choose “no”.
The second section concerns modules. If you want modules, choose “yes” for questions 1 and 3. If you want to use proprietary modules that come with certain distributions, such as Caldera's OpenLinux for their Netware support, also answer “yes” to the second question since you won't be able to recompile the module.
The third section is general setup. Do compile the kernel as ELF and compile support for ELF binaries. Not compiling the proper support is a definite “gotcha”. You'll get more efficient code compiling the kernel for the machine's specific architecture (Pentium or 486), but a 386 kernel will run in any 32-bit Intel compatible clone; a Pentium kernel won't. An emergency boot disk for a large number of computers (as well as distribution install disks) is best compiled as a 386. However, a 386 will not run a kernel compiled for a Pentium.
Next comes block devices—nothing special here. If your root device is on an IDE drive, just make sure you compile it.
Then comes networking. For computers not connected to a network, you won't need much here unless you plan to use one computer to dial-out while others connect through it. In this case, you'll need to read up on such things as masquerading and follow the suggested guidelines.
SCSI support is next, though why it doesn't directly follow block devices I don't know. If your root partition is on a SCSI device, don't choose modules for SCSI support.
SCSI low-level drivers follow general SCSI support. Again, modules only for devices that don't contain the root partition.
The next section takes us back to networking again. Expect to do a lot of looking for your particular card here as well as some other support such as ppp, slip, etc. If you use nfs to mount your root device, compile in Ethernet support.
For those lucky enough to be needing ISDN support, the ISDN subsection will need to be completed.
Older CD-ROMs may require support from the next section. If you're using a SCSI or IDE CD-ROM, you can skip this one.
Next comes file systems. Again, compile what you need, in most cases ext2 and use modules for the rest.
Character devices are chosen next. Non-serial mice, like the PS/2 mouse are supported. Look on the bottom of your mouse. Many two-button mice are PS/2 type, even though they look and connect like serial mice. You'll almost certainly want serial support (generic) as a minimum. Generic printer support is also listed here.
The penultimate section is often the most troubling: sound. Choose carefully from the list and read the available help. Make sure you've chosen the correct I/O base and IRQs for your card. The MPU I/O base for a SoundBlaster card is listed as 0. This is normally 330 and your sound module will complain if this value is incorrect. Don't worry. One of the nice things about modules is you can recompile and reinstall the modules as long as the kernel was compiled with the hook. (Aren't modules great?).
The final section contains one question that should probably be answered as “no, kernel hacking”.
Save your configuration and exit.
I have, on several occasions, had trouble editing the numbers in menuconfig or xconfig to values I knew were correct. For whatever reason, I couldn't change the number or config wouldn't accept the number, telling me it was invalid. For example, changing the SoundBlaster IRQ from the config default of 7 to 5, and the MPU base I/O from 0 to 300. If you experience this problem, but everything else went well, don't despair. The file you just wrote when you did a “Save” and “Exit” is an editable text file. You may use your text editor of choice: Emacs, vi, CrispLite, joe, etc. Your configuration file is in the /usr/src/linux directory and is called .config. The leading dot causes the file to be hidden during a normal directory listing (ls), but it shows up when the -a option is specified. Just edit the numbers in this file that you had trouble with in the configuration process. Next, type make dep to propagate your configurations from the .config file to the proper subdirectories and to complete the setup. Finally, type make clean to prepare for the final kernel build.
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
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- SuperTuxKart 0.9.2 Released
- Tech Tip: Really Simple HTTP Server with Python
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
- SourceClear Open
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