Building the Lastest Compilers and Tools
by
First of all, some really authoritative instructions reside at http://metalab.unc.edu/LDP/HOWTO/Kernel-HOWTO.html.
Your kernel source resides at /usr/local/linux, don't under-estimate the importance of the README file that's there, along with the Documetation subdirectory which explains a lot about modules (in modules.txt and networking/net-modules.txt).
The most important thing to know is that kernels must be built from /usr/src/linux, many of the header files depend on this.
As such, it's usually a good idea to make linux be a symbolic link pointing to the actual directory that contains the source code. For example, I delete my linux symbolic link, grab a new kernel and untar it in the directory, rename the newly created directory and reestablish a symbolic link.
/usr/src# tar zxvf linux-2.4.20.tar.gz /usr/src# mv linux linux-2.4.20 /usr/src# ln -s linux-2.4.20 linux /usr/src# cd linux /usr/src/linux# |
IMPORTANT
Failure to remove linux risks a high chance of overwriting your existing kernel source. |
I prefer using symbolic links in order to go back and rebuild prior distrubtions, if it ever becomes necessary.
The latest kernel can be obtained from any number of places including: http://www.kernel.org/ and ftp://ftp.tux.org/kernel/.
- If you are looking for entire distributions try
ftp://ftp.cdrom.com/pub/linux/
or ftp://ftp.tux.org/distributions/.
-
A word about Alan Cox patches.
Alan maintains a set of kernel patches contain newer drivers, new
features, and things that are generally considered more intrusive
to the code base and less-tested than Linus is ready for. So,
if you want the next generation features, goto
ftp://ftp.kernel.org/pub/linux/kernel/people/alan/ and snag the patch file for your
kernel version.
-
$ cd linux
$ gzip -dc ../patch-2.4.20-acxx.gz | patch -p1
I almost never apply patches, rather I find it much simpler to just get the entire kernel as a whole and build from there.
Building the kernel isn't complex, you just have to understand what each step does.
/usr/src/linux# make mrproper
This completely cleans out your binary directories. I only do this if
I've really screwed something up. Note that this deletes your
.config file, so you might want to rename it first!
I hardly ever do this.
/usr/src/linux# make menuconfig
This is where you set all the configuration parameters for the kernel.
The general gist is that you can build stuff into the kernel,
make it a module for loading later, or exclude it all together (saving
in size). Your settings typically go in a configuration file called
.config. Other commands are make config and
make xconfig, should you be using X Windows for the latter.
/usr/src/linux# make dep
This determines all the header file dependencies. Do this whenever
you've made a change to the configuation.
/usr/src/linux# make clean
If you've already built the system and are making minor changes,
not wanting to re-compile all the objects again, skip
this step. If you want to be a purist and make sure you're starting
absolutely fresh, do this step.
/usr/src/linux# make bzImage
This compiles the kernel, compresses it, and saves it in
arch/i386/boot/bzImage. (Your platform may vary,
so read the output string.) It is possible to do a
make bzdisk and send the image to a previously inserted
floppy for testing.
/usr/src/linux# make modules
If you selected modules <M> for any part of the
kernel, you'll have to build them as well.
/usr/src/linux# make modules_install
This moves the module binaries to /lib/modules/kernel_version.
/usr/src/linux# make install
Honestly, I'm not sure what this one is doing in full. But, I believe it
moves the System.map file to the root directory so that the
kernel can autoload modules properly. I think it also does some tricks
with the rdev command to instruct the kernel which drive is
the root drive when booting.
/usr/src/linux# cp arch/i386/boot/bzImage /kernel-x.y.z
When I check the kernel at the root with the one in the arch/i386/boot
directory, it's usually always different in size and date. As such, I
move the kernel manually, to the root directory, using a name that is very
clear about what it is.
/usr/src/linux# cp /System.map /boot/System.map
I've found that for some reason the System.map file doesn't
always get copied to this location. This seems to be where
lilo gets its information when it installs.
-
According to www.kernelnewbies.org,
the "System.map is a file (produced via nm) containing
symbol names and addresses of the linux kernel binary, vmlinux.
"Its primary use is in debugging. If a kernel "oops" message appears, the utility ksymoops can be used to decode the message into something useful for developers. ksymoops makes use of the System.map to map PC values to symbolic values. Note that 2.5 kernels have an in-kernel oops decoder called kksymoops, which does not need System.map."
According to other how-to sources, System.map can (and should) be placed in /boot, rather than /, and can event be renamed /boot/System.map-2.4.20.
/usr/src/linux# liloconfig
I either use this utility, or more likely, edit
/etc/lilo.conf by hand. I make an entry for the newest kernel
and I always try to leave one old kernel around, just for emergencies.
-
You may want to take a look at the LILO how-to and lilo man pages
which explain how to configure your system if it's got all kinds
of weird setups.
/usr/doc/Linux-mini-HOWTOs$ less LILO
$ man lilo.config
$ man lilo
This actually makes the kernel get installed, so it can be booted. The top two steps can often be done, under default configurations, with make bzlilo -- the catch is that you must name your kernel /vmlinuz for the scripts to work.
Editing the loadable modules list
You'll note that in /etc/rc.d/rc.modules there is a command
to figure out module dependencies and bunch more to load various
modules. If you made some things modules, you'll want to make sure
those lines are uncommented.
Ctrl-Alt-Del
Reboot the system and invoke the new kernel.
You may have to play with some of your configuarion settings to
get it all to work right.
Include files which depend on kernel internals should be symbolically linked to your kernel source.
-
# cd /usr/local/include
/usr/local/include# rm -rf asm linux scsi
/usr/local/include# ln -s /usr/src/linux/include/asm asm
/usr/local/include# ln -s /usr/src/linux/include/linux linux
/usr/local/include# ln -s /usr/src/linux/include/scsi scsi
Do NOT delete your kernel source after building the kernel; you need it
in order to build software.
|
•••About •••Articles •••Links •••Search Tips |