for the man who wrote his msn personal message “compiling kernel” called drave(!)
thnx to philip
Installing the kernel source code
http://www.kernel.org/pub/linux/kernel/
http://www.kernel.org/pub/linux/utils/kernel/modutils/
The source code for the kernel that is on your machine right now is in the directory ‘/usr/src/linux/’.It is wise to keep this particular source code safe, for example by renaming the linux directory as follows:
cd /usr/src
mv linux linux-2.2.19 (if the original source code is for 2.2.19).
Only after you have safely stored the original kernel should you unpack the newest kernel: you will see that the file linux-2.4.6.tar.bz2 unpacks everything in the ‘linux’ directory by default. It is overwritten if this directory already exists, and then you have problems: you can no longer recompile the original kernel, you lost the original configuration, etc. In this example I rename the ‘linux’ directory right after unpacking the kernel source code ‘linux-2.4.6′, and I create a symbolic link with the name ‘linux’ to the directory ‘linux-2.4.6′. The advantage of this procedure is that you can see the system’s present kernel version immediately. In addition it is easier to install a kernel upgrade. The commands are (as root, remember):
cd /usr/src
cp ~/linux-2.4.6.tar.bz2 ( assuming that the tarball was downloaded )
( to your home-directory (’~') )
bzip2 -d linux-2.4.6.tar.bz2 (this may take a while )
tar -xvf linux-2.4.6.tar
mv linux linux-2.4.6
ln -s /usr/src/linux-2.4.6 /usr/src/linux
Once this is done you go the kernel’s directory, and you do:
cd /usr/src/linux
make xconfig
Then Configure ur kernel…
Compiling the kernel
By clicking on ‘Save and Exit’ you store your configuration choices in the file ‘./.config’ (or ‘/usr/src/linux/.config’ if you compile in /usr/src/linux). As an aside, it is handy to save this file and to copy it to the new kernel source directory if you do only a minor upgrade, from kernel 2.4.5 to 2.4.6 for example. This way you can (usually) keep all your old configuration choices, which can save a lot of work. In a similar way you can start off by using the config file of the ’standard’ kernel of your distribution, which in some distro’s is called at /boot/config (copy it to ./.config to start using it). But, if you upgraded your kernel source and you get weird problems when compiling the kernel this is of course the first file you remove! As a matter of course you have, for security’s sake, written down and carefully stored the configuration of the kernel that works correctly. The procedure to compile the kernel is as follows:
make dep
make clean (for older kernels)
make bzImage
make modules
make modules_install
Of course you execute these commands in linux’ source directory, usually ‘/usr/src/linux’. Kernels in the 2.0.x series or older also need the command ‘make clean’, which removes earlier files before the compilation of a new kernel. The ‘make clean’ command prevented strange error messages that were difficult to track down, but were presumably caused by older object (.o) files that were not overwritten. The command ‘make bzImage’ compiles the new kernel, but does not yet install it. You can also compile the kernel with other ‘make’ commands, e.g., ‘make bzlilo’ or ‘make zImage,’ but these commands can give unexpected problems. Most kernels are too large to allow a properly executed ‘make zImage’: you get an error message during the compile, and you end up without a kernel. With the command ‘make bzlilo’ everything must be configured properly in files such as ‘/etc/lilo.conf,’ but this is not always the case. Hence it is safer to avoid these latter commands. The command ‘make modules’ compiles the modules: they are installed with the command ‘make modules_install’. This command puts the modules in the directory ‘/lib/modules/2.4.6/’ if the present kernel version is 2.4.6: it changes when you compile another kernel version. This way the modules corresponding to a particular kernel end up automatically in a separate directory, thereby avoiding conflicts with obsolete modules and similar problems. During boot the linux kernel now knows in which directory it can find the right modules. But, the files in ‘/lib/modules/2.4.6/’ are overwritten and older modules remain if you already compiled kernel 2.4.6 earlier and now recompile it. Then, older modules may hang around even though they are no longer needed in the newer kernel. Normally this is not a problem, but it is always a good idea to take the time to remove the older modules first before installing the new ones.
To avoid problems in installing the kernel you must also ensure that lilo’s configuration ‘/etc/lilo.conf’ is correct, and you must copy the kernel and the file ‘System.map’ into the correct location. After all this you must also execute the command ‘lilo’ too. An alternative is the use of ‘loadlin’, which allows booting a linux kernel under Dos/Windows. Both options are discussed below.
Configuring lilo
You can find lilo’s configuration file usually in the ‘/etc’ directory as ‘/etc/lilo.conf’. Open it in a text window with a simple ASCII editor: you may have installed a full-fledged editor like XEmacs (then, use ‘xemacs /etc/lilo.conf &’), a simple full screen editor like kedit or gedit (then, use ‘k(g)edit /etc/lilo.conf’) or a primitive line editor such as pico or nano (then, use ‘pico /etc/lilo.conf’). The file lilo.conf will look something like this:
boot = /dev/hda
vga = normal
read-only
menu-scheme = Wg:kw:Wg:Wg
lba32
prompt
timeout = 300
message = /boot/message
other = /dev/hda1
label = win98
image = /boot/bzImage
label = linux-2.4.6
root = /dev/hda3
append = “parport=0×378,7 hdd=ide-scsi”
image = /boot/vmlinuz.suse
label = suse
root = /dev/hda3
append = “hdd=ide-scsi”
initrd = /boot/initrd.suse
The detailed content of the file lilo.conf may well differ from the above on each system and between distributions. Therefore I will now walk you through this file. The top 8 lines are already in good shape and you need not change them, usually. The command ‘boot’ in the first line indicates the physical hard disk from which booting starts, that is, ‘boot’ points to the location of the ‘master boot record’. In my case booting starts from /dev/hda, the first physical hard disk. The option ‘vga’ indicates that the boot uses a standard VGA text mode, with 80×25 characters. The option ‘read-only’ means that the booting process first mounts the linux partition read-only. During linux’ boot the partitions are checked for errors: only afterwards are they re-mounted with both read and write permissions. The line ‘menu-scheme’ sets the colors of the ‘lilo’ boot menu in text mode. With ‘lda32′ it is possible to boot the operating system after the 1024′th cylinder, provided that this is supported in the BIOS. All moderns systems support ‘lba32′. Problems with this you can solve through a BIOS upgrade, something that is almost a necessity with the large hard disks that are now available. The command ‘prompt’ forces ‘lilo’ to give a prompt that allows the user to choose the desired operation system. The option ‘timeout’ gives the number of milliseconds that ‘lilo’ waits for input after the prompt before starting the standard operating system. If ‘lilo.conf’ does not give a standard operating system, as in the example here, the boot process starts the first operating system encountered. In my case this is Windows98, so that people who do not know linux yet will end up in a Windows environment. The ‘message’ option shows a message while ‘lilo’ is executing. Under SuSE this is Tux, linux’ cute penguin mascot, with (of course) the text ‘SuSE Linux 7.1′. You can see this message by typing ‘xv /boot/message’ or ‘gv /boot/message’ (sometimes even ‘gimp /boot/message’) : ‘xv’ and ‘gv’ (ghostview) are shareware programs with which you can look at various kinds of picture formats. Please note that the file /boot/message does not exist on systems without a graphical login screen (e.g. older distributions), in this case the ‘boot message’ is just a text message. It is in principle possible to show your own preferred image during boot, but I have not yet tried out this possibility. All options to ‘lilo’ are of course documented in the ‘man’ pages, which you access by the commands ‘man lilo’ and ‘man lilo.conf’.
The other options direct the boot of the various operating systems. At most you can boot up sixteen different operating systems or kernels. Normally this is ample. You pick the operating system with the line ‘label=’. The default for Windows98 (and also older Windows versions and DOS, but not Windows NT or Windows 2000) is to have them on the first, primary partition. Therefore these operating systems only need a line ‘other’ and a line ‘label’. The second section, starting with ‘image=/boot/bzImage’, starts the new kernel with the label ‘linux-2.4.6′. My linux root directory is ‘/dev/hda3′. The line ‘append = “parport=0×378,7 hdd=ide-scsi”‘ tells the kernel the address and interrupt for the parallel port (port 0×378, interrupt 7) , and specifies that my CD burner ‘hdd’ must be addressed through SCSI-emulation. The names for the CDs depend on the system: in mine it is ‘hdd’, but in yours it can be another name. The use of an interrupt is mostly a question of personal preference. An interrupt speeds up printing, but you can leave out this command if you do not have an interrupt available for the parallel (printer) port. Linux’ default is the slower so-called ‘polling’, which allows the kernel to use the parallel port without an interrupt. The last section, starting with ‘image = /boot/vmlinuz.suse’, contains lilo’s configuration made during SuSE’s configuration process: I have added the line append=”hdd=ide-scsi” by hand. The file ‘boot/vmlinuz.suse’ is the standard kernel that comes with the distribution. Preferably, you should ALWAYS save this kernel for emergencies. The line ‘initrd = /boot/initrd.suse’ applies only to the standard installation kernel: it specifies the loading of a so-called ‘ramdisk’ image, a virtual disk that is loaded in memory (or random access memory, RAM). The ‘ramdisk’ contains the modules needed for the correct booting of linux: a distribution kernel must of course be able to access an enormous variety of hardware, something that is only feasible by using many modules.
Hopefully it is now clear where you must store the new linux kernel before executing lilo. In this example, the right commands are:
cp /usr/src/linux/arch/i386/boot/bzImage /boot
cp /usr/src/linux/System.map /boot/System.map-2.4.6
lilo
Under SuSE 7.3 you can also do the second copy like this:
cp /usr/src/linux/System.map /boot
( the original System.map has already been renamed )
If you already have a kernel with the name ‘bzImage’ and you want to keep this kernel, you can copy the new kernel to ‘/boot/bzImage-2.4.6′ and make the corresponding change in /etc/lilo.conf: change /boot/bzImage to /boot/bzImage-2.4.6. The compilation always recreates the file System.map, which contains the names and the configuration of important kernel variables. The command ‘depmod -a’ creates a file that contains all the dependencies of the kernel modules, that is, the various relations between the kernel and the modules, between the modules themselves, and also the information in the file ‘/etc/modules.conf’. Most linux distributions, including SuSE, make sure that ‘depmod -a’ is executed during boot, but it is wise to ensure explicitly that the file /boot/System.map exists, and that it corresponds to the proper kernel version. The command ‘lilo’ installs the new configurations of an old kernel, or the new kernel. If you already have a file ‘/boot/bzImage’ that you overwrite with a freshly compiled kernel but without executing lilo, you will end up with a new kernel that can not boot. The old, original distribution kernel that you stored safely away still works, because this one has not been overwritten. Keeping the old kernel makes it possible to compile and test new kernels in a responsible way.
Using loadlin
If you use ‘loadlin’ to boot linux you undoubtedly know how to find this handy program, viz., in C:\loadlin. Virtually all linux distributions have ‘loadlin’ on the first CD in the ‘dosutils’ directory. You must also copy the new linux kernel to the hard disk in ‘C:\loadlin’, perhaps with a unique name. By first starting Windows98 in DOS mode you can then boot linux with the command:
loadlin bzImage
Under normal circumstances most configurations that are stored in the kernel itself, such as the location of the root partition, are correct if you have compiled your own kernel, and in this case the above command is sufficient to boot linux without problems. By typing (in DOS) the command ‘loadlin | more’ you will get a help screen that includes a link to a ‘loadlin-HowTo’ on the Internet. With ‘loadlin’ you can try out a newly compiled kernel even if you are reluctant to diddle with ‘lilo’: namely, ‘loadlin’ and ‘bzImage together fit on a 1.44 MB diskette. There is absolutely nothing that can go wrong if you first boot DOS with a boot diskette (with support for EMM386), and then boot linux from the diskette with ‘loadlin’ and ‘bzImage’. But, you must of course have a DOS boot diskette.
SuSE and the ALSA sound drivers
SuSE uses the standard ALSA (Advanced Linux Sound Architecture) sound drivers. These drivers are better quality than the drivers of the OSS project that are standard in the kernel. If you are serious about sound under linux you should absolutely use the ALSA drivers. These drivers are not part of the (older) kernel source code, which implies that the drivers must be compiled and installed separately. Source code for the ALSA drivers are located in the part ‘zq’ of the SuSE distribution: read on if you do not know what this means. Install ALSA through YaST or YaST2 so that you have the source code available in the directory ‘/usr/src/packages/.’ To compile and install the ALSA drivers you do the following:
rpm -bb /usr/src/packages/SPECS/alsa.spec
cd /usr/src/packages/BUILD/alsa/alsa-driver-
./configure
make install
The first line installs the source code, including the drivers, in the directory ‘/usr/src/packages/BUILD/’ directory. In addition the ALSA libraries and utilities are directly compiled as rpm-files. Unfortunately, the ALSA drivers are not compiled in by default. You must compile and install them separately by hand using the bottom two commands. De command ‘./configure’ finds the necessary configurations and files in your system and puts them in a configuration file. The command ‘make install’ compiles all ALSA drivers and installs them at the same time for use by the kernel in the directory ‘/lib/modules/2.4.6/misc/’. Now, when booting SuSE the desired sound driver is installed automatically. I admit that the procedure suggested here is somewhat cumbersome, but you must know exactly what you are doing to find the necessary drivers and to include sound support in a new kernel in a more direct way.
If you do not use SuSE, or if you want to use a more recent version of the ALSA drivers, you can download these drivers and the corresponding libraries and utilities from http://www.alsa-project.org. This site’s start page gives the latest news on the ALSA project (e.g., February 2002’s integration of the ALSA drivers in the official 2.5 series kernel source tree) and links to the various files to download. Below I will show how to compile the ALSA drivers: you can follow the analogous steps for the libraries and the utilities. Unpack the drivers in a convenient directory, e.g., ‘/usr/local/.’ Move to this directory, in this case ‘/usr/local/alsa-driver-
Support for pcmcia (laptops)
Support for pcmcia is standard in kernels from 2.4.x onward. However, the official PCMCIA HOWTO argues that the kernel version of PCMCIA should preferably not be used. For now, the pcmcia source, including the scripts and the drivers can work with all the kernel trees: 2.0, 2.2, and 2.4. It is my experience that the pcmcia drivers stop to work after recompiling the kernel, and that they must be recompiled too. There are two solutions depending on your distribution. The first is to use the source code that comes with the distribution. Installing and compiling the source code to an rpm file gives you a file that you can install. The other solution is to download, unpack, compile, and install the most recent pcmcia version from http://sourceforge.net/projects/pcmcia-cs/), like this:
cp /etc/rc.d/pcmcia /etc/rc.d/pcmcia.SuSE
cp ~/pcmcia-cs-3.1.?.tar.gz /usr/src
cd /usr/src
tar -zxf ./pcmcia-cs-3.1.?.tar.gz
make config
make all
make install
cp /etc/rc.d/pcmcia.SuSE /etc/rc.d/pcmcia
The first and last lines solve a SuSE-specific problem. SuSE’s pcmcia-initialization script ‘/etc/rc.d/pcmcia’ is overwritten by the command ‘make install’, which cause the script to fail under SuSE. The problem is solved by copying the original script back after ‘make install’. If you have mistakenly overwritten the original SuSE script you must re-install the pcmcia packet anew beginning with the part ‘a1′, copy the original script to another file, execute ‘make install’ again, and finally copy the original script back.
The new rpm file for pcmcia support you get under SuSE as follows:
rpm -i /cdrom/suse/zq1/pcmcia-3.1.?.spm
cd /usr/src/packages
rpm -bb ./SPECS/pcmcia-3.1.?.spec
cd /RPMS/i386/
rpm -i –force ./pcmcia-3.1.?.rpm
SuSEconfig
In the first line I assume that you will install the pcmcia drivers by themselves from the sixth or seventh CD and that the CD-ROM reader is already mounted on /cdrom. The command ‘rpm -i’ installs the source code and the command ‘rpm -bb’ compiles the pcmcia rpm file. Then you install this particular rpm file as you do all rpm files. Note that you must use the option ‘–force’ because otherwise the rpm program will tell you (correctly) that ‘pcmcia’ is already installed, and will therefore ignore the new file. As always you must execute the program SuSEconfig (note the CAPITALS and lower case letters) when you have installed rpm files by hand under SuSE, to activate the configuration changes. The latter is done automatically by SuSE’s setup programs YaST or YaST2 after they have installed or modified new packets. Then, it is no longer necessary to do the activation by hand.
To be able to use pcmcia support properly you must leave on ‘network support’ during compilation, but you must turn off all other drivers for network cards. And, as has already been discussed with Figure 11, you must of course turn on ‘TCP/IP support’ too if you want to use the Internet.
Installing ‘modutils’
As already mentioned the kernel uses the small programs in ‘modutils’ to manage kernel modules. These programs include:
insmod (which installs a module),
rmmod (to remove a module, and)
lsmod (showing all modules in use),
among many others. With commands like ‘man lsmod’ you can find out how to work the various commands, something I will not get into here.
Compiling and installing ‘modutils’ is straightforward. Simply do:
cd /usr/src
cp ~/modutils-2.4.6.tar.bz2 . ( assuming that the file sits in your )
( home directory, ‘~’ )
bzip2 -d modutils-2.4.6.tar.bz2 ( unzip: this may take a while )
tar -xvf modutils-2.4.6.tar
cd modutils-2.4.6 ( go to the directory in which ‘modutils’ have )
( just been unpacked )
./configure (find system-specific configurations )
make ( compile ‘modutils’: since it is small the compilation can be )
( surprisingly fast )
make install (install ‘modutils’ in the directory ‘/sbin/’ )
This is all you have to do to make ‘modutils’ ready for use. Note again that in this example ‘modutils’ happen to have the same version number as the kernel, but this is not always the case.
Philip de Groot
0 Responses to “Compile your own Linux kernel”