mirror of https://github.com/tLDP/LDP
2511 lines
92 KiB
Plaintext
2511 lines
92 KiB
Plaintext
<!doctype linuxdoc system>
|
|
|
|
<!--
|
|
************************** begin comment *****************************
|
|
The following is the Linux Kernel HOWTO.
|
|
This document is in the SGML format. You must use sgml package to
|
|
process this document
|
|
************************* end of comment *****************************
|
|
-->
|
|
<!--
|
|
************************** SGML USER GUIDE *****************************
|
|
The SGML user guide on linux is located at /usr/doc/sgml-tools
|
|
Read the example.sgml and guide.html documents.
|
|
Usage:
|
|
HTML sgml2html foo (Do not give extension .sgml here!!)
|
|
Text sgml2txt foo.sgml
|
|
Latex sgml2latex foo.sgml
|
|
|
|
Note: Use 2 dashes - before language, error while compiling
|
|
Postscript sgml2latex -language=english -o ps foo.sgml
|
|
DVI sgml2latex -d foo.sgml
|
|
Lyx sgml2lyx foo.sgml
|
|
Richtext sgml2rtf foo.sgml
|
|
gnuinfo sgml2info foo.sgml
|
|
man sgml2txt -man foo.sgml
|
|
SGML sgmlcheck foo.sgml
|
|
************************* end of comment *****************************
|
|
-->
|
|
|
|
<article>
|
|
|
|
<title>The Linux Kernel HOWTO
|
|
<author>
|
|
<!--
|
|
Brian Ward
|
|
<htmlurl url="mailto:
|
|
bri[AT]cs.uchicago.edu
|
|
" name="
|
|
bri[AT]cs.uchicago.edu
|
|
">
|
|
web site of brain <url name="Brian Ward" url="http://www.o-REMOVE_THIS_LETTERS-o.net">
|
|
-->
|
|
Al Dev (Alavoor Vasudevan)
|
|
<htmlurl url="mailto:
|
|
alavoor[AT]yahoo.com
|
|
" name="
|
|
alavoor[AT]yahoo.com
|
|
">
|
|
<date>v5.3, 31 March 2003
|
|
|
|
<abstract>
|
|
This is a detailed guide to kernel configuration, compilation, upgrades,
|
|
and troubleshooting for ix86-based systems. Can be useful for other architectures
|
|
as well. This document is kept small & simple, so that even non-technical
|
|
"home computer users" will be able to compile and run the Linux Kernel.
|
|
</abstract>
|
|
|
|
<toc>
|
|
|
|
<sect> Introduction
|
|
<p>
|
|
You compile Linux kernel for one of following reasons:
|
|
<itemize>
|
|
<item> You are doing kernel development
|
|
<p>
|
|
<item> You are adding a new hardware to machine
|
|
<p>
|
|
<item> You want to customize the kernel and do not want the default kernel shipped out to you.
|
|
<p>
|
|
<item> For <bf>Defence Industries</bf> or <bf>Military applications</bf>, you must
|
|
read the kernel source code and compile with your own hands. No exceptions!!
|
|
(U.S Dept of Defence compiles the Linux kernel before distributing the computers).
|
|
<p>
|
|
<item> Every country and every Government in the world compiles the kernel on
|
|
site for security and integrity.
|
|
Every Government/Corporation audits and verifies each and every line of the OS kernel
|
|
source code before using the computer.
|
|
<p>
|
|
<item> Military Intelligence agencies around the world reads and compiles
|
|
the Linux kernel source code. They know what each and every line of Linux kernel
|
|
source code is doing!!
|
|
<p>
|
|
<item> If you compile the Linux kernel with your own hands, then it is
|
|
<bf>as good as reading and verifying</bf> all the kernel source code!
|
|
<p>
|
|
<item> Each and every University in the world compiles the OS kernel before using
|
|
any computer!
|
|
<p>
|
|
<item> For your education and knowledge of Linux kernel and ofcourse, just for fun!
|
|
<p>
|
|
<item> For very advanced scientific applications - you may need to do kernel compile
|
|
<p>
|
|
<item> It is an International Law (the U.N. laws) - "You cannot use a computer
|
|
WITHOUT compiling the OS kernel with your own hands". If you disobey this law
|
|
you will be "punished" with lot of computer problems!! You must compile the kernel
|
|
with your own hands and not rely on someone else to do it for you!!
|
|
<p>
|
|
<item> It is Illegal, Unlawful, Felony and Fraud to use a computer without
|
|
compiling the OS Kernel with your VERY OWN hands!
|
|
<p>
|
|
<item> In USA, all the corporations mandate compilation of OS kernel before using the
|
|
computer and hence there is Linux, Linux & Linux everywhere in United States!
|
|
<p>
|
|
<item> And for many hundreds of reasons - too numerous to list!
|
|
</itemize>
|
|
|
|
<p>
|
|
|
|
Note: This document is kept small & simple, so that even non-technical
|
|
"home computer users" will be able to compile and run the Linux Kernel!
|
|
|
|
|
|
|
|
|
|
|
|
<sect> Quick Steps - Kernel Compile
|
|
<p>
|
|
This section is written by
|
|
<htmlurl url="mailto:alavoor[AT]yahoo.com"
|
|
name="Al Dev (alavoor[AT]yahoo.com)">
|
|
(The <bf>latest version</bf> of this document is at
|
|
<url url="http://www.milkywaygalaxy.freeservers.com">.
|
|
You may want to check there for changes).
|
|
Mirror sites are at -
|
|
<url name="angelfire" url="http://www.angelfire.com/country/aldev0">,
|
|
<url name="geocities" url="http://www.geocities.com/alavoor/index.html">.
|
|
These sites have lot of linux goodies and tips.
|
|
|
|
Kernel re-compile is required in order to make the kernel very lean
|
|
and which will result in FASTER operating system . It is also
|
|
required to support any new devices.
|
|
|
|
|
|
|
|
<sect1> Precautionary Preparations<label id="precautions">
|
|
<p>
|
|
Before you build kernel, it is a good idea to do a backup of the system.
|
|
If you had not backed up your system recently then you can do it now.
|
|
You can use commercial backup tools like
|
|
<url name="BRS Backup-Recovery-Software" url="http://24.221.230.253"> (also
|
|
in this page you can find open-source/freeware backup tools listed under 'Backup and Restore Utility').
|
|
Backup is just a suggestion and it is not mandatory to do backup before
|
|
building the Linux kernel.
|
|
|
|
<sect1> Minor Upgrading of Kernel <label id="upgrading">
|
|
<p>
|
|
If you had already built the kernel and you want to upgrade to next patch release,
|
|
then you can simply copy the existing config file and reuse it.
|
|
(For example you have built kernel 2.4.19 and want to upgrade to 2.4.20).
|
|
<p>
|
|
<bf>For minor upgrades : </bf>
|
|
This step may save you time, if you want to reuse the old settings.
|
|
Whenever you install the kernel, generally you put the config file in /boot.
|
|
So, you can use the existing version of config file:
|
|
<code>
|
|
bash# mv /usr/src/linux/.config /usr/src/linux/.config.save
|
|
bash# cp /boot/config-2.4.18-19.8.0 /usr/src/linux/.config
|
|
</code>
|
|
Or another method is - you can copy the .config file from your old
|
|
linux kernel source tree
|
|
to new kernel tree.
|
|
<code>
|
|
bash# ls -l /usr/src/lin* # You can see that /usr/src/linux is a soft link
|
|
bash# cd /usr/src/linux
|
|
bash# cp ../linux-old-tree/.config . # Example cp ../linux-2.4.19/.config .
|
|
</code>
|
|
|
|
or one other method is - you can use "make oldconfig"
|
|
which default all questions based on the contents of your existing ./.config file.
|
|
<p>
|
|
|
|
NOTE: If you do not have lot of disk space in /usr/src then you can unpack the
|
|
kernel source package on any partition where you have free disk space (like /home).
|
|
Because kernel compile needs lot of disk space for object files like *.o.
|
|
For this reason the /usr/src/linux MUST be a soft link pointing to your source directory.
|
|
<p>
|
|
After this, look in the next section to do make and install.
|
|
|
|
|
|
|
|
<sect1> For the Impatient<label id="impatient">
|
|
<p>
|
|
<enum>
|
|
<item> Unpack the sources
|
|
<item> Optional - Copy config file : You can copy the config file from your
|
|
old linux kernel source tree
|
|
to new kernel tree (may save time, if you want to reuse the old settings).
|
|
<item> make clean; make mrproper
|
|
<item> make xconfig
|
|
<item> make dep
|
|
<item> Give a unique name to your new Kernel - Edit /usr/src/linux/Makefile
|
|
and change EXTRAVERSION
|
|
<item> nohup make bzImage
|
|
<item> 'make modules' and 'make modules_install'
|
|
<item> And you can go to lunch or go to bed (have nice Linux dreams in sleep)
|
|
and when you come back the system is ready! And see the log with 'less nohup.out'.
|
|
<item> make install # But NOT recommended - use cp /usr/src/linux/arch/i386/boot/bzImage /boot/bzImage.myker
|
|
<item> Configure GRUB or LILO.
|
|
<item> Reboot and check new kernel is booting
|
|
<item> Create emergency boot disk - bzdisk or mkbootdisk
|
|
<item> Optional - make rpm # To build rpm packages
|
|
<item> Optional - make clean (If you want to free up disk space)
|
|
</enum>
|
|
|
|
<!-- no need - use make rpm
|
|
On Redhat, instead of using 'make' commands you can use rpm command to build kernel.
|
|
If you want to build binary RPMs (kernel*.i386.rpm), do this:
|
|
<enum>
|
|
<item> Install kernel*.src.rpm
|
|
<item> cd /usr/src/redhat/SPECS
|
|
<item> rpmbuild -ba kernel*.spec # or rpm -ba kernel*.spec # for old systems
|
|
<item> cd /usr/src/redhat/i386; rpm -i kernel*.rpm
|
|
</enum>
|
|
-->
|
|
|
|
See details of above steps in the following sections....
|
|
|
|
|
|
|
|
<sect1> Building New Kernel - Explanation of Steps<label id="steps">
|
|
<p>
|
|
<bf>Details of the steps mentioned in the previous section: </bf>
|
|
|
|
<bf>Note: </bf> Below 'bash#' denotes the bash prompt, you should type
|
|
the commands that appear after the 'bash#' prompt. Below are commands
|
|
tested on Redhat Linux Kernel 2.4.7-10, but it should work for other distributions with
|
|
very minor changes. It should also work for older kernel versions like 2.2, 2.0 and 1.3.
|
|
It should also work for future or newer versions of kernel (with little changes - let me know).
|
|
|
|
<itemize>
|
|
<item> <bf>Note:</bf> You can have many kernel images on your system. By following the steps below
|
|
you do not overwrite or damage your existing kernel. These steps are <bf>very safe</bf>
|
|
and your current kernel will be intact and will not be touched.
|
|
</itemize>
|
|
|
|
<enum>
|
|
<item>
|
|
<bf>Unpack the sources: </bf>
|
|
Login in as 'root' throughout all these steps. Mount Redhat linux cdrom and install the linux kernel source rpm
|
|
<code>
|
|
bash$ su - root
|
|
bash# cd /mnt/cdrom/RedHat/RPMS
|
|
bash# rpm -i kernel-headers*.rpm
|
|
bash# rpm -i kernel-source*.rpm
|
|
bash# rpm -i dev86*.rpm
|
|
bash# rpm -i bin86*.rpm
|
|
</code>
|
|
(The bin86*.rpm and 'as86' is required only for <bf>OLDER Linux</bf> systems like Redhat 5.x.
|
|
Get Intel assembler 'as86' command from
|
|
dev86*.rpm on cdrom or from
|
|
<url name="bin86-mandrake" url="http://rpmfind.net/linux/RPM/mandrake/7.1/Mandrake/RPMS/bin86-0.4-12mdk.i586.html">
|
|
, <url name="bin86-kondara" url="http://rpmfind.net/linux/RPM/kondara/jirai/i586/bin86-0.4-8k.i586.html">
|
|
).
|
|
|
|
Also make sure that /usr/src/linux is soft link pointing to proper unpacked source.
|
|
<code>
|
|
bash# cd /usr/src
|
|
bash# ls -l # You should see that /usr/src/linux is soft link pointing to source
|
|
lrwxrwxrwx 1 root root 19 Jan 26 11:01 linux -> linux-2.4.18-19.8.0
|
|
drwxr-xr-x 17 root root 4096 Jan 25 21:08 linux-2.4.18-14
|
|
drwxr-xr-x 17 root root 4096 Mar 26 12:50 linux-2.4.18-19.8.0
|
|
drwxr-xr-x 7 root root 4096 Jan 14 16:32 redhat
|
|
</code>
|
|
If it is not a soft link then do rename /usr/src/linux to /usr/src/linux-2.4.yy and create
|
|
a soft link.
|
|
|
|
<p>
|
|
NOTE: If you do not have lot of disk space in /usr/src then you can unpack the
|
|
kernel source package on any partition where you have free disk space (like /home).
|
|
Because kernel compile needs lot of disk space for object files like *.o.
|
|
For this reason the /usr/src/linux MUST be a soft link pointing to your source directory.
|
|
<p>
|
|
<!-- intentional blank line with a period -->
|
|
<p>
|
|
|
|
<item>
|
|
<bf>Optional - Copy config file : </bf>
|
|
This step may save you time, if you want to reuse the old settings.
|
|
|
|
Whenever you install the kernel, generally you put the config file in /boot.
|
|
So, you can use the existing version of config file:
|
|
<code>
|
|
bash# mv /usr/src/linux/.config /usr/src/linux/.config.save
|
|
bash# cp /boot/config-2.4.18-19.8.0 /usr/src/linux/.config
|
|
</code>
|
|
Or another method is - you can copy the .config file from your old
|
|
linux kernel source tree
|
|
to new kernel tree
|
|
<code>
|
|
bash# ls -l /usr/src/lin* # You can see that /usr/src/linux is a soft link
|
|
bash# cd /usr/src/linux
|
|
bash# cp ../linux-old-tree/.config . # Example cp ../linux-2.4.19/.config .
|
|
</code>
|
|
|
|
or one other method is - you can use "make oldconfig"
|
|
which default all questions based on the contents of your existing ./.config file.
|
|
<p>
|
|
<!-- intentional blank line with a period -->
|
|
<p>
|
|
|
|
<item>
|
|
<bf>Clean : </bf>
|
|
Before doing mrproper below, you may want to backup the .config file.
|
|
<code>
|
|
bash# cd /usr/src/linux
|
|
bash# cp .config .config.save
|
|
bash# make clean
|
|
bash# make mrproper # Must do this if want to start clean slate or if you face lot of problems
|
|
</code>
|
|
|
|
<p>
|
|
|
|
<item>
|
|
<bf>Configure: </bf>
|
|
<itemize>
|
|
<item> Start X-windows with 'startx'. If you are not able to start X-window then
|
|
see next step below.
|
|
<code>
|
|
bash# man startx
|
|
bash# startx
|
|
bash# cd /usr/src/linux
|
|
bash# make xconfig
|
|
</code>
|
|
<item> If you are not able to start X-window above then try -
|
|
<code>
|
|
bash# export TERM=xterm
|
|
bash# make menuconfig
|
|
|
|
If you find scrambled display, then use different terminal emulators like vt100,
|
|
vt102, vt220 or ansi. The display will be scrambled and will have garbage
|
|
characters in cases where you use telnet to login to remote linux. In such
|
|
cases you should use the terminal emulators like vt100, vt220.
|
|
For example:
|
|
bash# export TERM=vt220
|
|
bash# export TERM=ansi
|
|
|
|
At a lower level of VT, use:
|
|
bash# export TERM=vt100
|
|
bash# make menuconfig
|
|
|
|
If the menuconfig command fails then try -
|
|
bash# make config
|
|
</code>
|
|
</itemize>
|
|
The <bf>"make xconfig" or "make menuconfig"</bf> brings up a user friendly GUI interface.
|
|
And <bf>"make config"</bf> brings up command-line console mode interface.
|
|
You can load the
|
|
configuration file from <it>/usr/src/linux/.config</it> (dot config file. Note the dot
|
|
before config). Click on button "Load Configuration from File".
|
|
<p>
|
|
|
|
Within 'make xconfig' you must do these (to avoid problems) -
|
|
<itemize>
|
|
<item> <bf>VERY IMPORTANT !!! : </bf> Select proper CPU type - Pentium 3, AMD K6,
|
|
Cyrix, Pentium 4, Intel 386, DEC Alpha, PowerPC otherwise kernel compile will fail
|
|
and even if it compiles, it will not boot!!
|
|
<item> Select SMP support - whether single CPU or multiple CPUs
|
|
<item> Filesystems - Select Windows95 Vfat, MSDOS, NTFS as part of kernel and
|
|
not as loadable modules. (My personal preference, but you are free to pick your own option).
|
|
<item> Enable the Loadable kernel modules support!
|
|
With this option you can load/unload the device drivers
|
|
dynamically on running linux system on the fly.
|
|
|
|
See the Modules chapter at <ref id="loadablemodules" name="Loadable Modules">.
|
|
|
|
</itemize>
|
|
<p>
|
|
|
|
Save and Exit "make xconfig".
|
|
All the options which you selected is now saved into configuration file
|
|
at <it>/usr/src/linux/.config</it> (dot config file).
|
|
|
|
<p>
|
|
|
|
<item>
|
|
<bf>Dep : </bf>
|
|
And now, do -
|
|
<code>
|
|
bash# make dep
|
|
</code>
|
|
|
|
<p>
|
|
|
|
|
|
<item>
|
|
<bf>Give a unique name to your new Kernel: </bf>
|
|
You can give a name to your kernel, so that it is unique and does not
|
|
interfere with others.
|
|
<code>
|
|
bash# cd /usr/src/linux
|
|
bash# vi Makefile
|
|
</code>
|
|
Here look for EXTRAVERSION = -19.8.0Blah_Blah_Blah
|
|
and change to something like EXTRAVERSION = -19.8.0MyKernel.26Jan2003
|
|
|
|
<p>
|
|
|
|
|
|
<item>
|
|
<bf>Do make: </bf>
|
|
Read the following file (to gain some knowledge about kernel building. Tip: Use
|
|
the color editor
|
|
<url name="gvim" url="http://www.linuxdoc.org/HOWTO/Vim-HOWTO.html">
|
|
for better readability.
|
|
<code>
|
|
bash# gvim -R /usr/src/linux/arch/i386/config.in
|
|
bash# man less
|
|
bash# less /usr/src/linux/arch/i386/config.in
|
|
Type 'h' for help and to navigate press i, j, k, l, h or arrow, page up/down keys.
|
|
</code>
|
|
<p>
|
|
|
|
Now, give the make command -
|
|
<code>
|
|
bash# cd /usr/src/linux
|
|
bash# man nohup
|
|
bash# nohup make bzImage &
|
|
bash# man tail
|
|
bash# tail -f nohup.out (.... to monitor the progress)
|
|
This will put the kernel in /usr/src/linux/arch/i386/boot/bzImage
|
|
</code>
|
|
|
|
|
|
<p>
|
|
<item>
|
|
<bf>LOADABLE MODULES: </bf>
|
|
Now, while the 'make' is cranking along in the previous step "Do make", you
|
|
should bring up another new xterm shell window and follow these steps:
|
|
|
|
This step is required <bf>ONLY if</bf> you had enabled Loadable module support in
|
|
step "Configure Step" above.
|
|
|
|
Loadable module are located in /lib/modules. You MUST do this step if you enabled or
|
|
disabled any modules, otherwise you will get 'unresolved symbols' errors during
|
|
or after kernel boot.
|
|
<code>
|
|
# Bring up a new Xterm shell window and ...
|
|
bash# cd /usr/src/linux
|
|
|
|
# Redirect outputs such that you do not overwrite the nohup.out which is still running...
|
|
bash# nohup make modules 1> modules.out 2> modules.err &
|
|
|
|
bash# make modules_install # Do this, only after the above make command is successful
|
|
</code>
|
|
This will copy the modules to /lib/modules directory.
|
|
|
|
See the Modules chapter at <ref id="loadablemodules" name="Loadable Modules">.
|
|
<p>
|
|
|
|
<item>
|
|
<bf>Now go to Lunch or Bed :</bf>
|
|
Since both the make windows are cranking along,
|
|
and now, you can go to lunch (chitchat, have nap) or go to
|
|
bed (have nice Linux dreams in sleep) and when you wake up and
|
|
come back the system is ready! You can check with
|
|
command 'less nohup.out' to see the log of output.
|
|
<code>
|
|
bash# cd /usr/src/linux
|
|
bash# less nohup.out
|
|
bash# less modules.err
|
|
bash# less modules.out
|
|
|
|
If no errors then do:
|
|
bash# make modules_install
|
|
</code>
|
|
|
|
|
|
<item>
|
|
<bf>bzImage: </bf>
|
|
After bzImage is successful, copy the kernel image to /boot directory.
|
|
You must copy the new kernel image to /boot directory, otherwise the
|
|
new kernel <bf>MAY NOT</bf> boot. You must also copy the config file to /boot area
|
|
to reflect the kernel image, for documentation purpose.
|
|
<code>
|
|
bash# cp /usr/src/linux/arch/i386/boot/bzImage /boot/bzImage.myker.26mar2001
|
|
|
|
# You MUST copy the config file to reflect the corresponding kernel image, for documentation purpose.
|
|
bash# cp /usr/src/linux/.config /boot/config-<your_kernelversion_date>
|
|
# Example: cp /usr/src/linux/.config /boot/config-2.4.18-19.8.0-26mar2001
|
|
</code>
|
|
|
|
<bf>NOTE : </bf>
|
|
If you are planning to use the initrd in LILO or GRUB then you may want to
|
|
build initrd and place it in /boot/initrd*.img.
|
|
See the Appendix A at <ref id="createinitrd" name="Creating initrd.img file">.
|
|
<p>
|
|
<!-- intentional blank line with a period -->
|
|
<p>
|
|
|
|
<item>
|
|
<bf>Configure GRUB or LILO : </bf>
|
|
There are two options for boot loading under Redhat Linux - GRUB and LILO.
|
|
<p>
|
|
|
|
<bf>Configure GRUB: </bf>
|
|
GRUB is recent and much better tool than LILO and it is my first preference to use GRUB.
|
|
LILO is an older technology.
|
|
GRUB differs from bootloaders such as LILO in that <it>"it can lie to MS Windows and make
|
|
MS Windows believe that it's installed on the first partition even if
|
|
it's not!!"</it>. So you can keep your current Linux system where it is and install
|
|
Windows on the side.
|
|
See the <ref id="grubconf" name="Appendix C - GRUB details and sample grub.conf"> file.
|
|
|
|
<p>
|
|
<p>
|
|
<bf>Configure LILO: </bf>
|
|
LILO is older tool and see the
|
|
<ref id="liloconf" name="Appendix B - Sample lilo.conf"> to configure LILO.
|
|
(see also <url url="http://www.linuxdoc.org/HOWTO/LILO-crash-rescue-HOWTO.html">)
|
|
|
|
|
|
|
|
<p>
|
|
<item> Reboot the machine and at lilo press tab key and
|
|
type 'myker' If it boots then you did a good job! Otherwise at lilo
|
|
select your old kernel, boot and re-try all over again. Your old kernel
|
|
<bf>is still INTACT and SAFE</bf> at say <it>/boot/vmlinuz-2.0.34-0.6</it>
|
|
|
|
|
|
<p>
|
|
<item> If your new kernel 'myker' boots and works properly, you can create the
|
|
boot disk. Insert a blank floppy into floppy drive and -
|
|
<code>
|
|
bash# cd /usr/src/linux
|
|
bash# make bzdisk
|
|
|
|
See also mkbootdisk -
|
|
bash# rpm -i mkbootdisk*.rpm
|
|
bash# man mkbootdisk
|
|
</code>
|
|
|
|
<p>
|
|
<item> Build RPMs
|
|
<p>
|
|
Optional - You can also build RPM packages of kernel, in case you want to install the
|
|
new image on several machines.
|
|
<code>
|
|
make rpm # To build rpm packages
|
|
</code>
|
|
|
|
|
|
<p>
|
|
<item>
|
|
<bf>Clean: </bf>
|
|
Optional - make clean (If you want to free up disk space)
|
|
<p>
|
|
</enum>
|
|
|
|
|
|
<sect1> Troubleshooting
|
|
<p>
|
|
Having any problems? See the <ref id="troubleshoot" name="troubleshooting chapter">.
|
|
|
|
|
|
|
|
<sect1> Post Kernel Building <label id="postkernel">
|
|
<p>
|
|
See the <ref id="postkernel" name="Appendix D - Post Kernel Building">.
|
|
|
|
|
|
|
|
|
|
<sect> Loadable Modules <label id="loadablemodules">
|
|
<p>
|
|
Loadable kernel modules can save memory and ease configuration. The scope
|
|
of modules has grown to include filesystems, ethernet card drivers, tape
|
|
drivers, printer drivers, and more.
|
|
|
|
Loadable modules are pieces of kernel code which are not
|
|
linked (included) directly in the kernel. One compiles them separately,
|
|
and can insert and remove them into the running kernel at almost any
|
|
time. Due to its flexibility, this is now the preferred way to code certain
|
|
kernel features. Many popular device drivers, such as the PCMCIA
|
|
drivers and the QIC-80/40 tape driver, are loadable modules.
|
|
<p>
|
|
|
|
See the Module-HOWTO at <url url="http://www.tldp.org/HOWTO/Module-HOWTO">.
|
|
|
|
And see these man pages
|
|
<code>
|
|
bash# rpm -i /mnt/cdrom/Redhat/RPMS/modutils*.rpm
|
|
bash# man lsmod
|
|
bash# man insmod
|
|
bash# man rmmod
|
|
bash# man depmod
|
|
bash# man modprobe
|
|
</code>
|
|
For example to load the module <tt>/lib/modules/2.4.2-2/kernel/drivers/block/loop.o</tt>,
|
|
you would do :
|
|
<code>
|
|
bash# man insmod
|
|
bash# modprobe loop
|
|
bash# insmod loop
|
|
bash# lsmod
|
|
</code>
|
|
You can set the PATH which the insmod searches in /etc/modules.conf.
|
|
|
|
|
|
<sect1>Installing the module utilities<p>
|
|
You can install the Module Utilities RPM with:
|
|
<code>
|
|
bash# rpm -i /mnt/cdrom/Redhat/RPMS/modutils*.rpm
|
|
</code>
|
|
|
|
<p>
|
|
<tt>insmod</tt> inserts a module into the running kernel. Modules
|
|
usually have a <tt>.o</tt> extension; the example driver mentioned above
|
|
is called <tt>drv_hello.o</tt>, so to insert this, one would say
|
|
`<tt>insmod drv_hello.o</tt>'. To see the modules that the kernel is
|
|
currently using, use <tt>lsmod</tt>. The output looks like this:
|
|
<verb>
|
|
blah# lsmod
|
|
Module: #pages: Used by:
|
|
drv_hello 1
|
|
</verb>
|
|
`<tt>drv_hello</tt>' is the name of the module, it uses one page (4k) of
|
|
memory, and no other kernel modules depend on it at the moment. To remove
|
|
this module, use `<tt>rmmod drv_hello</tt>'. Note that <tt>rmmod</tt>
|
|
wants a <it>module name,</it> not a filename; you get this from
|
|
<tt>lsmod</tt>'s listing. The other module utilities' purposes are documented
|
|
in their manual pages.
|
|
<p>
|
|
|
|
<sect1>Modules distributed with the kernel<p>
|
|
As of version 2.0.30, most of everything is available as a loadable
|
|
modules. To use
|
|
them, first make sure that you don't configure them into the regular
|
|
kernel; that is, don't say <tt>y</tt> to it during `<tt>make config</tt>'.
|
|
Compile a new kernel and reboot with it. Then, <tt>cd</tt> to
|
|
<tt>/usr/src/linux</tt> again, and do a `<tt>make modules</tt>'. This
|
|
compiles all of the modules which you did not specify in the kernel
|
|
configuration, and places links to them in <tt>/usr/src/linux/modules</tt>.
|
|
You can use them straight from that directory or execute `<tt>make
|
|
modules_install</tt>', which installs them in
|
|
<tt>/lib/modules/x.y.z</tt>, where <tt>x.y.z</tt> is the kernel release.
|
|
<p>
|
|
|
|
This can be especially handy with filesystems. You may not use the minix
|
|
or msdos filesystems frequently. For example, if I encountered an msdos
|
|
(shudder) floppy, I would <tt>insmod /usr/src/linux/modules/msdos.o</tt>,
|
|
and then <tt>rmmod msdos</tt> when finished. This procedure saves about
|
|
50k of RAM in the kernel during normal operation. A small note is in order for
|
|
the minix filesystem: you should <it>always</it> configure it directly into the
|
|
kernel for use in ``rescue'' disks.
|
|
<p>
|
|
|
|
|
|
|
|
<sect1> Howto Install Just A Single Module ?
|
|
<p>
|
|
Let us assume that you already did 'make modules' and 'make modules_install'.
|
|
And later you did 'make clean' to free up disk space. And now, you want to
|
|
change a "C" file in one of the modules and want to rebuild just that module
|
|
and copy the module file to /lib/modules. How do you do it?
|
|
|
|
You can compile just a single module file (say like foo.o) and install it.
|
|
For this simply edit the Makefile and change the SUBDIRS to add only those
|
|
directories you are interested.
|
|
|
|
For an example, if I am interested in installing only fs/autofs module, then I
|
|
do the following :
|
|
<code>
|
|
cd /usr/src/linux
|
|
cp Makefile Makefile.my
|
|
vi Makefile.my
|
|
# And comment out the line having 'SUBDIRS' and add the
|
|
# directory you are interested, for example like fs/autofs as below :
|
|
#SUBDIRS =kernel drivers mm fs net ipc lib abi crypto
|
|
SUBDIRS =fs/autofs
|
|
# Save the file Makefile.my and give -
|
|
make -f Makefile.my modules
|
|
# This will create module autofs.o
|
|
|
|
# Now, copy the module object file to destination /lib/modules
|
|
make -f Makefile.my modules_install
|
|
# And this will do 'cp autofs.o /lib/modules/2.4.18-19.8.0/kernel/fs/autofs'
|
|
</code>
|
|
|
|
<!-- Adding or changing a variable in gnu make:
|
|
make TOPDIR=/usr/src/linux
|
|
# Another Method: Check with dry run option
|
|
make -n modules > dryrun.txt
|
|
-->
|
|
|
|
Learn more about Makefile and make. See the manual for GNU make at
|
|
<itemize>
|
|
<item> <url url="http://www.gnu.org/manual/make">.
|
|
<item> University of Utah Makefile
|
|
<url url="http://www.math.utah.edu/docs/info/make-stds_toc.html">
|
|
<item> University of Hawaii Makefile <url url="http://www.eng.hawaii.edu/Tutor/Make">
|
|
<item> In Linux - man make
|
|
<item> In Linux - info make
|
|
</itemize>
|
|
|
|
|
|
Get familiar with the Makefile which makes the modules. The Makefile has module line like
|
|
<code>
|
|
modules: $(patsubst %, _mod_%, $(SUBDIRS))
|
|
</code>
|
|
|
|
The patsubst function has the syntax $(patsubst pattern,replacement,text). It uses the
|
|
percent symbol (%) the same way pattern rules do - as a string which matches in both
|
|
the pattern and the replacement text. It searches the text for whitespace-separated
|
|
words that match the pattern and substitutes the replacement for them.
|
|
|
|
This makefile includes shell functions as well as standard make functions. The syntax
|
|
for a shell function is $(shell command). This returns the output of the shell
|
|
function (stripping new lines).
|
|
|
|
|
|
|
|
<sect> Cloning of Linux Kernels <label id="cloning">
|
|
<p>
|
|
You may want to build a Linux kernel on a system and then you may want to
|
|
mass deploy to many identical hardware PCs. To make it easy to install
|
|
your newly built kernel on hundreds of other systems, you may want to
|
|
package it in RPMs (Redhat) or DEB package (Debian) or just tar.gz files.
|
|
|
|
<enum>
|
|
<item> Build a kernel rpm package with rpmbuild -ba kernel*.spec
|
|
<p>
|
|
<item> Check that the kernel*.rpm generated has all the files in
|
|
/lib/modules/2.x.x-y directory. Otherwise you may want to tar gzip the
|
|
directory /lib/modules/2.x.x-y and take it to destination machines.
|
|
<p>
|
|
<item> Check that your kernel package has /boot/initrd-2.x.x-y.img file,
|
|
otherwise you may want to tar gzip and take it to destination machines.
|
|
<p>
|
|
<item> And other files in /boot which are not in the kernel*.rpm package.
|
|
<p>
|
|
</enum>
|
|
|
|
|
|
|
|
|
|
<sect>Important questions and their answers
|
|
<p>
|
|
|
|
<sect1>What does the kernel do, anyway? <p>
|
|
|
|
The Unix kernel acts as a mediator for your programs and your hardware.
|
|
First, it does (or arranges for) the memory management for all of the
|
|
running programs (processes), and makes sure that they all get a fair (or
|
|
unfair, if you please) share of the processor's cycles. In addition, it
|
|
provides a nice, fairly portable interface for programs to talk to your
|
|
hardware.
|
|
<p>
|
|
|
|
There is certainly more to the kernel's operation than this, but these
|
|
basic functions are the most important to know.
|
|
<p>
|
|
|
|
<sect1>Why would I want to upgrade my kernel? <p>
|
|
|
|
Newer kernels generally offer the ability to talk to more types of
|
|
hardware (that is, they have more device drivers), they can have better
|
|
process management, they can run faster than the older versions, they
|
|
could be more stable than the older versions, and they fix silly bugs in
|
|
the older versions. Most people upgrade kernels because they want the
|
|
device drivers and the bug fixes.
|
|
<p>
|
|
|
|
<sect1>What kind of hardware do the newer kernels support? <p>
|
|
|
|
See the
|
|
<url name="Hardware-HOWTO" url="http://www.tldp.org/HOWTO/Hardware-HOWTO">
|
|
. Alternatively, you can look at the
|
|
`<tt>config.in</tt>' file in the linux source, or just find out
|
|
when you try `<tt>make config</tt>'.
|
|
This shows you all hardware supported by the
|
|
standard kernel distribution, but not everything that linux supports; many
|
|
common device drivers (such as the PCMCIA drivers and some tape drivers) are
|
|
loadable modules maintained and distributed separately.
|
|
<p>
|
|
|
|
<sect1>What version of gcc and libc do I need? <p>
|
|
|
|
Linus recommends a version of gcc in the <tt>README</tt> file included with
|
|
the linux source. If you don't have this version, the documentation in the
|
|
recommended version of gcc should tell you if you need to upgrade your libc.
|
|
This is not a difficult procedure, but it is important to follow the
|
|
instructions.
|
|
<p>
|
|
|
|
<sect1>What's a loadable module? <p>
|
|
|
|
See the Modules chapter at <ref id="loadablemodules" name="Loadable Modules">.
|
|
|
|
<p>
|
|
|
|
<sect1>How much disk space do I need? <p>
|
|
|
|
It depends on your particular system configuration. First, the compressed
|
|
linux source is nearly 14 megabytes large at version 2.2.9. Many sites keep
|
|
this even after unpacking.
|
|
Uncompressed and built with a moderate configuration, it takes up another 67
|
|
MB.
|
|
<p>
|
|
|
|
<sect1>How long does it take? <p>
|
|
With newer machines, the compilation takes dramatically less time than
|
|
older ones; an AMD K6-2/300 with a fast disk can do a 2.2.x kernel in about
|
|
four minutes. As for old Pentiums, 486s, and 386s, if you plan to compile
|
|
one, be prepared to wait, possibly hours, days..
|
|
<p>
|
|
If this troubles you, and you happen to have a faster machine around to
|
|
compile on, you can build on the fast machines (assuming you give it the
|
|
right parameters, that your ulilities are up-to-date, and so on), and then
|
|
transfer the kernel image to the slower machine.
|
|
<p>
|
|
|
|
|
|
|
|
<sect>Patching the kernel <p>
|
|
|
|
<sect1>Applying a patch <p>
|
|
|
|
Incremental upgrades of the kernel are distributed as patches. For
|
|
example, if you have Linux v1.1.45, and you notice that there's a
|
|
`<tt>patch46.gz</tt>' out there for it, it means you can upgrade to version
|
|
1.1.46 through application of the patch. You might want to make a backup of the
|
|
source tree first (`<tt>make clean</tt>' and then
|
|
`<tt>cd /usr/src; tar zcvf old-tree.tar.gz linux</tt>'
|
|
will make a compressed tar archive for you.).
|
|
<p>
|
|
|
|
So, continuing with the example above, let's suppose that
|
|
you have `<tt>patch46.gz</tt>' in <tt>/usr/src</tt>. <tt>cd</tt> to
|
|
<tt>/usr/src</tt> and do a `<tt>zcat patch46.gz | patch -p0</tt>'
|
|
(or `<tt>patch -p0 < patch46</tt>'
|
|
if the patch isn't compressed). You'll see things whizz by
|
|
(or flutter by, if your
|
|
system is that slow) telling you that it is trying to apply hunks,
|
|
and whether it succeeds or not. Usually, this action goes by too quickly for
|
|
you to read, and you're not too sure whether it worked or not, so you might
|
|
want to use the <tt>-s</tt> flag to <tt>patch</tt>, which tells <tt>patch</tt>
|
|
to only report error messages (you don't get as much of the ``hey, my
|
|
computer is actually doing something for a change!'' feeling, but you may
|
|
prefer this..). To look for
|
|
parts which might not have gone smoothly, cd to <tt>/usr/src/linux</tt> and
|
|
look for files with a <tt>.rej</tt> extension. Some versions of <tt>patch</tt>
|
|
(older versions which may have been compiled with on an inferior
|
|
filesystem) leave the rejects with a <tt>#</tt> extension. You can use
|
|
`<tt>find</tt>' to look for you;
|
|
<verb>
|
|
find . -name '*.rej' -print
|
|
</verb>
|
|
prints all files who live in the current directory or any subdirectories with
|
|
a <tt>.rej</tt> extension to the standard output.
|
|
<p>
|
|
|
|
If everything went right, do a `<tt>make clean</tt>', `<tt>config</tt>',
|
|
and `<tt>dep</tt>' as described in sections 3 and 4.
|
|
<p>
|
|
|
|
There are quite a few options to the <tt>patch</tt> command. As mentioned
|
|
above, <tt>patch -s</tt>
|
|
will suppress all messages except the errors. If you keep your kernel
|
|
source in some other place than <tt>/usr/src/linux</tt>, <tt>patch -p1</tt>
|
|
(in that directory) will patch things cleanly. Other <tt>patch</tt> options are
|
|
well-documented in the manual page.
|
|
<p>
|
|
|
|
<sect1>If something goes wrong <p>
|
|
|
|
(Note: this section refers mostly to quite old kernels)<p>
|
|
|
|
The most frequent problem that used to arise was when a patch modified
|
|
a file called `<tt>config.in</tt>' and it didn't look quite right,
|
|
because you changed the options to suit your machine. This has been
|
|
taken care of, but one still might encounter it with an older release.
|
|
To fix it, look at the <tt>config.in.rej</tt> file, and see what remains
|
|
of the original patch.
|
|
The changes will typically be marked with `<tt>+</tt>' and `<tt>-</tt>'
|
|
at the beginning of the
|
|
line. Look at the lines surrounding it, and remember if they were set to
|
|
`<tt>y</tt>' or `<tt>n</tt>'. Now, edit <tt>config.in</tt>, and change
|
|
`<tt>y</tt>' to `<tt>n</tt>' and `<tt>n</tt>' to `<tt>y</tt>'
|
|
when appropriate. Do a
|
|
<verb>
|
|
patch -p0 < config.in.rej
|
|
</verb>
|
|
and if it reports that it
|
|
succeeded (no fails), then you can continue on with a configuration and
|
|
compilation. The <tt>config.in.rej</tt> file will remain, but you can get
|
|
delete it.
|
|
<p>
|
|
|
|
If you encounter further problems, you might have installed a patch out
|
|
of order. If patch says `<tt>previously applied patch detected: Assume
|
|
-R?</tt>', you are probably trying to apply a patch which is below your current
|
|
version number; if you answer `<tt>y</tt>', it will attempt to degrade
|
|
your source, and will most likely fail; thus, you will need to get a whole new
|
|
source tree (which might not have been such a bad idea in the first place).
|
|
<p>
|
|
|
|
To back out (unapply) a patch, use `<tt>patch -R</tt>' on the original patch.
|
|
<p>
|
|
|
|
The best thing to do when patches really turn out wrong is to start over
|
|
again with a clean, out-of-the-box source tree (for example, from one
|
|
of the <tt>linux-x.y.z.tar.gz</tt> files), and start again.
|
|
<p>
|
|
|
|
<sect1>Getting rid of the .orig files <p>
|
|
|
|
After just a few patches, the <tt>.orig</tt> files will start to pile up. For
|
|
example, one 1.1.51 tree I had was once last cleaned out at 1.1.48.
|
|
Removing the .orig files saved over a half a meg.
|
|
<verb>
|
|
find . -name '*.orig' -exec rm -f {} ';'
|
|
</verb>
|
|
will take care of it for you. Versions of <tt>patch</tt> which use
|
|
<tt>#</tt> for rejects use a tilde instead of <tt>.orig</tt>.
|
|
<p>
|
|
There are better ways to get rid of the <tt>.orig</tt> files, which
|
|
depend on GNU <tt>xargs</tt>:
|
|
<verb>
|
|
find . -name '*.orig' | xargs rm
|
|
</verb>
|
|
or the ``quite secure but a little more verbose'' method:
|
|
<verb>
|
|
find . -name '*.orig' -print0 | xargs --null rm --
|
|
</verb>
|
|
<p>
|
|
|
|
<sect1>Other patches <p>
|
|
|
|
There are other patches (I'll call them ``nonstandard'') than the
|
|
ones Linus distributes. If you apply these, Linus' patches may not work
|
|
correctly and you'll have to either back them out, fix the source or
|
|
the patch, install a new source tree, or a combination of the above. This
|
|
can become very frustrating, so if you do not want to modify the source (with
|
|
the possibility of a very bad outcome), back
|
|
out the nonstandard patches before applying Linus', or just install a new
|
|
tree. Then, you can see
|
|
if the nonstandard patches still work. If they don't, you are either
|
|
stuck with an old kernel, playing with the patch or source to
|
|
get it to work, or waiting (possibly begging) for a new version of
|
|
the patch to come out.
|
|
<p>
|
|
|
|
How common are the patches not in the standard distribution? You will
|
|
probably hear of them. I used to use the noblink patch
|
|
for my virtual consoles because I hate blinking cursors (This patch
|
|
is (or at least was) frequently updated for new kernel releases.). With
|
|
most newer device drivers being developed as loadable modules, though, the
|
|
frequecy of ``nonstandard'' patches is decreasing significantly.
|
|
<p>
|
|
|
|
|
|
|
|
<sect>Tips and tricks <p>
|
|
|
|
<sect1>Redirecting output of the make or patch commands <p>
|
|
|
|
If you would like logs of what those `<tt>make</tt>' or `<tt>patch</tt>'
|
|
commands did, you can redirect output to a file. First,
|
|
find out what shell you're running:
|
|
`<tt>grep root /etc/passwd</tt>' and look for something like
|
|
`<tt>/bin/csh</tt>'.
|
|
<p>
|
|
|
|
If you use sh or bash,
|
|
<verb>
|
|
(command) 2>&1 | tee (output file)
|
|
</verb>
|
|
will place a copy of <tt>(command)</tt>'s output in the
|
|
file `<tt>(output file)</tt>'.
|
|
<p>
|
|
|
|
For csh or tcsh, use
|
|
<verb>
|
|
(command) |& tee (output file)
|
|
</verb>
|
|
<p>
|
|
|
|
For rc (Note: you probably do not use rc) it's
|
|
<verb>
|
|
(command) >[2=1] | tee (output file)
|
|
</verb>
|
|
<p>
|
|
|
|
<sect1>Conditional kernel install <p>
|
|
Other than using floppy disks, there are several methods of testing out a new
|
|
kernel without touching the old one. Unlike many other Unix flavors, LILO has
|
|
the ability to boot a kernel from anywhere on the disk (if you have a
|
|
large (500 MB or above) disk, please read over the LILO documentation on
|
|
how this may cause problems). So, if you add something similar to
|
|
<verb>
|
|
image = /usr/src/linux/arch/i386/boot/bzImage
|
|
label = new_kernel
|
|
</verb>
|
|
to the end of your LILO configuration file, you can choose to run a newly
|
|
compiled kernel without touching your old <tt>/vmlinuz</tt> (after running
|
|
<tt>lilo</tt>, of course). The easiest way to tell LILO to boot a new
|
|
kernel is to press the shift key at bootup time (when it says
|
|
<tt>LILO</tt> on the screen, and nothing else), which gives you a prompt.
|
|
At this point, you can enter `<tt>new_kernel</tt>' to boot the new kernel.
|
|
<p>
|
|
If you wish to keep several different kernel source trees on your system at
|
|
the same time (this can take up a <it>lot</it> of disk space; be careful), the
|
|
most common way is to name them <tt>/usr/src/linux-x.y.z</tt>, where
|
|
<tt>x.y.z</tt> is the kernel version. You can then ``select'' a source
|
|
tree with a symbolic link; for example, `<tt>ln -sf linux-1.2.2
|
|
/usr/src/linux</tt>' would make the 1.2.2 tree current. Before creating a
|
|
symbolic link like this, make certain that the last argument to
|
|
<tt>ln</tt> is not a real directory (old symbolic links are fine); the
|
|
result will not be what you expect.
|
|
<p>
|
|
|
|
<sect1>Kernel updates <p>
|
|
Russell Nelson (<tt>nelson@crynwr.com</tt>) summarizes the changes in new
|
|
kernel releases. These are short, and you might like to look at them
|
|
before an upgrade. They are available with anonymous ftp from
|
|
<url url="ftp://ftp.emlist.com"> in <tt>pub/kchanges</tt> or through the URL
|
|
<url url="http://www.crynwr.com/kchanges">
|
|
<p>
|
|
|
|
<sect> Linux Kernel Textbooks and Documents
|
|
<p>
|
|
Check the following books on "The Linux Kernel" at
|
|
<itemize>
|
|
<item> Kernel book <url url="http://kernelbook.sourceforge.net">
|
|
and at <url url="http://sourceforge.net/projects/kernelbook">
|
|
<item> Linux Kernel books <url url="http://www.tldp.org/guides.html">
|
|
<item> FreeTech books <url url="http://www.tcfb.com/freetechbooks/booklinuxdev.html">
|
|
<item> Rusty's <url url="http://www.netfilter.org/unreliable-guides">
|
|
<item> Linux Kernel links <url url="http://www.topology.org/soft/lkernel.html">
|
|
<item> Linux Kernel Internals <url url="http://www.moses.uklinux.net/patches/lki.html">
|
|
<item> Books links <url url="http://linux-mm.org/kernel-links.shtml">
|
|
</itemize>
|
|
|
|
Refer also to other relevant HOWTOs at:
|
|
<itemize>
|
|
<item> Sound-HOWTO: sound cards and utilities
|
|
<item> SCSI-HOWTO: all about SCSI controllers and devices
|
|
<item> NET-2-HOWTO: networking
|
|
<item> PPP-HOWTO: PPP networking in particular
|
|
<item> PCMCIA-HOWTO: about the drivers for your notebook
|
|
<item> ELF-HOWTO: ELF: what it is, converting..
|
|
<item> Hardware-HOWTO: overview of supported hardware
|
|
<item> Module mini-HOWTO: more on kernel modules
|
|
<item> Kerneld mini-HOWTO: about kerneld
|
|
<item> BogoMips mini-HOWTO: in case you were wondering
|
|
</itemize>
|
|
|
|
|
|
|
|
<sect> Kernel Files Information <label id="kernelinfo">
|
|
<p>
|
|
This section gives a "very brief" and "introduction" to some of the Linux Kernel System.
|
|
If you have time you can give one reading.
|
|
|
|
<sect1> vmlinuz and vmlinux <label id="vmlinuz">
|
|
<p>
|
|
The vmlinuz is the Linux kernel executable. This is located at /boot/vmlinuz.
|
|
This can be a soft link to something like /boot/vmlinuz-2.4.18-19.8.0
|
|
|
|
The vmlinux is the uncompressed built kernel, vmlinuz is the compressed one,
|
|
that has been made bootable. (Note both names vmlinux and vmlinuz look same except for
|
|
last letter z).
|
|
Generally, you don't need to worry about vmlinux, it is just an intermediate step.
|
|
|
|
|
|
The kernel usually makes a bzImage, and stores it in arch/i386/boot, and it
|
|
is up to the user to copy it to /boot and configure GRUB or LILO.
|
|
|
|
|
|
<sect1> Bootloader Files <label id="bootload">
|
|
<p>
|
|
<code>
|
|
ls -l /boot/*.b
|
|
-rw-r--r-- 1 root root 5824 Sep 5 2002 /boot/boot.b
|
|
-rw-r--r-- 1 root root 612 Sep 5 2002 /boot/chain.b
|
|
-rw-r--r-- 1 root root 640 Sep 5 2002 /boot/os2_d.b
|
|
</code>
|
|
the .b files are "bootloader" files. they are part of the dance required to
|
|
get a kernel into memory to begin with. You should NOT touch them.
|
|
|
|
<sect1> Message File
|
|
<p>
|
|
<code>
|
|
ls -l /boot/message*
|
|
-rw-r--r-- 1 root root 23108 Sep 6 2002 /boot/message
|
|
-rw-r--r-- 1 root root 21282 Sep 6 2002 /boot/message.ja
|
|
</code>
|
|
The 'message' file contains the message your bootloader will display, prompting you to
|
|
choose an OS. So DO NOT touch it.
|
|
|
|
|
|
|
|
|
|
<sect1> initrd.img <label id="initrdimg">
|
|
<p>
|
|
See the Appendix A at <ref id="createinitrd" name="Description of initrd.img file">.
|
|
|
|
|
|
<sect1> bzImage <label id="bzImagelbl">
|
|
<p>
|
|
The bzImage is the compressed kernel image created with command 'make bzImage'
|
|
during kernel compile.
|
|
|
|
|
|
<sect1> module-info <label id="moduleinfo">
|
|
<p>
|
|
This is created by utils/modlist.
|
|
|
|
|
|
<sect1> config <label id="configfiles">
|
|
<p>
|
|
Everytime you compile and install the kernel image in /boot, you should
|
|
also copy the corresponding config file to /boot area, for documentation
|
|
and future reference. Do NOT touch or edit these files!!
|
|
<code>
|
|
ls -l /boot/config-*
|
|
-rw-r--r-- 1 root root 42111 Sep 4 2002 /boot/config-2.4.18-14
|
|
-rw-r--r-- 1 root root 42328 Jan 26 01:29 /boot/config-2.4.18-19.8.0
|
|
-rw-r--r-- 1 root root 51426 Jan 25 22:21 /boot/config-2.4.18-19.8.0BOOT
|
|
-rw-r--r-- 1 root root 52328 Jan 28 03:22 /boot/config-2.4.18-19.8.0-26mar2003
|
|
</code>
|
|
|
|
|
|
|
|
<sect1> System.map <label id="systemmap">
|
|
<p>
|
|
System.map is a "phone directory" list of function in a particular build of
|
|
a kernel. It is typically a symlink to the System.map of the currently
|
|
running kernel. If you use the wrong (or no) System.map, debugging crashes
|
|
is harder, but has no other effects. Without System.map, you may face
|
|
minor annoyance messages.
|
|
|
|
Do NOT touch the System.map files.
|
|
<code>
|
|
ls -ld /boot/System.map*
|
|
lrwxrwxrwx 1 root root 30 Jan 26 19:26 /boot/System.map -> System.map-2.4.18-19.8.0custom
|
|
-rw-r--r-- 1 root root 501166 Sep 4 2002 /boot/System.map-2.4.18-14
|
|
-rw-r--r-- 1 root root 510786 Jan 26 01:29 /boot/System.map-2.4.18-19.8.0
|
|
-rw-r--r-- 1 root root 331213 Jan 25 22:21 /boot/System.map-2.4.18-19.8.0BOOT
|
|
-rw-r--r-- 1 root root 503246 Jan 26 19:26 /boot/System.map-2.4.18-19.8.0custom
|
|
</code>
|
|
|
|
<bf>How The Kernel Symbol Table Is Created ? </bf>
|
|
System.map is produced by 'nm vmlinux' and irrelevant or uninteresting symbols are grepped out,
|
|
When you compile the kernel, this file 'System.map' is created at /usr/src/linux/System.map.
|
|
Something like below:
|
|
<code>
|
|
nm /boot/vmlinux-2.4.18-19.8.0 > System.map
|
|
|
|
# Below is the line from /usr/src/linux/Makefile
|
|
nm vmlinux | grep -v '\(compiled\)\|\(\.o$$\)\|\( [aUw] \)\|\(\.\.ng$$\)\|\(LASH[RL]DI\)' | sort > System.map
|
|
cp /usr/src/linux/System.map /boot/System.map-2.4.18-14 # For v2.4.18
|
|
</code>
|
|
|
|
From <url url="http://www.dirac.org/linux/systemmap.html">
|
|
|
|
|
|
<sect2>
|
|
System.map
|
|
<p>
|
|
There seems to be a dearth of information about the System.map file. It's
|
|
really nothing mysterious, and in the scheme of things, it's really not that
|
|
important. But a lack of documentation makes it shady. It's like an earlobe; we
|
|
all have one, but nobody really knows why. This is a little web page I cooked
|
|
up that explains the why.
|
|
|
|
Note, I'm not out to be 100% correct. For instance, it's possible for a system
|
|
to not have /proc filesystem support, but most systems do. I'm going to assume
|
|
you "go with the flow" and have a fairly typical system.
|
|
|
|
Some of the stuff on oopses comes from Alessandro Rubini's "Linux Device
|
|
Drivers" which is where I learned most of what I know about kernel programming.
|
|
|
|
<sect2>
|
|
What Are Symbols?
|
|
<p>
|
|
In the context of programming, a symbol is the building block of a program: it
|
|
is a variable name or a function name. It should be of no surprise that the
|
|
kernel has symbols, just like the programs you write. The difference is, of
|
|
course, that the kernel is a very complicated piece of coding and has many,
|
|
many global symbols.
|
|
|
|
|
|
<sect2>
|
|
What Is The Kernel Symbol Table?
|
|
<p>
|
|
The kernel doesn't use symbol names. It's much happier knowing a variable or
|
|
function name by the variable or function's address. Rather than using size_t
|
|
BytesRead, the kernel prefers to refer to this variable as (for example)
|
|
c0343f20.
|
|
|
|
Humans, on the other hand, do not appreciate names like c0343f20. We prefer to
|
|
use something like size_t BytesRead. Normally, this doesn't present much of a
|
|
problem. The kernel is mainly written in C, so the compiler/linker allows us to
|
|
use symbol names when we code and allows the kernel to use addresses when it
|
|
runs. Everyone is happy.
|
|
|
|
There are situations, however, where we need to know the address of a symbol
|
|
(or the symbol for an address). This is done by a symbol table, and is very
|
|
similar to how gdb can give you the function name from a address (or an address
|
|
from a function name). A symbol table is a listing of all symbols along with
|
|
their address. Here is an example of a symbol table:
|
|
|
|
<code>
|
|
c03441a0 B dmi_broken
|
|
c03441a4 B is_sony_vaio_laptop
|
|
c03441c0 b dmi_ident
|
|
c0344200 b pci_bios_present
|
|
c0344204 b pirq_table
|
|
c0344208 b pirq_router
|
|
c034420c b pirq_router_dev
|
|
c0344220 b ascii_buffer
|
|
c0344224 b ascii_buf_bytes
|
|
</code>
|
|
|
|
|
|
You can see that the variable named dmi_broken is at the kernel address
|
|
c03441a0.
|
|
|
|
<sect2>
|
|
What Is The System.map File?
|
|
<p>
|
|
There are 2 files that are used as a symbol table:
|
|
<enum>
|
|
<item> /proc/ksyms
|
|
<item> System.map
|
|
</enum>
|
|
|
|
There. You now know what the System.map file is.
|
|
|
|
Every time you compile a new kernel, the addresses of various symbol names are
|
|
bound to change.
|
|
|
|
/proc/ksyms is a "proc file" and is created on the fly when a kernel boots up.
|
|
Actually, it's not really a file; it's simply a representation of kernel data
|
|
which is given the illusion of being a disk file. If you don't believe me, try
|
|
finding the filesize of /proc/ksyms. Therefore, it will always be correct for
|
|
the kernel that is currently running..
|
|
|
|
However, System.map is an actual file on your filesystem. When you compile a
|
|
new kernel, your old System.map has wrong symbol information. A new System.map
|
|
is generated with each kernel compile and you need to replace the old copy with
|
|
your new copy.
|
|
|
|
|
|
<sect2>
|
|
What Is An Oops?
|
|
<p>
|
|
What is the most common bug in your homebrewed programs? The segfault. Good ol'
|
|
signal 11.
|
|
|
|
What is the most common bug in the Linux kernel? The segfault. Except here, the
|
|
notion of a segfault is much more complicated and can be, as you can imagine,
|
|
much more serious. When the kernel dereferences an invalid pointer, it's not
|
|
called a segfault -- it's called an "oops". An oops indicates a kernel bug and
|
|
should always be reported and fixed.
|
|
|
|
Note that an oops is not the same thing as a segfault. Your program cannot
|
|
recover from a segfault. The kernel doesn't necessarily have to be in an
|
|
unstable state when an oops occurs. The Linux kernel is very robust; the oops
|
|
may just kill the current process and leave the rest of the kernel in a good,
|
|
solid state.
|
|
|
|
An oops is not a kernel panic. In a panic, the kernel cannot continue; the
|
|
system grinds to a halt and must be restarted. An oops may cause a panic if a
|
|
vital part of the system is destroyed. An oops in a device driver, for example,
|
|
will almost never cause a panic.
|
|
|
|
When an oops occurs, the system will print out information that is relevent to
|
|
debugging the problem, like the contents of all the CPU registers, and the
|
|
location of page descriptor tables. In particular, the contents of the EIP
|
|
(instruction pointer) is printed. Like this:
|
|
<code>
|
|
EIP: 0010:[<00000000>]
|
|
Call Trace: [<c010b860>]
|
|
</code>
|
|
|
|
|
|
|
|
<sect2>
|
|
What Does An Oops Have To Do With System.map?
|
|
<p>
|
|
You can agree that the information given in EIP and Call Trace is not very
|
|
informative. But more importantly, it's really not informative to a kernel
|
|
developer either. Since a symbol doesn't have a fixed address, c010b860 can
|
|
point anywhere.
|
|
|
|
To help us use this cryptic oops output, Linux uses a daemon called klogd, the
|
|
kernel logging daemon. klogd intercepts kernel oopses and logs them with
|
|
syslogd, changing some of the useless information like c010b860 with
|
|
information that humans can use. In other words, klogd is a kernel message
|
|
logger which can perform name-address resolution. Once klogd tranforms the
|
|
kernel message, it uses whatever logger is in place to log system wide
|
|
messages, usually syslogd.
|
|
|
|
To perform name-address resolution, klogd uses System.map. Now you know what an
|
|
oops has to do with System.map.
|
|
|
|
<bf>Fine print:</bf> There are actually two types of address resolution are performed by
|
|
klogd.
|
|
|
|
<itemize>
|
|
<item> Static translation, which uses the System.map file.
|
|
<item> Dynamic translation which is used with loadable modules, doesn't use
|
|
</itemize>
|
|
|
|
System.map and is therefore not relevant to this discussion, but I'll describe
|
|
it briefly anyhow.
|
|
|
|
<bf>Klogd Dynamic Translation </bf>
|
|
|
|
Suppose you load a kernel module which generates an oops. An oops message is
|
|
generated, and klogd intercepts it. It is found that the oops occured at
|
|
d00cf810. Since this address belongs to a dynamically loaded module, it has no
|
|
entry in the System.map file. klogd will search for it, find nothing, and
|
|
conclude that a loadable module must have generated the oops. klogd then
|
|
queries the kernel for symbols that were exported by loadable modules. Even if
|
|
the module author didn't export his symbols, at the very least, klogd will know
|
|
what module generated the oops, which is better than knowing nothing about the
|
|
oops at all.
|
|
|
|
There's other software that uses System.map, and I'll get into that shortly.
|
|
|
|
<sect2>
|
|
Where Should System.map Be Located?
|
|
<p>
|
|
System.map should be located wherever the software that uses it looks for it.
|
|
That being said, let me talk about where klogd looks for it. Upon bootup, if
|
|
klogd isn't given the location of System.map as an argument, it will look for
|
|
System.map in 3 places, in the following order:
|
|
<enum>
|
|
<item> /boot/System.map
|
|
<item> /System.map
|
|
<item> /usr/src/linux/System.map
|
|
</enum>
|
|
|
|
System.map also has versioning information, and klogd intelligently searches
|
|
for the correct map file. For instance, suppose you're running kernel 2.4.18
|
|
and the associated map file is /boot/System.map. You now compile a new kernel
|
|
2.5.1 in the tree /usr/src/linux. During the compiling process, the file
|
|
/usr/src/linux/System.map is created. When you boot your new kernel, klogd will
|
|
first look at /boot/System.map, determine it's not the correct map file for the
|
|
booting kernel, then look at /usr/src/linux/System.map, determine that it is
|
|
the correct map file for the booting kernel and start reading the symbols.
|
|
|
|
A few nota bene's:
|
|
|
|
<itemize>
|
|
<item> Somewhere during the 2.5.x series, the Linux kernel started to untar into
|
|
linux-version, rather than just linux (show of hands -- how many people have
|
|
been waiting for this to happen?). I don't know if klogd has been modified to
|
|
search in /usr/src/linux-version/System.map yet. TODO: Look at the klogd
|
|
srouce. If someone beats me to it, please email me and let me know if klogd has
|
|
been modified to look in the new directory name for the linux source code.
|
|
<item> The man page doesn't tell the whole the story. Look at this:
|
|
</itemize>
|
|
|
|
<code>
|
|
# strace -f /sbin/klogd | grep 'System.map'
|
|
31208 open("/boot/System.map-2.4.18", O_RDONLY|O_LARGEFILE) = 2
|
|
</code>
|
|
|
|
|
|
Apparently, not only does klogd look for the correct version of the map in the
|
|
3 klogd search directories, but klogd also knows to look for the name
|
|
"System.map" followed by "-kernelversion", like System.map-2.4.18. This is
|
|
undocumented feature of klogd.
|
|
|
|
A few drivers will need System.map to resolve symbols (since they're linked
|
|
against the kernel headers instead of, say, glibc). They will not work
|
|
correctly without the System.map created for the particular kernel you're
|
|
currently running. This is NOT the same thing as a module not loading because
|
|
of a kernel version mismatch. That has to do with the kernel version, not the
|
|
kernel symbol table which changes between kernels of the same version!
|
|
|
|
<sect2>
|
|
What else uses the System.map
|
|
<p>
|
|
Don't think that System.map is only useful for kernel oopses. Although the
|
|
kernel itself doesn't really use System.map, other programs such as klogd, lsof,
|
|
|
|
<code>
|
|
satan# strace lsof 2>&1 1> /dev/null | grep System
|
|
readlink("/proc/22711/fd/4", "/boot/System.map-2.4.18", 4095) = 23
|
|
</code>
|
|
|
|
and ps :
|
|
|
|
<code>
|
|
satan# strace ps 2>&1 1> /dev/null | grep System
|
|
open("/boot/System.map-2.4.18", O_RDONLY|O_NONBLOCK|O_NOCTTY) = 6
|
|
</code>
|
|
|
|
|
|
and many other pieces of software like dosemu require a correct System.map.
|
|
|
|
<sect2>
|
|
What Happens If I Don't Have A Healthy System.map?
|
|
<p>
|
|
Suppose you have multiple kernels on the same machine. You need a separate
|
|
System.map files for each kernel! If boot a kernel that doesn't have a
|
|
System.map file, you'll periodically see a message like:
|
|
System.map does not match actual kernel Not a fatal error, but can be annoying
|
|
to see everytime you do a ps ax. Some software, like dosemu, may not work
|
|
correctly (although I don't know of anything off the top of my head). Lastly,
|
|
your klogd or ksymoops output will not be reliable in case of a kernel oops.
|
|
|
|
<sect2>
|
|
How Do I Remedy The Above Situation?
|
|
<p>
|
|
The solution is to keep all your System.map files in /boot and rename them with
|
|
the kernel version. Suppose you have multiple kernels like:
|
|
|
|
<itemize>
|
|
<item> /boot/vmlinuz-2.2.14
|
|
<item> /boot/vmlinuz-2.2.13
|
|
</itemize>
|
|
|
|
Then just rename your map files according to the kernel version and put them in
|
|
/boot, like:
|
|
<code>
|
|
/boot/System.map-2.2.14
|
|
/boot/System.map-2.2.13
|
|
</code>
|
|
|
|
Now what if you have two copies of the same kernel? Like:
|
|
<itemize>
|
|
<item> /boot/vmlinuz-2.2.14
|
|
<item> /boot/vmlinuz-2.2.14.nosound
|
|
</itemize>
|
|
|
|
The best answer would be if all software looked for the following files:
|
|
<code>
|
|
/boot/System.map-2.2.14
|
|
/boot/System.map-2.2.14.nosound
|
|
</code>
|
|
|
|
You can also use symlinks:
|
|
<code>
|
|
System.map-2.2.14
|
|
System.map-2.2.14.sound
|
|
ln -s System.map-2.2.14.sound System.map # Here System.map -> System.map-2.2.14.sound
|
|
</code>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<sect> Other Formats of this Document
|
|
<p>
|
|
This section is written by
|
|
<htmlurl url="mailto:alavoor[AT]yahoo.com"
|
|
name="Al Dev">
|
|
(at site <url url="http://www.milkywaygalaxy.freeservers.com">
|
|
mirrors at
|
|
<url name="angelfire" url="http://www.angelfire.com/country/aldev0">,
|
|
<url name="geocities" url="http://www.geocities.com/alavoor/index.html">,
|
|
<url name="virtualave" url="http://aldev0.virtualave.net">,
|
|
<url name="Fortunecity" url="http://members.fortunecity.com/aldev">,
|
|
<url name="Freewebsites" url="http://aldev.freewebsites.com">,
|
|
<url name="Tripod" url="http://members.tripod.lycos.com/aldev">,
|
|
<url name="101xs" url="http://www.101xs.com/101xs/aldev">,
|
|
<url name="50megs" url="http://aldev0.50megs.com">
|
|
)
|
|
|
|
This document is published in 14 different formats namely - DVI, Postscript,
|
|
Latex, Adobe Acrobat PDF,
|
|
LyX, GNU-info, HTML, RTF(Rich Text Format), Plain-text, Unix man pages, single
|
|
HTML file, SGML (Linuxdoc format), SGML (Docbook format), MS WinHelp format.
|
|
|
|
This howto document is located at -
|
|
<itemize>
|
|
<item> <url url="http://www.linuxdoc.org"> and click on HOWTOs and search
|
|
for howto document name using CTRL+f or ALT+f within the web-browser.
|
|
</itemize>
|
|
|
|
You can also find this document at the following mirrors sites -
|
|
<itemize>
|
|
<item> <url url="http://www.caldera.com/LDP/HOWTO">
|
|
<item> <url url="http://www.linux.ucla.edu/LDP">
|
|
<item> <url url="http://www.cc.gatech.edu/linux/LDP">
|
|
<item> <url url="http://www.redhat.com/mirrors/LDP">
|
|
|
|
<item> Other mirror sites near you (network-address-wise) can be found at
|
|
<url url="http://www.linuxdoc.org/mirrors.html">
|
|
select a site and go to directory /LDP/HOWTO/xxxxx-HOWTO.html
|
|
</itemize>
|
|
|
|
|
|
<itemize>
|
|
<item>
|
|
You can get this HOWTO document as a single file tar ball in HTML, DVI,
|
|
Postscript or SGML formats from -
|
|
<url url="ftp://www.linuxdoc.org/pub/Linux/docs/HOWTO/other-formats/">
|
|
and <url url="http://www.linuxdoc.org/docs.html#howto">
|
|
<p>
|
|
<item>Plain text format is in: <url url="ftp://www.linuxdoc.org/pub/Linux/docs/HOWTO">
|
|
and <url url="http://www.linuxdoc.org/docs.html#howto">
|
|
<p>
|
|
<item>Single HTML file format is in:
|
|
<url url="http://www.linuxdoc.org/docs.html#howto">
|
|
<p> Single HTML file can be created with command (see man sgml2html) -
|
|
sgml2html -split 0 xxxxhowto.sgml
|
|
<p>
|
|
<item>Translations to other languages like French, German, Spanish,
|
|
Chinese, Japanese are in
|
|
<url url="ftp://www.linuxdoc.org/pub/Linux/docs/HOWTO">
|
|
and <url url="http://www.linuxdoc.org/docs.html#howto">
|
|
Any help from you to translate to other languages is welcome.
|
|
</itemize>
|
|
The document is written using a tool called "SGML-Tools" which can be got from -
|
|
<url url="http://www.sgmltools.org">
|
|
Compiling the source you will get the following commands like
|
|
<itemize>
|
|
<item>sgml2html xxxxhowto.sgml (to generate html file)
|
|
<item>sgml2html -split 0 xxxxhowto.sgml (to generate a single page html file)
|
|
<item>sgml2rtf xxxxhowto.sgml (to generate RTF file)
|
|
<item>sgml2latex xxxxhowto.sgml (to generate latex file)
|
|
</itemize>
|
|
|
|
|
|
|
|
|
|
<sect1> Acrobat PDF format <label id="acrobatpdf">
|
|
<p>
|
|
PDF file can be generated from postscript file using
|
|
either acrobat <bf>distill</bf> or <bf>Ghostscript</bf>.
|
|
And postscript file is generated
|
|
from DVI which in turn is generated from LaTex file.
|
|
You can download distill software from <url url="http://www.adobe.com">. Given below
|
|
is a sample session:
|
|
<code>
|
|
bash$ man sgml2latex
|
|
bash$ sgml2latex filename.sgml
|
|
bash$ man dvips
|
|
bash$ dvips -o filename.ps filename.dvi
|
|
bash$ distill filename.ps
|
|
bash$ man ghostscript
|
|
bash$ man ps2pdf
|
|
bash$ ps2pdf input.ps output.pdf
|
|
bash$ acroread output.pdf &
|
|
</code>
|
|
Or you can use Ghostscript command <bf>ps2pdf</bf>.
|
|
ps2pdf is a work-alike for nearly all the functionality of
|
|
Adobe's Acrobat Distiller product: it
|
|
converts PostScript files to Portable Document Format (PDF) files.
|
|
<bf>ps2pdf</bf> is implemented as a very small command script
|
|
(batch file) that invokes Ghostscript, selecting a special "output device"
|
|
called <bf>pdfwrite</bf>. In order to use ps2pdf, the pdfwrite
|
|
device must be included in the makefile when Ghostscript was compiled;
|
|
see the documentation on building Ghostscript for details.
|
|
|
|
|
|
|
|
<sect1> Convert Linuxdoc to Docbook format <label id="linuxdoc2docbook">
|
|
<p>
|
|
This document is written in linuxdoc SGML format. The Docbook SGML format
|
|
supercedes the linuxdoc format and has lot more features than linuxdoc.
|
|
The linuxdoc is very simple and is easy to use. To convert linuxdoc SGML
|
|
file to Docbook SGML use the program <bf>ld2db.sh</bf> and some perl scripts.
|
|
The ld2db output is not 100% clean and you need to use the <bf>clean_ld2db.pl</bf>
|
|
perl script. You may need to manually correct few lines in the document.
|
|
<itemize>
|
|
<item> Download ld2db program from <url url="http://www.dcs.gla.ac.uk/~rrt/docbook.html">
|
|
or from <url name="Milkyway Galaxy site" url="http://www.milkywaygalaxy.freeservers.com">
|
|
<item> Download the cleanup_ld2db.pl perl script from
|
|
from <url name="Milkyway Galaxy site" url="http://www.milkywaygalaxy.freeservers.com">
|
|
</itemize>
|
|
The ld2db.sh is not 100% clean, you will get lot of errors when you run
|
|
<code>
|
|
bash$ ld2db.sh file-linuxdoc.sgml db.sgml
|
|
bash$ cleanup.pl db.sgml > db_clean.sgml
|
|
bash$ gvim db_clean.sgml
|
|
bash$ docbook2html db.sgml
|
|
</code>
|
|
And you may have to manually edit some of the minor errors after
|
|
running the perl script. For e.g. you may need to put closing tag <
|
|
/Para> for each <
|
|
Listitem>
|
|
|
|
|
|
|
|
<sect1> Convert to MS WinHelp format <label id="mswinhelp">
|
|
<p>
|
|
You can convert the SGML howto document to Microsoft Windows Help file,
|
|
first convert the sgml to html using:
|
|
<code>
|
|
bash$ sgml2html xxxxhowto.sgml (to generate html file)
|
|
bash$ sgml2html -split 0 xxxxhowto.sgml (to generate a single page html file)
|
|
</code>
|
|
Then use the tool <url name="HtmlToHlp" url="http://javadocs.planetmirror.com/htmltohlpe.html">.
|
|
You can also use sgml2rtf and then use the RTF files for generating winhelp files.
|
|
|
|
|
|
|
|
<sect1> Reading various formats <label id="readformats">
|
|
<p>
|
|
In order to view the document in dvi format, use the xdvi program. The xdvi
|
|
program is located in tetex-xdvi*.rpm package in Redhat Linux which can be
|
|
located through ControlPanel | Applications | Publishing | TeX menu buttons.
|
|
To read dvi document give the command -
|
|
<tscreen><verb>
|
|
xdvi -geometry 80x90 howto.dvi
|
|
man xdvi
|
|
</verb></tscreen>
|
|
And resize the window with mouse.
|
|
To navigate use Arrow keys, Page Up, Page Down keys, also
|
|
you can use 'f', 'd', 'u', 'c', 'l', 'r', 'p', 'n' letter
|
|
keys to move up, down, center, next page, previous page etc.
|
|
To turn off expert menu press 'x'.
|
|
|
|
You can read postscript file using the program 'gv' (ghostview) or
|
|
'ghostscript'.
|
|
The ghostscript program is in ghostscript*.rpm package and gv
|
|
program is in gv*.rpm package in Redhat Linux
|
|
which can be located through ControlPanel | Applications | Graphics menu
|
|
buttons. The gv program is much more user friendly than ghostscript.
|
|
Also ghostscript and gv are available on other platforms like OS/2,
|
|
Windows 95 and NT, you view this document even on those platforms.
|
|
|
|
<itemize>
|
|
<item>Get ghostscript for Windows 95, OS/2, and for
|
|
all OSes from <url url="http://www.cs.wisc.edu/~ghost">
|
|
</itemize>
|
|
|
|
To read postscript document give the command -
|
|
<tscreen><verb>
|
|
gv howto.ps
|
|
ghostscript howto.ps
|
|
</verb></tscreen>
|
|
|
|
You can read HTML format document using Netscape Navigator, Microsoft Internet
|
|
explorer, Redhat Baron Web browser or any of the 10 other web browsers.
|
|
|
|
You can read the latex, LyX output using LyX a X-Windows front end to latex.
|
|
|
|
|
|
|
|
<sect> Appendix A - Creating initrd.img file <label id="createinitrd">
|
|
<p>
|
|
The <bf>initrd</bf> is the "initial ramdisk". It is
|
|
enough files stored in a ramdisk to store needed drivers . You need the
|
|
drivers so that the kernel can mount / and kick off init.
|
|
|
|
You can avoid this if you build your scsi drivers right into the kernel,
|
|
instead of into modules. (Many persons recommend this).
|
|
|
|
<sect1> Using mkinitrd
|
|
<p>
|
|
The mkinitrd utility creates an initrd image in a single command. This
|
|
is command is peculiar to RedHat. There may be equivalent command of mkinitrd in other
|
|
distributions of Linux. This is very convenient utility.
|
|
|
|
You can read the mkinitrd man page.
|
|
|
|
<code>
|
|
/sbin/mkinitrd --help # Or simply type 'mkinitrd --help'
|
|
usage: mkinitrd [--version] [-v] [-f] [--preload <module>]
|
|
[--omit-scsi-modules] [--omit-raid-modules] [--omit-lvm-modules]
|
|
[--with=<module>] [--image-version] [--fstab=<fstab>] [--nocompress]
|
|
[--builtin=<module>] [--nopivot] <initrd-image> <kernel-version>
|
|
|
|
(example: mkinitrd /boot/initrd-2.2.5-15.img 2.2.5-15)
|
|
|
|
# Read the online manual page with .....
|
|
man mkinitrd
|
|
|
|
su - root
|
|
|
|
# The command below creates the initrd image file
|
|
mkinitrd ./initrd-2.4.18-19.8.0custom.img 2.4.18-19.8.0custom
|
|
|
|
ls -l initrd-2.4.18-19.8.0custom.img
|
|
-rw-r--r-- 1 root root 127314 Mar 19 21:54 initrd-2.4.18-19.8.0custom.img
|
|
|
|
cp ./initrd-2.4.18-19.8.0custom.img /boot
|
|
</code>
|
|
|
|
See the following sections for the manual method of creating an initrd image.
|
|
|
|
<sect1> Kernel Docs
|
|
<p>
|
|
To create /boot/initrd.img see the documentation at
|
|
/usr/src/linux/Documentation/initrd.txt
|
|
and see also
|
|
<url name="Loopback-Root-mini-HOWTO"
|
|
url="http://www.tldp.org/HOWTO/mini/Loopback-Root-FS-3.html#ss3.3">.
|
|
|
|
|
|
|
|
<sect1> Linuxman Book
|
|
<p>
|
|
A cut from <url url="http://www.linuxman.com.cy/rute/node1.html"> chapter 31.7.
|
|
|
|
SCSI Installation Complications and initrd
|
|
|
|
Some of the following descriptions may be difficult to understand without
|
|
knowledge of kernel modules explained in Chapter 42. You may want to come back
|
|
to it later.
|
|
|
|
Consider a system with zero IDE disks and one SCSI disk containing a LINUX
|
|
installation. There are BIOS interrupts to read the SCSI disk, just as there
|
|
were for the IDE, so LILO can happily access a kernel image somewhere inside
|
|
the SCSI partition. However, the kernel is going to be lost without a kernel
|
|
module [See Chapter 42. The kernel doesn't support every possible kind of
|
|
hardware out there all by itself. It is actually divided into a main part (the
|
|
kernel image discussed in this chapter) and hundreds of modules (loadable parts
|
|
that reside in /lib/modules/) that support the many type of SCSI, network,
|
|
sound etc., peripheral devices.] that understands the particular SCSI driver.
|
|
So although the kernel can load and execute, it won't be able to mount its root
|
|
file system without loading a SCSI module first. But the module itself resides
|
|
in the root file system in /lib/modules/. This is a tricky situation to solve
|
|
and is done in one of two ways: either (a) using a kernel with preenabled SCSI
|
|
support or (b) using what is known as an initrd preliminary root file system
|
|
image.
|
|
|
|
The first method is what I recommend. It's a straightforward (though
|
|
time-consuming) procedure to create a kernel with SCSI support for your SCSI
|
|
card built-in (and not in a separate module). Built-in SCSI and network drivers
|
|
will also autodetect cards most of the time, allowing immediate access to the
|
|
device--they will work without being given any options [Discussed in Chapter
|
|
42.] and, most importantly, without your having to read up on how to configure
|
|
them. This setup is known as compiled-in support for a hardware driver (as
|
|
opposed to module support for the driver). The resulting kernel image will be
|
|
larger by an amount equal to the size of module. Chapter 42 discusses such
|
|
kernel compiles.
|
|
|
|
The second method is faster but trickier. LINUX supports what is known as an
|
|
initrd image ( initial rAM disk image). This is a small, +1.5 megabyte file
|
|
system that is loaded by LILO and mounted by the kernel instead of the real
|
|
file system. The kernel mounts this file system as a RAM disk, executes the
|
|
file /linuxrc, and then only mounts the real file system.
|
|
|
|
31.6 Creating an initrd Image
|
|
|
|
Start by creating a small file system. Make a directory ~/initrd and
|
|
copy the following files into it.
|
|
|
|
<code>
|
|
drwxr-xr-x 7 root root 1024 Sep 14 20:12 initrd/
|
|
drwxr-xr-x 2 root root 1024 Sep 14 20:12 initrd/bin/
|
|
-rwxr-xr-x 1 root root 436328 Sep 14 20:12 initrd/bin/insmod
|
|
-rwxr-xr-x 1 root root 424680 Sep 14 20:12 initrd/bin/sash
|
|
drwxr-xr-x 2 root root 1024 Sep 14 20:12 initrd/dev/
|
|
crw-r--r-- 1 root root 5, 1 Sep 14 20:12 initrd/dev/console
|
|
crw-r--r-- 1 root root 1, 3 Sep 14 20:12 initrd/dev/null
|
|
brw-r--r-- 1 root root 1, 1 Sep 14 20:12 initrd/dev/ram
|
|
crw-r--r-- 1 root root 4, 0 Sep 14 20:12 initrd/dev/systty
|
|
crw-r--r-- 1 root root 4, 1 Sep 14 20:12 initrd/dev/tty1
|
|
crw-r--r-- 1 root root 4, 1 Sep 14 20:12 initrd/dev/tty2
|
|
crw-r--r-- 1 root root 4, 1 Sep 14 20:12 initrd/dev/tty3
|
|
crw-r--r-- 1 root root 4, 1 Sep 14 20:12 initrd/dev/tty4
|
|
drwxr-xr-x 2 root root 1024 Sep 14 20:12 initrd/etc/
|
|
drwxr-xr-x 2 root root 1024 Sep 14 20:12 initrd/lib/
|
|
-rwxr-xr-x 1 root root 76 Sep 14 20:12 initrd/linuxrc
|
|
drwxr-xr-x 2 root root 1024 Sep 14 20:12 initrd/loopfs/
|
|
</code>
|
|
|
|
On my system, the file initrd/bin/insmod is the statically linked [meaning it
|
|
does not require shared libraries.] version copied from /sbin/insmod.static--a
|
|
member of the modutils-2.3.13 package. initrd/bin/sash is a statically linked
|
|
shell from the sash-3.4 package. You can recompile insmod from source if you
|
|
don't have a statically linked version. Alternatively, copy the needed DLLs
|
|
from /lib/ to initrd/lib/. (You can get the list of required DLLs by running
|
|
ldd /sbin/insmod. Don't forget to also copy symlinks and run strip -s {lib} to
|
|
reduce the size of the DLLs.)
|
|
|
|
Now copy into the initrd/lib/ directory the SCSI modules you require. For
|
|
example, if we have an Adaptec AIC-7850 SCSI adapter, we would require the
|
|
aic7xxx.o module from /lib/modules/{version}/scsi/aic7xxx.o. Then, place it in
|
|
the initrd/lib/ directory.
|
|
|
|
<code>
|
|
-rw-r--r-- 1 root root 129448 Sep 27 1999 initrd/lib/aic7xxx.o
|
|
</code>
|
|
|
|
The file initrd/linuxrc should contain a script to load all the modules needed
|
|
for the kernel to access the SCSI partition. In this case, just the aic7xxx
|
|
module [ insmod can take options such as the IRQ and IO-port for the device.
|
|
See Chapter 42.]:
|
|
|
|
<code>
|
|
#!/bin/sash
|
|
|
|
aliasall
|
|
|
|
echo "Loading aic7xxx module"
|
|
insmod /lib/aic7xxx.o
|
|
</code>
|
|
|
|
Now double-check all your permissions and then chroot to the file system for
|
|
testing.
|
|
|
|
<code>
|
|
chroot ~/initrd /bin/sash
|
|
/linuxrc
|
|
</code>
|
|
|
|
Now, create a file system image similar to that in Section 19.9:
|
|
<code>
|
|
dd if=/dev/zero of=~/file-inird count=2500 bs=1024
|
|
losetup /dev/loop0 ~/file-inird
|
|
mke2fs /dev/loop0
|
|
mkdir ~/mnt
|
|
mount /dev/loop0 ~/mnt
|
|
cp -a initrd/* ~/mnt/
|
|
umount ~/mnt
|
|
losetup -d /dev/loop0
|
|
</code>
|
|
|
|
Finally, gzip the file system to an appropriately named file:
|
|
<code>
|
|
gzip -c ~/file-inird > initrd-<kernel-version>
|
|
</code>
|
|
|
|
31.7 Modifying lilo.conf for initrd
|
|
|
|
Your lilo.conf file can be changed slightly to force use of an initrd file
|
|
system. Simply add the initrd option. For example:
|
|
|
|
<code>
|
|
boot=/dev/sda
|
|
prompt
|
|
timeout = 50
|
|
compact
|
|
vga = extended
|
|
linear
|
|
image = /boot/vmlinuz-2.2.17
|
|
initrd = /boot/initrd-2.2.17
|
|
label = linux
|
|
root = /dev/sda1
|
|
read-only
|
|
</code>
|
|
|
|
Notice the use of the linear option. This is a BIOS trick that you can read
|
|
about in lilo(5). It is often necessary but can make SCSI disks nonportable to
|
|
different BIOSs (meaning that you will have to rerun lilo if you move the disk
|
|
to a different computer).
|
|
|
|
|
|
|
|
|
|
<sect> Appendix B - Sample lilo.conf <label id="liloconf">
|
|
<p>
|
|
See also <ref id="grubconf" name="Appendix C - GRUB details and sample grub.conf"> file.
|
|
|
|
Always give a date extension to the filename, because it tells you when you built the
|
|
kernel, as shown below:
|
|
<code>
|
|
bash# man lilo
|
|
bash# man lilo.conf
|
|
And edit /etc/lilo.conf file and put these lines -
|
|
image=/boot/bzImage.myker.26mar2001
|
|
label=myker
|
|
root=/dev/hda1
|
|
read-only
|
|
You can check device name for 'root=' with the command -
|
|
bash# df /
|
|
|
|
Now give -
|
|
bash# lilo
|
|
bash# lilo -q
|
|
</code>
|
|
You must re-run lilo even if the entry 'myker' exists, everytime you create a new bzImage.
|
|
|
|
Given below is a sample /etc/lilo.conf file. You should follow the
|
|
naming conventions like ker2217 (for kernel 2.2.17), ker2214 (for kernel 2.2.14).
|
|
You can have many kernel images on the same /boot system.
|
|
On my machine I have something like:
|
|
<code>
|
|
boot=/dev/hda
|
|
map=/boot/map
|
|
install=/boot/boot.b
|
|
prompt
|
|
timeout=50
|
|
default=firewall
|
|
|
|
image=/boot/vmlinuz-2.2.14-5.0
|
|
label=ker2214
|
|
read-only
|
|
root=/dev/hda9
|
|
|
|
image=/boot/vmlinuz-2.2.17-14
|
|
label=ker2217
|
|
read-only
|
|
root=/dev/hda9
|
|
|
|
#image=/usr/src/linux/arch/i386/boot/bzImage
|
|
# label=myker
|
|
# root=/dev/hda7
|
|
# read-only
|
|
|
|
image=/boot/bzImage.myker.11feb2001
|
|
label=myker11feb
|
|
root=/dev/hda9
|
|
read-only
|
|
|
|
image=/boot/bzImage.myker.01jan2001
|
|
label=myker01jan
|
|
root=/dev/hda9
|
|
read-only
|
|
|
|
image=/boot/bzImage.myker-firewall.16mar2001
|
|
label=firewall
|
|
root=/dev/hda9
|
|
read-only
|
|
</code>
|
|
|
|
|
|
|
|
|
|
<sect> Appendix C - GRUB Details And A Sample grub.conf <label id="grubconf">
|
|
<p>
|
|
See
|
|
<itemize>
|
|
<item> <url url="http://www.tldp.org/HOWTO/Linux+Win9x+Grub-HOWTO/intro.html">
|
|
<item> GNU GRUB <url url="http://www.gnu.org/software/grub">
|
|
<item> <url name="Redhat Manual" url="http://www.redhat.com/docs/manuals/linux/RHL-7.2-Manual/ref-guide/ch-grub.html">.
|
|
<item> <url name="Multiboot-with-GRUB minihowto" url="http://www.tldp.org/HOWTO/mini/Multiboot-with-GRUB.html">
|
|
<item> <url name="Grub Manual" url="http://www.mcc.ac.uk/grub/grub_toc.html">
|
|
</itemize>
|
|
<code>
|
|
bash# man grub
|
|
bash# man grubby # (command line tool for configuring grub, lilo, and elilo)
|
|
bash# man grub-install
|
|
</code>
|
|
Edit the file /etc/grub.conf to make entries for the new kernel.
|
|
See the sample file below:
|
|
|
|
<code>
|
|
# grub.conf generated by anaconda
|
|
#
|
|
# Note that you do not have to rerun grub after making changes to this file
|
|
# NOTICE: You do not have a /boot partition. This means that
|
|
# all kernel and initrd paths are relative to /, eg.
|
|
# root (hd0,8)
|
|
# kernel /boot/vmlinuz-version ro root=/dev/hda9
|
|
# initrd /boot/initrd-version.img
|
|
#boot=/dev/hda
|
|
|
|
# By default boot the second entry
|
|
default=1
|
|
|
|
# Fallback to the first entry.
|
|
fallback 0
|
|
|
|
# Boot automatically after 2 minutes
|
|
timeout=120
|
|
|
|
splashimage=(hd0,8)/boot/grub/splash.xpm.gz
|
|
|
|
title Windows 2000
|
|
unhide (hd0,0)
|
|
hide (hd0,1)
|
|
hide (hd0,2)
|
|
rootnoverify (hd0,0)
|
|
chainloader +1
|
|
makeactive
|
|
|
|
title Red Hat Linux (2.4.18-19.8.0.19mar2003)
|
|
root (hd0,8)
|
|
kernel /boot/bzImage.2.4.18-19.8.0.19mar2003 ro root=LABEL=/ hdd=ide-scsi
|
|
initrd /boot/initrd-2.4.18-19.8.0custom.img.19mar03
|
|
|
|
title Red Hat Linux (2.4.18-19.8.0custom)
|
|
root (hd0,8)
|
|
kernel /boot/vmlinuz-2.4.18-19.8.0custom ro root=LABEL=/ hdd=ide-scsi
|
|
initrd /boot/initrd-2.4.18-19.8.0custom.img
|
|
|
|
title Red Hat Linux (2.4.18-14)
|
|
root (hd0,8)
|
|
kernel /boot/vmlinuz-2.4.18-14 ro root=LABEL=/ hdd=ide-scsi
|
|
initrd /boot/initrd-2.4.18-14.img
|
|
|
|
title MyKernel.26jan03 (Red Hat Linux 2.4.18-14)
|
|
root (hd0,8)
|
|
kernel /boot/bzImage.myker.26jan03 ro root=LABEL=/ hdd=ide-scsi
|
|
initrd /boot/initrd-2.4.18-19.8.0.img
|
|
|
|
title Windows 98
|
|
hide (hd0,0)
|
|
hide (hd0,1)
|
|
unhide (hd0,2)
|
|
rootnoverify (hd0,2)
|
|
chainloader +1
|
|
makeactive
|
|
|
|
title DOS 6.22
|
|
hide (hd0,0)
|
|
unhide (hd0,1)
|
|
hide (hd0,2)
|
|
rootnoverify (hd0,1)
|
|
chainloader +1
|
|
makeactive
|
|
|
|
title Partition 2 (floppy)
|
|
hide (hd0,0)
|
|
unhide (hd0,1)
|
|
hide (hd0,2)
|
|
chainloader (fd0)+1
|
|
|
|
title Partition 3 (floppy)
|
|
hide (hd0,0)
|
|
hide (hd0,1)
|
|
unhide (hd0,2)
|
|
chainloader (fd0)+1
|
|
</code>
|
|
|
|
|
|
<sect> Appendix D - Post Kernel Building <label id="postkernel">
|
|
<p>
|
|
After successfully building and booting the Linux kernel, you may be required
|
|
to do these additional steps to make some of the devices to work with Linux.
|
|
(The steps below were tested on Redhat Linux but should work with other distributions
|
|
as well.)
|
|
|
|
<bf>Video card/Monitor configuration: </bf>
|
|
<itemize>
|
|
<item> Please see the video card manual which is usually shipped with the PC.
|
|
You should look for a "Technical Specifications" page.
|
|
<item> Please see the monitor's manual and look for a "Technical Specifications" page.
|
|
</itemize>
|
|
|
|
If you are using latest version of Linux (2.4 or later) and inside KDE/GNOME desktop
|
|
click on Start->"System Settings"->Display.
|
|
|
|
For older versions of Linux follow the steps below:
|
|
|
|
You can configure the Video card and monitor by using these commands:
|
|
<code>
|
|
bash$ su - root
|
|
bash# man Xconfigurator
|
|
bash# /usr/bin/X11/Xconfigurator --help
|
|
bash# /usr/bin/X11/Xconfigurator
|
|
bash# /usr/bin/X11/Xconfigurator --expert
|
|
|
|
See also:
|
|
bash# man xf86config
|
|
bash# /usr/bin/X11/xf86config
|
|
</code>
|
|
If your card is not detected automatically, then you can use the --expert option
|
|
and select the "Unlisted card". If your monitor is not listed then select the generic
|
|
monitor type SVGA 1024x768.
|
|
|
|
<bf>Sound card configuration: </bf>
|
|
<itemize>
|
|
<item> Connect your external speakers to the sound card's audio port.
|
|
<item> Connect your CDROM audio wire to sound card's audio 4-pin socket. (Otherwise
|
|
your cdrom drive will not play the music from your music cd)
|
|
<item> Refer to HOWTO docs on 'Sound' at <url url="http://www.linuxdoc.org">
|
|
</itemize>
|
|
If you are using latest version of Linux (2.4 or later) and inside KDE/GNOME desktop
|
|
click on Start->"System Settings"->Soundcard Detection.
|
|
|
|
For older versions of Linux follow the steps below:
|
|
|
|
<code>
|
|
bash$ su - root
|
|
bash# man sndconfig
|
|
bash# /usr/sbin/sndconfig
|
|
</code>
|
|
Then start X-window 'KDE desktop' with 'startx' command.
|
|
Click on 'K Start->ControlCenter->SoundServer->General->Test Sound'. This should
|
|
play the test sound. Then click on 'K Start->MultiMedia->SoundMixer->SoundVolumeSlider'
|
|
and adjust the sound volume.
|
|
|
|
<bf>Network card configuration: </bf>
|
|
If you are using latest version of Linux (2.4 or later) and inside KDE/GNOME desktop
|
|
click on Start->"System Settings"->Network.
|
|
|
|
For older versions of Linux follow the steps below:
|
|
|
|
<itemize>
|
|
<item> Use /sbin/linuxconf
|
|
<item> Or use KDE control panel
|
|
<item> Refer to HOWTO docs on 'Networking' at <url url="http://www.linuxdoc.org">
|
|
</itemize>
|
|
|
|
<bf>Configure Firewall and IP Masquerading : </bf>
|
|
For Linux kernel version 2.4 and above, the firewall and IP Masquerading is
|
|
implemented by NetFilter package. Hence in kernel config you should enable
|
|
Netfilter and run the Firewall/IPMasq script. Download the scripts from
|
|
<url name="Firewall-IPMasq scripts" url="http://www.BoingWorld.com/workshops/linux/iptables-tutorial">
|
|
, main page of Netfilter is at
|
|
<url url="http://netfilter.samba.org">.
|
|
Related materials at <url name="firewalling-matures" url="http://www.linuxsecurity.com/feature_stories/kernel-netfilter.html">
|
|
and <url name="Netfilter-FAQ" url="http://netfilter.filewatcher.org/netfilter-faq.html">.
|
|
|
|
For kernel version below 2.4 you should install the firewall rpms from
|
|
<url name="rpmfind.net" url="http://rpmfind.net/linux/rpm2html/search.php?query=firewall">
|
|
or <url name="firewall.src.rpm" url="http://rpmfind.net/linux/RPM/contrib/noarch//SRPMS//firewall-2.2-3.src.html">.
|
|
|
|
<bf>Configuration of other devices: </bf>
|
|
Refer to HOWTO docs relating to your devices at <url url="http://www.linuxdoc.org">
|
|
|
|
|
|
<sect> Appendix E - Troubleshoot Common Mistakes <label id="troubleshoot">
|
|
<p>
|
|
|
|
<sect1> Compiles OK but does not boot
|
|
<p>
|
|
If the kernel compiles ok but booting never works
|
|
and it always complains with a kernel panic about /sbin/modprobe.
|
|
|
|
Solution: You did not create initrd image file.
|
|
See the Appendix A at <ref id="createinitrd" name="Creating initrd.img file">.
|
|
Also, you must do 'make modules' and 'make modules_install' in addition to
|
|
creating the initrd image file.
|
|
|
|
<sect1> The System Hangs at LILO
|
|
<p>
|
|
<bf>Sympton: </bf> After you build the kernel and reboot, the system hangs just before LILO.
|
|
|
|
<bf>Reason: </bf> Probably you did not set the BIOS to pick up the proper Primary Master IDE and
|
|
Secondary Slave IDE hard disk partition.
|
|
|
|
<bf>Solution: </bf>Power on the machine and press DEL key to do setup of the BIOS (Basic Input Output system). Select the IDE settings and set proper primary hard disk partition and slave drives.
|
|
When the system boots it looks for the primary IDE hard disk and the Master Boot Record partition.
|
|
It reads the MBR and starts loading the Linux Kernel from the hard disk partition.
|
|
|
|
|
|
<sect1> No init found
|
|
<p>
|
|
The following mistake is commited very frequently by new users.
|
|
|
|
If your new kernel does not boot and you get -
|
|
<code>
|
|
Warning: unable to open an initial console
|
|
Kernel panic: no init found. Try passing init= option to kernel
|
|
</code>
|
|
The problem is that you <bf>did not</bf> set the "root=" parameter properly
|
|
in the /etc/lilo.conf. In my case, I used root=/dev/hda1 which is
|
|
having the root partition "/". You must properly point the root device in your
|
|
lilo.conf, it can be like /dev/hdb2 or /dev/hda7.
|
|
|
|
The kernel looks for the init command which is located in /sbin/init.
|
|
And /sbin directory lives on the root partition.
|
|
For details see -
|
|
<code>
|
|
bash# man init
|
|
</code>
|
|
See the <ref id="grubconf" name="Appendix C - GRUB details and sample grub.conf"> file
|
|
and see the <ref id="liloconf" name="Appendix B - Sample lilo.conf">.
|
|
|
|
|
|
<sect1> Lot of Compile Errors
|
|
<p>
|
|
The 'make', 'make bzImage', 'make modules' or 'make modules_install'
|
|
gives compile problems.
|
|
You should give 'make mrproper' before doing make.
|
|
<code>
|
|
bash# make mrproper
|
|
</code>
|
|
If this problem persists, then try menuconfig instead of xconfig.
|
|
Sometimes GUI version xconfig causes some problems:
|
|
<code>
|
|
bash# export TERM=VT100
|
|
bash# make menuconfig
|
|
</code>
|
|
|
|
|
|
|
|
|
|
<sect1> The 'depmod' gives "Unresolved symbol error messages"
|
|
<p>
|
|
When you run <tt>depmod</tt> it gives "Unresolved symbols". A sample error message
|
|
is given here to demonstrate the case:
|
|
<code>
|
|
bash$ su - root
|
|
bash# man depmod
|
|
bash# depmod
|
|
depmod: *** Unresolved symbols in /lib/modules/version/kernel/drivers/md/linear.o
|
|
depmod: *** Unresolved symbols in /lib/modules/version/kernel/drivers/md/multipath.o
|
|
depmod: *** Unresolved symbols in /lib/modules/version/kernel/drivers/md/raid0.o
|
|
depmod: *** Unresolved symbols in /lib/modules/version/kernel/drivers/md/raid1.o
|
|
depmod: *** Unresolved symbols in /lib/modules/version/kernel/drivers/md/raid5.o
|
|
</code>
|
|
|
|
<bf>Reason: </bf> You did not make modules and install the modules after building
|
|
the new kernel with <tt>"make bzImage"</tt>.
|
|
|
|
<bf>Solution: </bf> After you build the new kernel, you must do:
|
|
<code>
|
|
bash$ su - root
|
|
bash# cd /usr/src/linux
|
|
bash# make modules
|
|
bash# make modules_install
|
|
</code>
|
|
|
|
|
|
|
|
<sect1> Kernel Does Not Load Module - "Unresolved symbols" Error Messages
|
|
<p>
|
|
When you boot kernel and system tries to load any modules and
|
|
you get "Unresolved symbol : __some_function_name" then it means
|
|
that you did not clean compile the modules and kernel. It is mandatory that
|
|
you should do <bf>make clean</bf> and make the modules. Do this -
|
|
<code>
|
|
bash# cd /usr/src/linux
|
|
bash# make dep
|
|
bash# make clean
|
|
bash# make mrproper
|
|
bash# nohup make bzImage &
|
|
bash# tail -f nohup.out (.... to monitor the progress)
|
|
bash# make modules
|
|
bash# make modules_install
|
|
</code>
|
|
|
|
|
|
|
|
<sect1> Kernel fails to load a module
|
|
<p>
|
|
If the kernel fails to load a module (say loadable module for network card
|
|
or other devices), then you may want to try to build the driver for device
|
|
right into the kernel. Sometimes <it><bf>loadable module will NOT
|
|
work</bf></it> and the driver
|
|
needs to be built right inside the kernel. For example - some network cards do not
|
|
support loadable module feature - you MUST build the driver of the network card
|
|
right into linux kernel. Hence, in 'make xconfig' you MUST not select loadable
|
|
module for this device.
|
|
|
|
|
|
|
|
|
|
<sect1> Loadable modules
|
|
<p>
|
|
You can install default loadable modules with -
|
|
|
|
The step given below may not be required but is needed <bf>ONLY FOR EMERGENCIES</bf> where
|
|
your /lib/modules files are damaged. If you already have
|
|
the /lib/modules directory and in case you
|
|
want replace them use the --force to replace the package and
|
|
select appropriate cpu architecture.
|
|
|
|
For new versions of linux redhat linux 6.0 and later, the kernel modules are
|
|
included with kernel-2.2*.rpm. Install the loadable modules and the kernel with
|
|
<code>
|
|
This will list the already installed package.
|
|
bash# rpm -qa | grep -i kernel
|
|
|
|
bash# rpm -U --force /mnt/cdrom/Redhat/RPMS/kernel-2.2.14-5.0.i686.rpm
|
|
(or)
|
|
bash# rpm -U --force /mnt/cdrom/Redhat/RPMS/kernel-2.2.14-5.0.i586.rpm
|
|
(or)
|
|
bash# rpm -U --force /mnt/cdrom/Redhat/RPMS/kernel-2.2.14-5.0.i386.rpm
|
|
</code>
|
|
|
|
This is only for old versions of redhat linux 5.2 and before.
|
|
Boot new kernel and install the loadable
|
|
modules from RedHat Linux "contrib" cdrom
|
|
<code>
|
|
bash# rpm -i /mnt/cdrom/contrib/kernel-modules*.rpm
|
|
....(For old linux systems which do not have insmod pre-installed)
|
|
</code>
|
|
<p>
|
|
|
|
<sect1> See Docs
|
|
<p>
|
|
More problems. You can read the /usr/src/linux/README (at least once)
|
|
and also /usr/src/linux/Documentation.
|
|
|
|
|
|
<sect1>make clean <p>
|
|
If your new kernel does really weird things after a routine kernel upgrade,
|
|
chances are you forgot to <tt>make clean</tt> before compiling the new
|
|
kernel. Symptoms can be anything from
|
|
your system outright crashing, strange I/O problems, to crummy
|
|
performance. Make sure you do a <tt>make dep</tt>, too.
|
|
<p>
|
|
|
|
<sect1>Huge or slow kernels <p>
|
|
If your kernel is sucking up a lot of memory, is too large,
|
|
and/or just takes forever to compile even when you've got your new
|
|
Quadbazillium-III/4400 working on it, you've probably got lot of unneeded
|
|
stuff (device drivers, filesystems, etc) configured. If you don't use it,
|
|
don't configure it, because it does take up memory.
|
|
The most obvious symptom of kernel bloat is extreme swapping in and out of
|
|
memory to disk; if your disk is making a lot of noise and it's not one of
|
|
those old Fujitsu Eagles that sound like like a jet landing when turned
|
|
off, look over your kernel configuration.
|
|
<p>
|
|
|
|
You can find out how much memory the kernel is using by taking the
|
|
total amount of memory in your machine and subtracting from it the
|
|
amount of ``total mem'' in <tt>/proc/meminfo</tt> or the output of the command
|
|
`<tt>free</tt>'.
|
|
<p>
|
|
|
|
<sect1>The parallel port doesn't work/my printer doesn't work<p>
|
|
Configuration options for PCs are: First, under the category `General Setup',
|
|
select `Parallel port support' and `PC-style hardware'. Then under
|
|
`Character devices', select `Parallel printer support'.
|
|
<p>
|
|
Then there are the names. Linux 2.2 names the printer devices differently
|
|
than previous releases. The upshot of this is that if you had an <tt>lp1</tt>
|
|
under your old kernel, it's probably an <tt>lp0</tt> under your new one.
|
|
Use `<tt>dmesg</tt>' or look through the logs in <tt>/var/log</tt> to find
|
|
out.
|
|
<p>
|
|
|
|
<sect1>Kernel doesn't compile <p>
|
|
|
|
If it does not compile, then it is likely that a patch failed, or your
|
|
source is somehow corrupt. Your version of gcc also might not
|
|
be correct, or could also be corrupt (for example, the include files
|
|
might be in error). Make sure that the symbolic links which
|
|
Linus describes in the <tt>README</tt> are set up correctly. In general, if
|
|
a standard kernel
|
|
does not compile, something is seriously wrong with the system, and
|
|
reinstallation of certain tools is probably necessary.
|
|
<p>
|
|
|
|
In some cases, gcc can crash due to hardware problems. The error
|
|
message will be something like ``xxx exited with signal 15'' and it will
|
|
generally look very mysterious. I probably would not mention this, except
|
|
that it happened to me once - I had some bad cache memory, and the compiler
|
|
would occasionally barf at random. Try reinstalling gcc first if you
|
|
experience problems. You should only get suspicious if your kernel compiles
|
|
fine with external cache turned off, a reduced amount of RAM, etc.
|
|
<p>
|
|
|
|
It tends to disturb people when it's suggested that their hardware has
|
|
problems. Well, I'm not making this up. There is an FAQ for it -- it's at
|
|
<url url="http://www.bitwizard.nl/sig11">.
|
|
<p>
|
|
|
|
<sect1>New version of the kernel doesn't seem to boot<p>
|
|
|
|
You did not run LILO, or it is not configured correctly. One thing that
|
|
``got'' me once was a problem in the config file; it said
|
|
`<tt>boot = /dev/hda1</tt>'
|
|
instead of `<tt>boot = /dev/hda</tt>' (This can be really annoying at first,
|
|
but once you have a working config file, you shouldn't need to
|
|
change it.).
|
|
<p>
|
|
|
|
<sect1> You forgot to run LILO, or system doesn't boot at all<p>
|
|
|
|
Ooops! The best thing you can do here is to boot off of a floppy disk or
|
|
CDROM and
|
|
prepare another bootable floppy (such as `<tt>make zdisk</tt>' would do).
|
|
You need to know where your root (<tt>/</tt>) filesystem is and what type
|
|
it is (e.g. second extended, minix). In the example below, you also need
|
|
to know what filesystem your <tt>/usr/src/linux</tt> source
|
|
tree is on, its type, and where it is normally mounted.<p>
|
|
|
|
In the following example, <tt>/</tt> is <tt>/dev/hda1</tt>, and the
|
|
filesystem which holds <tt>/usr/src/linux</tt>
|
|
is <tt>/dev/hda3</tt>, normally mounted at <tt>/usr</tt>. Both are
|
|
second extended filesystems. The working kernel image in
|
|
<tt>/usr/src/linux/arch/i386/boot</tt> is called <tt>bzImage</tt>.<p>
|
|
|
|
The idea is that if there is a functioning
|
|
<tt>bzImage</tt>, it is possible to use that
|
|
for the new floppy. Another alternative, which may or may not work better
|
|
(it depends on the particular method in which you messed up your system) is
|
|
discussed after the example.<p>
|
|
|
|
First, boot from a boot/root disk combo or rescue disk, and
|
|
mount the filesystem which contains the working kernel image:<p>
|
|
|
|
<verb>
|
|
mkdir /mnt
|
|
mount -t ext2 /dev/hda3 /mnt
|
|
</verb>
|
|
|
|
If <tt>mkdir</tt> tells you that the directory already exists, just ignore
|
|
it. Now, <tt>cd</tt> to the place where the working kernel image was. Note
|
|
that
|
|
<verb>
|
|
/mnt + /usr/src/linux/arch/i386/boot - /usr = /mnt/src/linux/arch/i386/boot
|
|
</verb>
|
|
Place a formatted
|
|
disk in drive ``A:'' (not your boot or root disk!), dump
|
|
the image to the disk, and configure it for your root filesystem:<p>
|
|
|
|
<verb>
|
|
cd /mnt/src/linux/arch/i386/boot
|
|
dd if=bzImage of=/dev/fd0
|
|
rdev /dev/fd0 /dev/hda1
|
|
</verb>
|
|
|
|
<tt>cd</tt> to <tt>/</tt> and unmount the normal <tt>/usr</tt> filesystem:<p>
|
|
<verb>
|
|
cd /
|
|
umount /mnt
|
|
</verb>
|
|
|
|
You should now be able to reboot your system as normal from this floppy.
|
|
Don't forget to run lilo (or whatever it was that you did wrong) after
|
|
the reboot!<p>
|
|
|
|
As mentioned above, there is another common alternative. If you
|
|
happened to have a working kernel image in <tt>/</tt> (<tt>/vmlinuz</tt>
|
|
for example), you can use that for a boot disk. Supposing all of the above
|
|
conditions, and that my kernel image is <tt>/vmlinuz</tt>, just make these
|
|
alterations to the example above: change
|
|
<tt>/dev/hda3</tt> to <tt>/dev/hda1</tt> (the <tt>/</tt> filesystem),
|
|
<tt>/mnt/src/linux</tt> to
|
|
<tt>/mnt</tt>, and <tt>if=bzImage</tt> to <tt>if=vmlinuz</tt>. The
|
|
note explaining how to derive <tt>/mnt/src/linux</tt> may be ignored.
|
|
<p>
|
|
|
|
Using LILO with big drives (more than 1024 cylinders) can cause problems.
|
|
See the LILO mini-HOWTO or documentation for help on that.
|
|
<p>
|
|
|
|
<sect1>It says `warning: bdflush not running' <p>
|
|
|
|
This can be a severe problem. Starting with a kernel release
|
|
after Linux v1.0 (around 20 Apr 1994), a program called `<tt>update</tt>' which
|
|
periodically flushes out the filesystem buffers, was upgraded/replaced. Get
|
|
the sources to `<tt>bdflush</tt>'
|
|
(you should find it where you got your kernel source), and install it (you
|
|
probably want to run your system under the old kernel while doing this). It
|
|
installs itself as `<tt>update</tt>' and after a reboot, the new kernel
|
|
should no longer complain.
|
|
<p>
|
|
|
|
<sect1>I can't get my IDE/ATAPI CD-ROM drive to work<p>
|
|
Strangely enough, lot of people cannot get their ATAPI drives working,
|
|
probably because there are a number of things that can go wrong.
|
|
<p>
|
|
If your CD-ROM drive is the only device on a particular IDE
|
|
interface, it must be jumpered as ``master'' or ``single.'' Supposedly,
|
|
this is the most common error.
|
|
<p>
|
|
Creative Labs (for one) has put IDE interfaces on their sound cards now.
|
|
However, this leads to the interesting problem that while some people only
|
|
have one interface to being with, many have two IDE interfaces built-in to
|
|
their motherboards (at IRQ15, usually), so a common practice is to make the
|
|
soundblaster interface a third IDE port (IRQ11, or so I'm told).
|
|
<p>
|
|
This causes problems with older Linux versions like 1.3 and below.
|
|
in that versions Linux don't support a third IDE interface.
|
|
To get around this, you have a few choices.<p>
|
|
<p>
|
|
If you have a second IDE port already, chances are that you are not using
|
|
it or it doesn't already have two devices on it. Take the ATAPI drive off
|
|
the sound card and put it on the second interface. You can then disable the
|
|
sound card's interface, which saves an IRQ anyway.
|
|
<p>
|
|
If you don't have a second interface, jumper the sound card's interface
|
|
(not the sound card's sound part) as IRQ15, the second interface. It should
|
|
work.
|
|
<p>
|
|
|
|
<sect1>It says weird things about obsolete routing requests <p>
|
|
|
|
Get new versions of the <tt>route</tt> program and any other programs
|
|
which do route manipulation.
|
|
<tt>/usr/include/linux/route.h</tt> (which is actually a file in
|
|
<tt>/usr/src/linux</tt>) has changed.
|
|
<p>
|
|
|
|
<sect1>``Not a compressed kernel Image file''<p>
|
|
Don't use the <tt>vmlinux</tt> file created in <tt>/usr/src/linux</tt> as
|
|
your boot image; <tt>[..]/arch/i386/boot/bzImage</tt> is the right
|
|
one.
|
|
<p>
|
|
|
|
<sect1>Problems with console terminal after upgrade to Linux v1.3.x<p>
|
|
Change the word <tt>dumb</tt> to <tt>linux</tt> in the console termcap
|
|
entry in <tt>/etc/termcap</tt>. You may also have to make a terminfo entry.
|
|
<p>
|
|
|
|
<sect1> Can't seem to compile things after kernel upgrade<p>
|
|
The linux kernel source includes a number of include files (the things that
|
|
end with <tt>.h</tt>) which are referenced by the standard ones in
|
|
<tt>/usr/include</tt>. They are typically referenced like this (where
|
|
<tt>xyzzy.h</tt> would be something in <tt>/usr/include/linux</tt>):
|
|
<verb>
|
|
#include <linux/xyzzy.h>
|
|
</verb>
|
|
Normally, there is a link called <tt>linux</tt> in <tt>/usr/include</tt> to
|
|
the <tt>include/linux</tt> directory of your kernel source
|
|
(<tt>/usr/src/linux/include/linux</tt> in the typical system). If this link
|
|
is not there, or points to the wrong place, most things will not compile at
|
|
all. If you decided that the kernel source was taking too much room on the
|
|
disk and deleted it, this will obviously be a problem. Another way it might
|
|
go wrong is with file permissions; if your <tt>root</tt> has a umask
|
|
which doesn't allow other users to see its files by default, and you
|
|
extracted the kernel source without the <tt>p</tt> (preserve filemodes)
|
|
option, those users also won't be able to use the C compiler. Although you
|
|
could use the <tt>chmod</tt> command to fix this, it is probably easier to
|
|
re-extract the include files. You can do this the same way you did the
|
|
whole source at the beginning, only with an additional argument:<p>
|
|
<verb>
|
|
blah# tar zxvpf linux.x.y.z.tar.gz linux/include
|
|
</verb>
|
|
Note: ``<tt>make config</tt>'' will recreate the <tt>/usr/src/linux</tt>
|
|
link if it isn't there.
|
|
<p>
|
|
|
|
<sect1>Increasing limits<p>
|
|
The following few <it>example</it> commands may be helpful to those
|
|
wondering how to increase certain soft limits imposed by the kernel:
|
|
<verb>
|
|
echo 4096 > /proc/sys/kernel/file-max
|
|
echo 12288 > /proc/sys/kernel/inode-max
|
|
echo 300 400 500 > /proc/sys/vm/freepages
|
|
</verb>
|
|
<p>
|
|
|
|
|
|
|
|
|
|
</article>
|