Linux Solutions

Welcome to the tutorial guide. The guide will provide a user with advise and guidance on how to find the version of the Kernels.

Please note that a common error is to try to insert an object file which is not an LKM. For example, you configure your kernel to have the USB core module bound into the base kernel instead of generated as an LKM. In that case, you end up with a file usbcore.o, which looks pretty much the same as the usbcore.o you would get if you built it as an LKM. But you can’t insmod that file.

You will see following error message:

$ insmod usbcore.o
usbcore.o: couldn’t find the kernel version this module was compiled for

The insmod is informing you that it looked in usbcore.o for a piece of information any legitimate LKM would have — the kernel version with which the LKM was intended to be used — and it didn’t find it.

If this is a module you created yourself with the intention of it being an LKM, but it is not an LK. This is because you did not include linux/module.h at the top of your source code and/or did not define the MODULE> macro. MODULE is intended to be set via the compile command (-DMODULE) and determine whether the compilation produces an LKM or an object file for binding into the base kernel. If your module is like most modern modules and can by built only as an LKM, then you should just define it in your source code (#define MODULE) before you include include/module.h.
On the other hand, if LKM Loads successfully and is verified that via /proc/modules. Now it is a good idea to find out if it is working or not. That’s up to the LKM, and varies according to what kind of LKM it is, but here are some of the more common actions of an LKM u
pon being loaded.

The first thing a device driver LKM does after loading is usually to search the system for a device it knows how to drive. Just how it does this search varies from one driver to the next, and can usually be controlled by module parameters. But in any case, if the driver doesn’t find any device it is capable of driving, it causes the load to fail.

Otherwise, the driver registers itself as the driver for a particular major number and you can start using the device it found via a device special file that specifies that major number. It may also register itself as the handler for the interrupt level that the device uses. It may also send setup commands to the device, so you may see lights blink or something like that.

You will see that a device driver has registered itself in the file /proc/devices. You can see that the device driver is handling the device’s interrupts in /proc/interrupts.
A nice device driver issues kernel messages telling what devices it found and is prepared to drive. A nice device driver will provide you with some of the details of its search when it fails to find a device, but many just fail the load without explanation, and what you get is a list of guesses from insmod as to what the problem might have been.
A network device (interface) driver works similarly, except that the LKM registers a device name of its choosing (e.g. eth0) rather than a major number. You can see the currently registered network device names in /proc/net/dev
A filesystem driver, upon loading, registers itself as the driver for a filesystem type of a certain name.

If you followed the advise and guidance as provided in this tutorial guide then you would have found out the version of the kernel.

Welcome to the tutorial guide. The guide will provide a user with advise and guidance on how to insert and remove LKMs.

Before we go ahead with the process of inserting and removing LKMs, please note that there are two basic programs for inserting and removing LKMs which are insmod and rmmod.

In order to insert an LKM, please type following command as provided below:

insmod serial.o
(Please note that the serial.o contains the device driver for serial ports (UARTs)).

Please note that this command might not work. Please note that in Linux 2.6, the technical aspects of loading LKMs are considerably different, and the most visible manifestation of this is that the LKM file has a suffix of “.ko” instead of “.o”. From the user point of view, it looks quite similar, though.

Another insertion that can be used is a little more difficult. It is as following:#
insmod msdos.o

There is a possibility that you will get a raft of error messages like following:
Msdos.o: unresolved symbol fat_date_unix2dos
msdos.o: unresolved symbol fat_add_cluster1
msdos.o: unresolved symbol fat_put_super
…

This is because msdos.o contains external symbol references to the symbols mentioned and there are no such symbols exported by the kernel. In order to prove this, let’s do following:

cat /proc/ksyms

This will list every symbol that is exported by the kernel. You will note that ‘fat_date_unix2dos’ is nowhere in the list.

By loading another LKM, one which defines those symbols and exports them. In this case, it is the LKM in the file fat.o. So do
insmod fat.o
and then see that “fat_date_unix2dos” is in /proc/ksyms. Now redo the
insmod msdos.o
and it works. Look at /proc/modules and see that both LKMs are loaded and one depends on the other:
msdos 5632 0 (unused)
fat 30400 0 [msdos]

If you would like to remove an LKM from the kernel, please use following command:

rmmod ne

Please note that there is a command lsmod which can list the currently loaded LKMs, but this command also dump the contents of /proc/modules, with column headings.

If you followed advise and guidance as provided in this tutorial guide then you would have learnt about the process of inserting and removing LKMs.

Welcome to the tutorial guide. The guide will present LKMs benefits and then will provide a user with instructions on how to make loadable kernel modules.

Before we start with the process of making loadable kernel modules, we will have a look at the benefits that LKMs can provide to a user.

- LKMs can save memory, because you have to have them loaded only when you’re actually using them. All parts of the base kernel stay loaded all the time. And in real storage, not just virtual storage.
- LKMs are much faster to maintain and debug. What would require a full reboot to do with a filesystem driver built into the kernel, you can do with a few quick commands with LKMs.
- LKMs are not slower, by the way, than base kernel modules. Calling either one is simply a branch to the memory location where it resides.

What LKMs Are Used ForThere are six main things LKMs are used for:
• Device drivers. A device driver is designed for a specific piece of hardware. The kernel uses it to communicate with that piece of hardware without having to know any details of how the hardware works.
• Filesystem drivers. A filesystem driver interprets the contents of a filesystem (which is typically the contents of a disk drive) as files and directories and such. There are lots of different ways of storing files and directories and such on disk drives, on network servers, and in other ways.
• System calls. User space programs use system calls to get services from the kernel. For example, there are system calls to read a file, to create a new process, and to shut down the system. Most system calls are integral to the system and very standard, so are always built into the base kernel (no LKM option). But you can invent a system call of your own and install it as an LKM. Or you can decide you don’t like the way Linux does something and override an existing system call with an LKM of your own.
• Network drivers. A network driver interprets a network protocol. It feeds and consumes data streams at various layers of the kernel’s networking function. For example, if you want an IPX link in your network, you would use the IPX driver.
• TTY line disciplines. These are essentially augmentations of device drivers for terminal devices.
• Executable interpreters. An executable interpreter loads and runs an executable. Linux is designed to be able to run executables in various formats, and each must have its own executable interpreter.

How to make loadable Kernel Modules
For the LKMs that are part of Linux, you build them as part of the same kernel build process that generates the base kernel image. See the README file in the Linux source tree. In short, after you make the base kernel image with a command such as make zImage, you will make all the LKMs with the command:
make modules

This results in a bunch of LKM object files (*.o) throughout the Linux source tree. (In older versions of Linux, there would be symbolic links in the modules directory of the Linux source tree pointing to all those LKM object files). These LKMs are ready to load, but you probably want to install them in some appropriate directory.

The command make modules_install will copy them all over to the conventional locations.
Part of configuring the Linux kernel (at build time) is choosing which parts of the kernel to bind into the base kernel and which parts to generate as separate LKMs. In the basic question-and-answer configuration (make config), you are asked, for each optional part of the kernel, whether you want it bound into the kernel (a “Y” response), created as an LKM (an “M” response), or just skipped completely (an “N” response). Other configuration methods are similar.

You should have only the bare minimum bound into the base kernel. And only skip completely the parts that you’re sure you’ll never want. There is very little to lose by building an LKM that you won’t use. Some compile time, some disk space, some chance of a problem in the code killing the kernel build. That’s it.

As part of the configuration dialog you also must choose whether to use symbol versioning or not. This choice affects building both the base kernel and the LKMs and it is crucial you get it right.

LKMs that are not part of Linux (i.e. not distributed with the Linux kernel) have their own build procedures which I will not cover. The goal of any such procedure, though, is always to end up with an ELF object file.

Please note that you don’t have to rebuild all the LKMs and your base kernel image at the same time (e.g. you could build just the base kernel and use LKMs you built earlier with it).

If you followed advise and guidance as provided in this tutorial guide then you would have learnt about LKMs and its benefits together with how to make loadable Kernels.

Welcome to the user tutorial guide. The guide will provide a user with advise and guidance on how to install the user mode linux.

Once your kernel is created, you can prepare it for use. You can copy the kernel from the ./linux directory and System.map file to /boot. An example is provided below which can be used. The only thing that you will need to change is KERNEL_VERSION to the version of your kernel.

$ cp arch/i386/boot/bzImage /boot/bzImage-KERNEL_VERSION
$ cp System.map /boot/System.map-KERNEL_VERSION
$ ln -s /boot/System.map-KERNEL_VERSION /boot/System.map

The next step is to configure the bootloader. The bootloader is the first program that runs when a computer is booted. For this document it is assumed that you are running an IA32 system with a standard PC BIOS. If you are running the LiLO bootloader skip to the the Section called LiLO Configuration otherwise proceed to the Section called GrUB

GrUB Configuration
GrUB is beginning to supplant LiLO as the bootloader of choice in more recent Linux distributions. It is generally more flexible and a lot more forgiving of system errors. For example, LiLO generally requires that an alternate boot disk is used if the kernel configuration renders the system unbootable Grub allows “on-the-fly” modification of kernel location, boot parameters, kernel to boot, etc..

After you have copied the bzImage and System.map to /boot, please edit the grub configuration file located in /boot/grub/menu.lst. On some distributions /etc/grub.conf is a symbolic link to this file.
# Note that you do not have to rerun grub after making changes to this file
#boot=/dev/hda
default=0
timeout=10
title Red Hat Linux (2.4.20-24.9)
root (hd0,1)
kernel /boot/vmlinuz-2.4.20-24.9 ro root=LABEL=/
initrd /boot/initrd-2.4.20-24.9.img
title Red Hat Linux (2.4.20-20.9)
root (hd0,1)
kernel /boot/vmlinuz-2.4.20-20.9 ro root=LABEL=/
initrd /boot/initrd-2.4.20-20.9.img

You can edit the file to include the new kernel information. Please keep in mind that GrUB counts starts from 0, so (hd0,1) references the first controller, second partition. If you have created an initial RAMdisk be sure to include it here too. A typical configuration looks like following below:
title Test Kernel (2.6.0)
root (hd0,1)
kernel /boot/bzImage-2.6.0 ro root=LABEL=/
initrd /boot/initrd-2.6.0.img

LiLO Configuration
LiLO is an older bootloader. Its configuration file is located in /etc/lilo.conf on most systems. Unlike GrUB, any changes to lilo.conf will not be set until the lilo program is rerun.
boot=/dev/hda
map=/boot/map
install=/boot/boot.b
default=test-2.6.0
keytable=/boot/us.klt
lba32
prompt
timeout=50
message=/boot/message
menu-scheme=wb:bw:wb:bw
image=/boot/vmlinuz
label=linux
root=/dev/hda3
append=” ide1=autotune ide0=autotune”
read-only

image=/boot/bzImage-2.6.0
label=test-2.6.0
root=/dev/hda2
read-only

The important sections are the image=/boot/bzImage and the default=test-2.6.0 options. Notice that you can have several image sections in the lilo.conf, allowing multiple configurations. Install the new kernel by running the lilo program.
$ /sbin/lilo
If you are installing and testing the kernel remotely, you can instead specify to LiLO that the new kernel is loaded only for the next boot by using the following syntax:
$ /sbin/lilo -R test-2.6.0
Messages will appear showing the newly added kernel with an asterisk marking the default image. If you get errors, consult the lilo documentation for the correct syntax.

If you followed advise and guidance as provided in this tutorial guide then you would have successfully installed the User mode linux and have configured the GrUB and LiLO.

Welcome to the tutorial guide. The guide will provide a user with advise and guidance on how to create a initial RAMDisk.

After building the main boot drivers as modules (e.g., SCSI host adapter, filesystem, RAID drivers) the next step is to create an initial RAMdisk image.

Please note that the drivers are required to load the root filesystem but the filesystem cannot be loaded because the drivers are on the filesystem. The manpage for mkinitrd states:
“mkinitrd creates filesystem images which are suitable for use as Linux initial ramdisk(initrd) images. Such images are often used for preloading the block device modules (such as IDE, SCSI or RAID) which are needed to access the root filesystem. mkinitrd automatically loads filesystem modules (such as ext3 and jbd), IDE modules,all scsi_hostadapter entries in /etc/modules.conf, and raid modules if the systems root partition is on raid, which makes it simple to build and use kernels using modular device drivers.”
–MKINITRD(8)

If you want to create the initrd, pleas run following:
$ mkinitrd /boot/initrd-2.6.0.img 2.6.0

Please note that some versions of mkinitrd may require other options to specify the location of the new kernel. On SuSe 9.0, the following syntax is required:
$ mkinitrd -k vmlinux-VERSION -i initrd-VERSION

Troubleshooting Build Failures
If your build fails with a signal 11 error it is most likely because of hardware problems; often the culprit is failing memory. Unfortunately, the BIOS memory check is close to useless in detecting intermittent memory failures. Even dedicated memory checkers do not stress memory as much as gcc running a kernel build. One way to tell if hardware is at fault is to restart the ‘make bzImage’ process. If you can get a little further before failing again then it is a hardware error. There are several possible ways to try to correct these.
Try changing your memory settings in the BIOS to more conservative levels. For example, change to SLOW or NORMAL instead of FAST. Verify that all the fans are working correctly.

Swap out the memory. One trick is to specify less memory than is actually installed by passing values to the kernel on boot. This prevents the kernel from accessing all the memory in the machine, and could help diagnose bad SIMMs or SDRAMs.
If instead the ‘make’ fails at the same point each time, then it is a configuration error. These usually result from not enabling a feature that is required by another. For example, IP Firewalling requires TCP/IP. If the prerequisite is not enabled, the build will fail. You may also get errors if you select the wrong processor or are using either a very old or development compiler.
Please note that the kernel is highly sensitive to the versions of the build tools such as the compiler and linker. The versions listed are requirements, not suggested.

If you followed the advise and guidance as provided in this tutorial guide then you would have successfully created the initial RAMdisk.

Welcome to the tutorial guide. The guide will provide a user with advise and guidance on how to build the kernel.

Before we go ahead with the process of building kernel, we need to create the necessary include files and generate dependency information. Please note that this step is only required for the 2.4.x kernel tree.
$make dep

You will notice that several messages will be displayed. It all depends on the speed of the machine and what options you chose. After the dependency information is created, the next step is to clean up the miscellaneous object files. This step is required for all versions of the kernel.
$make clean

After going through the steps as mentioned, it is time to build the Kernel
Please type:
$make bzImage

As the Kbuild documentation states:
“Some computers won’t work with ‘make bzImage’, either due to hardware problems or very old versions of lilo or loadlin. If your kernel image is small, you may use ‘make zImage’, ‘make zdisk’, or ‘make zlilo’ on these systems.”

On an Athlon 1800XP, building the bzImage can take a couple of minutes for a moderately configured kernel. On a Pentium 100 used as a baseline, a similar configuration took almost 45 minutes. If everything went correctly then the new kernel should exist in ./arch/$ARCH/boot. If you are on an IA32 system, then you can use following code to verify this:
$ls -l arch/i386/boot

How to build the modules
As the kernel has been created now, so the next step now is to create all the loadable modules if you have them configured. Be aware that typical distribution kernels tend to have almost every feature installed, plus a few others for good measure. This is a time consuming process and it can take an hour or so to build on our Athlon XP1800. If you want to build the modules then please run the following code:
$ make modules

After the modules are built, the next step is to install the the modules. Please note tht if you are building as a non-privileged user you will now need to switch to root to complete the next step:
$ su
password:
$ make modules_install

This will copy the modules into /lib/modules/KERNEL_VERSION.
If you followed advise and guidance as provided in this tutorial guide then you would have successfully build the modules.

Welcome to the tutorial guide. The guide will provide a user with guidance and information on how to configure the 2.6.x kernels. Please note that there are four main frontend programs: config, oldconfig, menuconfig, and xconfig.

It is good to know these frontend programs. config is the least user-friendly. If a user makes an error then he/she has to begin the process from the top. If you press Enter, it will accept the default entry which is in upper case.

oldconfig has the functionality to read the defaults from an existing .config and rewrite necessary links and files. This option is recommended if you have made minor changes to source files or need to script the rebuild process.

menuconfig is an ncurses based frontend. Please note that if you are planning to use this frontend then the system must have the ncurses-devel libraries installed. A user can navigate by using arrow keys. Press Enter to select sub-menus. Press the highlighted letter on each option to jump directly to that option. If you want to build an option directly into the kernel, please press Y and if you want to disable an option entirely, press N. If you want to build an option as a loadable module, press M. You can also access content-specific help screens by pressing ? on each page or selecting HELP from the lower menu.

xconfig is a graphical frontend using qconf by Roman Zippel. It requires the qt and X libraries to build and use.

Aftet you have decided which configuration option to use, you can then start the process with make followed by either config, menuconfig, or xconfig. An example will make this clear:
$ make menuconfig

Please note that the system will take a few moments to build the configuration utility. After that you will then be presented with the configuration menus.

There are some top level configuration options in the 2.6 kernel. Some of these are provide below:

- Code Maturity Level Options
This option allows configuration of alpha-quality software or obsoleted drivers. If the kernel is intended for a stable production system then it is a good idea to disable this option

General Setup
This section contains options for sysctl support, a feature allowing run-time configuration of the kernel. A new feature, kernel .config support, allows the complete kernel configuration to be viewed during run-time. This addresses many requests to be able to see what features were compiled into the kernel.
- Loadable Module Support
You will almost certainly want to enable module support. If you will need third-party kernel modules you will also need to enable Set Version Information on All Module Symbols.
- Processor Type and Features
This is considered to be the most important configuration choice. In the Preparation section we determined our processor type by examining /proc/cpuinfo and we use that information here to select the appropriate processor.
- Power Management Options
In power management options, ACPI and CPU Frequency Scaling options exist. This can improve laptop power usage. Read the Documentation/power file for more information.

- Bus Options ( PCI, PCMCIA, EISA, MCA, ISA)
Bus options present options for all system bus devices. On modern machines the ISA and MCA support can often be disabled.

• Executable File Formats
• Interesting features here include the kernel support for miscellaneous binaries, which can allow seamless operation of non-Linux binaries with a little userland help.
• Device Drivers
• All the device-driver configuration options that were previously scattered throughout the 2.4.x menus are now neatly organized under this option. Features such as SCSI support, graphic card optimizations, sound, USB and other hardware are configured here.
• File Systems
• File system present with options for filesystems which are supported by the kernel, such as EXT2 and ReiserFS. It is best to build support for the root filesystems directly into the kernel rather than as a module.
• Security Options
• Interesting options here include support for NSA Security Enhanced Linux and other, somewhat experimental, features to increase security.

If you followed the advise and guidance as provided in this tutorial guide then you would have successfully learnt about configuring the 2.6.x kernels.

Welcome to the tutorial guide. The guide will provide a user with guidance and instructions on how to configure 2.4.x kernels.

The main step is to run the configuration utility. Please note that in the 2.4.x kernels there are four main frontends: config, oldconfig, menuconfig, xconfig. We choose one configuration method and run it, for example:
$ make config
config is the least user-friendly option as it merely presents a series of questions that must be answered sequentially. Alas, if an error is made you must begin the process from the top. Pressing Enter will accept the default entry, which is in upper case.
oldconfig will read the defaults from an existing .config and rewrite necessary links and files. Use this option if you’ve made minor changes to source files or need to script the rebuild process. Note that oldconfig will only work within the same major version of the kernel. You cannot, for example, use a 2.4.x .config with the 2.6.x kernel.
menuconfig is an ncurses-based frontend. Your system must have the ncurses-devel libraries installed in order to use this utility. As the help text at the top of the screen indicates, use the arrow keys to navigate the menu. Press Enter to select sub-menus. Press the highlighted letter on each option to jump directly to that option. To build an option directly into the kernel, press Y. To disable an option entirely, press N. To build an option as a loadable module, press M. You can also access content-specific help screens by pressing ? on each page or selecting HELP from the lower menu.

For the purposes of this next section we will assume that make xconfig is used. The options are identical otherwise. As mentioned, there are literally hundreds of configuration options and this precludes us from listing every one of them. If you are unsure of an option use the online help or consult the kernel documentation found in the ../linux/Documentation directory. We begin by typing:
$ make xconfig
The main configuration menu will appear. Selecting an item will bring up another window with further options. These in turn can spawn other sub-menus.
• Code Maturity Level Options
• This option allows configuration of alpha-quality software. It is best to disable this option if the kernel is intended for a stable production system. If you require an experimental feature in the kernel, such as a driver for new hardware, then enable this option but be aware that it “may not meet the normal level of reliability” as tested code.
• Loadable Module Support
• You will almost certainly want to enable module support. If you will need third-party kernel modules you will also need to enable Set Version Information on All Module Symbols.
• Processor Type and Features
• This is perhaps the most important option to choose. In the Preparation section we determined our processor type by examining /proc/cpuinfo and we use that information here to select the appropriate processor. Included in this submenu are features such as Low Latency Scheduling which can improve desktop responsiveness, Symmetric Multi-processing Support for machines with multiple CPUs, and High Memory Support for machines with more than 1G of RAM. Laptop users can also benefit from the CPU Frequency Scaling feature.
• General Setup
• Choices for PCI, ISA, PCMCIA and other architectural support such as Advanced Power Management are found here.
• Memory Technology Devices
• MTD devices include Compact Flash devices. Some digital cameras will require this support.
• Block Devices
• The Block Device section contains options for floppy and hard drives, including parallel port devices, tape drives and RAID controllers. Important options include loopback device support, which allows mounting on disk images, and initrd support, which is needed to preload drivers necessary to boot the system.
• Multi-Device support (RAID and LVM)
• Important for servers, these options include RAID support for combining multiple disks. Note that this option is not needed for certain hardware RAID that function below the operating system level. LVM is a useful subsystem that allows, among other things, dynamic resizing of filesystems.
• ATA/IDE/MFM/RLL support.
• This section includes options for IDE/ATAPI chipsets, including performance tweaks such as DMA. Most systems will need this support.
• Cryptography Support (CryptoAPI)
• Useful options include Loopback Crypto Support, which allows encrypted filesystem images to be mounted. Even with full access to the PC, loopback encryption can help safeguard data.
• Networking Options
• Many choices are available for networking. TCP/IP, IP tunneling, packet filtering, IPv4 and IPv6, routing support and network QoS are among the most useful. If your kernel is intended for a dedicated firewall or router device, then the options here can significantly improve performance. Read the online and kernel documentation.
• SCSI Support
• SCSI support is needed for not only true SCSI devices, but also for IDE CDR/W drives in SCSI emulation mode. If your root filesystem is mounted on a SCSI disk, then you must build support directly into the kernel and not as a module.
• Character Devices
• Dozens of options are available here, including support for many serial and parallel devices, hardware sensors (for system monitors), mice, joysticks and DRM. Many of the options can be safely disabled without problem.
• File Systems
• It is a good idea to build support for your root filesystem directly into the kernel. Though the initrd utilities can get around the chicken-and-egg boot problem, it is generally safer and easier to just build the fs modules directly. Many options can also be safely disabled if you have no use for the feature.
Once all the configuration changes have been made, you can go ahead and save settings. By default, the configuration is placed in the .config file in the topmost directory. Because this file is deleted by make mrproper and is also hidden, it is a good idea to use the Save to Alternate File before exiting. It will prompt for another save location. Enter something outside of the source tree and with a useful name such as kernel-2.4.22-lowlatency.config. Once this is done, exit the configuration menu. You will be prompted to save the configuration again. Select Yes and continue.

The configuration for the 2.4.x kernel is now complete. If you followed advise and guidance as provided in this tutorial guide then you would have configured the 2.4.x kernel now.

Welcome to the tutorial guide. The guide will provide a user with advise and guidance on how to configure a Kernel.

Please note that the configuration process is the complicated part of the kernel rebuild process. In this step you have to plan and decide which features should be included in the final kernel and it can require lots of hardware knowledge. In truth, it is not too onerous. The current kernels have graphical configuration programs and though not perfect, provide help screens for most of the configuration options.

Many changes were made to the configuration subsystem in the 2.6.x kernel series. It is easier to add modules and much more robust than before. It has also changed dramatically in appearance especially when using the X-based configuration tool, xconfig.

Both configuration tools provide context sensitive help screens for the different options. Because this help is readily available to the user (and more importantly, because there are several hundred options) this guide will only cover a fraction of the choices.

Compile Modules or Static
One of the first choices you will make is whether or not to build device support directly into the kernel or as a module. With any modern CPU, the time to load and unload the modules and the memory required for the module loader subsystem is negligible even to benchmarking utilities. Some devices, notably the disk controller, can be built directly into the kernel in order to simplify the boot process.

It is a good idea to disable some options entirely as there are advantages to disabling features that are not required. You will note that the compile times will be drastically reduced which depends on which subsystem is disabled.

Also, the final kernel and installed modules will require less space. On modern hard drives of 40G, 60G, and even 250G, an extra 20M or so is negligible but is significant on embedded or older systems.

Assign Unique Name
It is good to know that inside the Linux source directory is the default Makefile. This file is used by the make utility to compile the Linux sources. The first few lines of the Makefile contains some versioning information. This information is as provided below:
VERSION = 2
PATCHLEVEL = 4
SUBLEVEL = 22
EXTRAVERSION = -1

The additional EXTRAVERSION field is to prevent overwriting any existing kernel modules on the system.

Backup .config
Please note that the configuration choices are kept in the ../linux/.config file. If you have not already run any configurations, this file will not exist. If you have, and would like to save your configuration, copy the .config to another file:

$ cd linux
$ cp .config config.save

If you are using the sources from a vendor, then the default configuration files are usually included in the configs or in the ./arch/i386/defconfig (for i386 machines) file. As the .config will be overwritten in the next step, so please don’t forget to do a backup before proceeding.

Let’s start the configuration process by wiping out all previous configurations and resetting the source directory to a pristine state. The main reason for doing this is that some files do not automatically get rebuilt, which can lead to failed builds.
$ make mrproper

In the 2.4.x series, a few dozen lines of rm -f commands will appear as all generated files get removed. Please note that the 2.6.x process returns only a few CLEAN messages. Please note that it is generally safe to omit the make mrproper step during subsequent rebuilds.

If you followed advise and guidance as provided in this tutorial guide then you would have have compiled modules, assigned unique name and successfully dealt with backup configuration.

Welcome to the tutorial guide. The guide will provide a user with information on determining the hardware.

Please note that after you have determined that your hardware and software meet the minimum requirements for the kernel build, we will need to collect more detailed information about the system. This is needed during the configuration process when we decide which hardware will be supported under our new kernel. The information that we will gather include: Processor, Drive type and Controller (SCSI, IDE), Ethernet devices, Graphics and Sound Cards, USB HUB.

Let’s start by running the /sbin/lspci utility to print information about our hardware by running following command:

$ /sbin/lspci
00:00.0 Host bridge: Silicon Integrated Systems [SiS] 735 Host (rev 01)
00:01.0 PCI bridge: Silicon Integrated Systems [SiS] 5591/5592 AGP
00:02.0 ISA bridge: Silicon Integrated Systems [SiS] 85C503/5513
00:02.2 USB Controller: Silicon Integrated Systems [SiS] 7001 (rev 07)
00:02.3 USB Controller: Silicon Integrated Systems [SiS] 7001 (rev 07)
00:02.5 IDE interface: Silicon Integrated Systems [SiS] 5513 [IDE] (rev d0)
00:02.7 Multimedia audio controller: SiS7012 PCI Audio Accelerator (rev a0)
00:03.0 Ethernet controller: [SiS] SiS900 10/100 Ethernet (rev 90)
01:00.0 VGA compatible controller: ATI Technologies Inc Rage 128 RF/SG AGP

If we don’t know about our processor then it is a good idea to determine the processor type As some Linux systems contain a /proc filesystem that allows a user to view raw information about the system. If /proc exists please run following command to get the processors’ information:
$ cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 6
model : 6
model name : AMD Athlon(tm) XP 1800+
stepping : 2
cpu MHz : 1526.870
cache size : 256 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge
bogomips : 3047.42

If you are interested in acquiring the Linux kernel sources, then please note following. If you are using a packaged distribution then most likely the distributor will bundle a kernel source package. These are installable via the package installation method, whether RPM, apt, YAST, portage, etc..

The other option is to use the pristine sources, either the official sources one of the regularly maintained trees. Please note that these sources are full of new features and untested code.

Untested code
This is a feature of the distributed development model of Linux and Open Source (??) in general. The traditional model of a software release is somewhat antithetical to this model, as new code must be released to allow all developers to test and improve the code. However, because Linux is used in production environments throughout world it is necessary to separate the unstable development tree from the tested, stable tree. This is done through the version number of the kernel. There are three main numbers associated with the kernel — the Major, Minor, and PatchLevel fields. The Major number rarely changes, and then only when/if the entire architecture is revamped. The Minor number changes more frequently, perhaps once every couple years. Kernels with an odd Minor number are considered unstable, testing branches. Kernels with an even Minor number are generally rock solid. The PatchLevel is updated frequently, sometimes more than once a week in extreme cases.
To recap, you can build either from your distribution’s modified kernel sources or from the stable or unstable branch of the offical sources. If you are making minor modifications to the configuration, it is perhaps safest to install your distributor’s version. These kernels usually include stability and feature patches that may be missing from the stock kernels. For example, some distributors will include low-latency or security patches and do the more difficult work of integrating these into their system. The downside is that the distributors tend to lag behind the bleeding-edge kernels. If you would like to test features that are available in the newest tree then you will likely need to build from the “pristine” source from Linus or the tree maintainer of your choice.

Download the Source
Please note that you will see several links to /pub/linux on the mirror site. You can select the kernel directory, then the kernel version that you would like to install. Once you select a kernel version you will see several files such as following:

ChangeLog-2.6.0-test9 25-Oct-2003 14:51 41k
LATEST-IS-2.6.0-test9 25-Oct-2003 14:51 0k
linux-2.6.0-test9.tar.bz2.sign 25-Oct-2003 15:14 1k
linux-2.6.0-test9.tar.gz 25-Oct-2003 15:14 39.7M
linux-2.6.0-test9.tar.gz.sign 25-Oct-2003 15:14 1k
linux-2.6.0-test9.tar.sign 25-Oct-2003 15:14 1k
patch-2.6.0-test9.bz2.sign 25-Oct-2003 15:14 1k
patch-2.6.0-test9.gz 25-Oct-2003 15:14 123k
patch-2.6.0-test9.gz.sign 25-Oct-2003 15:14 1k
patch-2.6.0-test9.sign 25-Oct-2003 15:14 1k

The Changelog files detail the differences between versions. The linux- files are the compressed sources for the entire Linux kernel. Please note that most sites will contain both gzip and bzip packages. The bzip packages tend to be smaller than the GZIP versions, so they are usually the best option since all modern Linux distributions contain BZIP utilities.

The patch files are a list of differences between versions of the kernel. If you have previously downloaded an earlier source package, you will only need to download the much smaller patch file to bring those up to date. We will discuss patch application in the next section.

There are also some .sign files that contain GPG checksum information which are useful for verifying that the sources you downloaded have not been corrupted or maliciously modified.

Extract and Patch
Please note that once you have retrieved the kernel sources and patches, you will need to extract them and apply the patches. The pristine 2.4.x and 2.6.x sources can be built as a regular, unprivileged user and this is recommended. Let’s start by creating a directory to hold all the source tarballs and patches, then proceed to extract the sources. For these examples we will assume that you have previously downloaded an earlier release of the kernel and will now need to patch to bring it up to the current version.
$ mkdir src
$ cd src

If your Linux sources are in BZIP compressed format then please use the following command:
$ tar xfvj /path/to/linux-2.6.0-test7.tar.bz2

Otherwise, use the options for GZIP compressed data:
$ tar xfvz /path/to/linux-2.6.0-test7.tar.gz
You should see a list of filenames scroll by as they are being extracted. Verify that the new kernel source directory is created:
$ ls -l
total 4
drwxr-xr-x 18 kwan users 4096 Oct 8 15:24 linux-2.6.0-test7
-rw-r–r– 1 kwan users 276260 Nov 15 02:05 patch-2.6.0-test8.gz
-rw-r–r– 1 kwan users 126184 Nov 15 02:07 patch-2.6.0-test9.gz

Next we must apply the patches in order. Patch files are created by the diff program, and can selectively modify one or more files by adding, deleting, or modifying lines in the source code. Because they contain only the differences between files it is usually a lot faster (and better for the Internet in general) if you patch to the current release. (TBF unclear). Appendix TBF shows a typical patch file. Like the kernel sources, the patch files are also compressed.
$ gunzip patch-2.6.0-test8.gz
$ gunzip patch-2.6.0-test9.gz
$ ls -l
-rw-r–r– 1 kwan users 1072806 Nov 15 02:05 patch-2.6.0-test8
-rw-r–r– 1 kwan users 486902 Nov 15 02:07 patch-2.6.0-test9
Once the patches are uncompressed we can apply them to the kernel sources. Remember that it is important to apply them in order.
$ cd linux-2.6.0-test7
$ patch -p1 <../patch-2.6.0.test8
$ patch -p1 <../patch-2.6.0.test9

If it is successful you will see messages similar to the following scroll by:
patching file Documentation/filesystems/jfs.txt
patching file Documentation/filesystems/xfs.txt
patching file Documentation/ia64/fsys.txt
patching file Documentation/ide.txt
patching file Documentation/x86_64/boot-options.txt
patching file Makefile

If unsuccessful you will get a warning and be prompted for a file to patch. If this occurs, press Ctrl-C to break out of the patch utility and verify that you are using the correct patch and applying them in the correct order.
Once all the patches are applied you might consider backing up the directory.
$ cd ..
$ mv linux-2.6.0-test7 linux-2.6.0-test9
$ tar cfvj linux-2.6.0-test9.tar.bz2 linux-2.6.0-test9

If you followed advise and guidance as provided in this tutorial guide then you would have successfully determined the hardware.