Железо

Требования к железу могут существенно отличаться от версии к версии . Так , 2.4 может грузиться менее чем при 8 метрах памяти , но лучше хотя бы 64 метра . Для компиляции исходников нужно метров 500 на харде . Откомпилированное ядро с модулями может занимать до 4 метров . Ядро можно компилировать вообще на другой машине .

Требования к софту

Минимальные требования для компиляции ядра можно найти в ./Documentation/Changes . Они следующие :
2.4.x series

 o  Gnu C                  2.91.66     # gcc --version
 o  Gnu make               3.77        # make --version
 o  binutils               2.9.1.0.25  # ld -v
 o  util-linux             2.10o       # fdformat --version
 o  modutils               2.4.2       # insmod -V
 o  e2fsprogs              1.19        # tune2fs
 o  reiserfsprogs          3.x.0b      # reiserfsck 2>&1|grep reiserfsprogs
 o  pcmcia-cs              3.1.21      # cardmgr -V
 o  PPP                    2.4.0       # pppd --version
 o  isdn4k-utils           3.1pre1     # isdnctrl 2>&1|grep version
 
 		

		o  Gnu C                  2.95.3       # gcc --version
 o  Gnu make               3.78         # make --version
 o  binutils               2.12         # ld -v
 o  util-linux             2.10o        # fdformat --version
 o  module-init-tools      0.9.10       # depmod -V
 o  e2fsprogs              1.29         # tune2fs 
 o  jfsutils               1.1.3        # fsck.jfs -V
 o  reiserfsprogs          3.6.3        # reiserfsck -V 2>&1|grep reiserfsprogs
 o  xfsprogs               2.1.0        # xfs_db -V
 o  pcmcia-cs              3.1.21       # cardmgr -V
 o  quota-tools            3.09         # quota -V
 o  PPP                    2.4.0        # pppd --version
 o  isdn4k-utils           3.1pre1      # isdnctrl 2>&1|grep version
 o  nfs-utils              1.0.5        # showmount --version
 o  procps                 3.1.13       # ps --version
 o  oprofile               0.5.3        # oprofiled --version
 		

Тестирование железа

Once 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. Among the information we will gather include: Processor, Drive type and Controller (SCSI, IDE), Ethernet devices, Graphics and Sound Cards, USB HUB.

We start by running the /sbin/lspci utility to print information about our hardware:

			$ /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
 		

			$ 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
 		

Acquiring the Sources

There are many ways to acquire the Linux kernel sources. 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.. If you decide to go this route, please consult your distribution's documentation for specifics.

The other option is to use the "pristine" sources, either the "official" sources from Linus Torvalds himself, or one of the regularly maintained trees from people such as Alan Cox, Robert Love, Andrew Morton, et al.. These sources are often on the bleeding-edge of kernel development, 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.. FIXME: NO LONGER really true -- 2.6 based distributions are out there / will be (e.g., SuSE 9.1) by the end of April 2004.

Download the Source

Though the latest sources are always available from http://kernel.org, to be kind to the Internet, always use one of the mirrors listed at http://kernel.org/mirrors. In general, geographically close mirrors will tend to be fastest. You can either browse the sites with an Internet browser or with a dedicated FTP client.

You will see several links to /pub/linux on the mirror site. Select the kernel directory, then the kernel version that you would like to install. As of this writing, 2.4.22 is the latest stable version and 2.6.0 is in pre-release state. Once you select a kernel version you will see several files.

		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 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. For more information on verifying the GPG signature, see http://www.kernel.org/signature.html .

The http://kernel.org website is not the only place to retrieve patches. Many other vendors and individuals have developed patches to improve aspects of the kernel's performance, support new hardware, or introduce features that are too esoteric or experimental to make it to the stock kernel. For example, kernel hacker Robert Love had developed the pre-emptible kernel modifications that made dramatic improvements to the responsiveness of a Linux system. These patches were not part of the standard 2.4.x kernel but were of such usefulness that they were officially adopted into the 2.6.0 series. For the most part these third-party patches are stable but do use your judgment when downloading and applying them.

Extract and Patch

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. [3]

We will begin 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
 		

			$ tar xfvj /path/to/linux-2.6.0-test7.tar.bz2
 		

			$ tar xfvz /path/to/linux-2.6.0-test7.tar.gz
 		

			$ 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
 		

			$ 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
 		

			$ cd linux-2.6.0-test7
 			$ patch -p1 <../patch-2.6.0.test8
 			$ patch -p1 <../patch-2.6.0.test9
 		

		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
 		

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
 		

The Configuration Process

The configuration process is the most strenous portion of the kernel rebuild process. In this step you are deciding which features will 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. For this reason the configuration steps for the different branches have been split into two sections in this chapter.

As mentioned, 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. In the early days of Linux, when module support was in its infancy, it was possible that static (i.e., compiled in) drivers were faster. 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. [4]

You may also choose to disable some options entirely. Though you will not have any performance increases, there are advantages to disabling features that are not required. For one, the compile times will be drastically reduced depending on which subsystem is disabled. For another, 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. The disadvantage is that you will not have support for those features until you recompile the kernel. One other thing to keep in mind, as noted in KERNELTRAP.ORG (http://www.kerneltrap.org/node/view/799):

Assign Unique Name

We have so far extracted and patched the Linux sources. During our preparation we also determined what hardware is installed in the system so that we will know which modules will need compilation. Before we proceed to actually configuring the kernel there are a couple minor but important details to complete.

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:

		VERSION = 2
 		PATCHLEVEL = 4
 		SUBLEVEL = 22
 		EXTRAVERSION = -1
 		

Backup .config

Finally, before we begin, 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
 		

We begin the configuration 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, or at worst, a buggy kernel.

			$ make mrproper
 		

As of this writing (December 15, 2003), the 2.4.x kernel is in wide deployment. The 2.6.0 has just been released to the world. FIXME -- the previous sentence needs to be updated Though the configuration and build procedures are quite similar, there are enough differences to warrant separate sections for each kernel. If you are building a 2.6.x series kernel, skip to the Section called Configuring the 2.6.x kernels. Otherwise, proceed to the next section, the Section called Configuring the 2.4.x kernels.

Configuring the 2.4.x kernels

Our next step is to run the configuration utility. 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. Figure 1 shows an example screen. [5]

xconfig, as the name suggests, is an X Window based frontend. It requires the Tcl/Tk and X libraries to work, and of course, an X server. Figure 2 shows an example screen.

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
 		

Once all the configuration changes have been made, you can go ahead and save settings. By defaulti, 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. You may now skip to the chapter called Build.

Configuring the 2.6.x kernels

Our next step is to run the configuration utility. On the 2.6.x kernels there are four main frontend programs: config, menuconfig, and xconfig.

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.

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. Figure 1 in the Section called Configuring the 2.4.x kernels shows an example screen from the 2.4.x kernel series.

xconfig is a graphical frontend using qconf by Roman Zippel. It requires the qt and X libraries to build and use. The interface is intuitive and customizable. Online help is automatically shown for each kernel configuration option. It also can show dependency information for each module which can help diagnose build errors. Figure 3 shows an example of the xconfig screen. From the online help:

Once you have decided which configuration option to use, start the process with make followed by either config, menuconfig, or xconfig. For example:

		 	$ make menuconfig
 		

Dependencies

The next step is to create the necessary include files and generate dependency information. This step is only required for the 2.4.x kernel tree.

			$make dep
 		

			$make clean
 		

Build the Kernel

We are now (finally) ready to start the actual kernel build. At the prompt type:

			$make bzImage
 		

			$ls -l arch/i386/boot
 		

Build the Modules

There is one more step needed for the build process, however. You have created the kernel, but now you need 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. These can typically take an hour or so to build on our Athlon XP1800. The stock kernels are somewhat leaner by default and take, on average, 25 minutes to compile. To build the modules we run:

			$ make modules
 		

			$ su
 			password:
 			$ make modules_install
 		

Create Initial RAMDisk

If you have built your main boot drivers as modules (e.g., SCSI host adapter, filesystem, RAID drivers) then you will need to create an initial RAMdisk image. The initrd is a way of sidestepping the chicken and egg problem of booting -- drivers are needed to load the root filesystem but the filesystem cannot be loaded because the drivers are on the filesystem. As the manpage for mkinitrd states:

				$ mkinitrd /boot/initrd-2.6.0.img 2.6.0
 			

				$ 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. [8] 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.

Also keep in mind 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.

Copy the Kernel and System.map

Once your kernel is created, you can prepare it for use. From the ./linux directory, copy the kernel and System.map file to /boot. In the following examples change KERNEL_VERSION to the version of your kernel. [9]

 $ 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 your 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 Configuration.

FIXME: Need information on non-IA32 bootloaders!!

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..

Once you have copied the bzImage and System.map to /boot, 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
 		

		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
 		

		$  /sbin/lilo
 		

		$  /sbin/lilo -R test-2.6.0