Hi all,
FWIW, here's my 2 bits on kernel building. I picked up these habits from Red
Hat 4, way back when, and they have never failed me. IMHO, every Linux user
should be able to build their own kernel. At the very least, it speeds up the
Linux boot time. Unfortunately for some, this info is Red Hat/Mandrake
oriented but then, so is Win4Lin. I guess the general feeling is that Debian
and Suze users should be smart enough to adapt these things. :-)
Most, if not all, distributions are configured to run on as many systems as
possible and leave the optimization and customization to the end user. This
capability is one of main reasons I love using Linux. It is also the bane of
most new Linux users, especially those converts from Windows where
customization is limited and often discouraged. With a proprietary OS like
Windows you will never be able to use the full power of your system.
I'm sure this project scares many new Linux users since it sounds technical
but it really isn't that bad. I often test various programs against several
versions of the Linux kernel and often wind up patching and/or building
kernels. So often that I even created a simple script to automate the compile
section which I run after the configuration step.
First and foremost, be prepared. This means keeping the ability to boot the
system no matter what. My method is to keep the original configuration
intact and compile from a modified copy of the source or a completely new
version. I prefer using pristine source from kernel.org (please use a mirror
site :-) ) but you can use the source from the distro if you change the
EXTRAVERSION value in /usr/src/linux/makefile.
FWIW, I have never needed the 'make clean' step when building a kernel. My
method also ensures that modules will always match the kernel without any
older modules interfering. Keep in mind that the kernel and modules are the
heart of your system and as such deserve the utmost care when building
them. Yes, it requires more time, especially on older hardware but in the
end it will pay off in system stability.
Another important point when using multiple source versions is keeping the
/usr/src/linux symlink pointing to the correct source tree. I use the Red Hat
aka Mandrake init script /etc/rc.d/rc.local which runs at the end of the
system boot cycle. It only needs a few lines added.
-- cut here --
# get the kernel version, if you want to clean up the script a little, use
# this variable in the console section to replace the uname function
# used there.
v=$(uname -r)
# ensure the source symlink matches the running kernel version
rm -f /usr/src/linux
ln -s /usr/src/linux-$v /usr/src/linux
-- to here --
As mentioned by another user, I also save configurations in a unique file in
case I need to change something. It makes adapting a new kernel a little bit
easier when I only need to change a few settings. Just make sure to verify
all the settings during the initial configuration. Should something not work
and you need to rebuild, follow the same steps and load the settings file
during the make menuconfig (or xconfig) step.
It should also be mentioned that modules get installed into a directory
which matches the kernel version and this directory should be clean, ie no
existing files. In spite of what some may have heard, it is safer to always
perform a clean build. Especially when the kernel changes are as deep as the
W4L patches are.
ex: /lib/modules/2.4.3-20.w4l
FWIW, I prefer to use Midnight Commander (console ver.) which simplifies
copying the kernel source and modifying the /usr/src/linux symlink as well
as editing any files which may need it. IMHO, it is the most versatile
utility I have used in Linux. However, you should use whichever method you
prefer.
The actual source tree should be in a directory which matches the kernel
version in the makefile. Here is an example listing of the /usr/src
directory.
/usr/src/..
~linux
linux-2.4.3-20mdk
linux-2.4.3-20.w4l
linux-2.2.18.0
In this sample, ~linux points to /usr/src/linux-2.4.3-20.w4l To patch the
kernel source, this symlink must exist or the patch will apply to the wrong
source tree. I use a modified W4L patch script which lets me install patches
to various kernel sources using a command similar to the following;
dopatch w4l
Where w4l is the name of the patch file and ends with the .patch suffix.
Note, the .patch suffix is not needed in the command line. The patch names
are usually some long and descriptive name which relates to the version.
-- cut here --
# a simple W4L patch script /usr/bin/dopatch
patch -p1 -d /usr/src/linux -b <$1.patch
-- to here--
You should ensure that any patch installs properly.
Here is the build script I use.
-- cut here --
# build kernel script
#
# this script uses the && to execute the next step only if the current
# one completes properly (as my understanding of it.) and the \ to
# join the lines into one command which is passed to bash. It could
# have been written on a single line but it is easier to read this way.
#
# edit the following line to match the kernel version
a=2.4.3-20.w4l
#
make dep && \
make bzImage && \
make modules && \
rm -Rf /lib/modules/$a && \
make modules_install && \
cp -f /usr/src/linux/arch/i386/boot/bzImage /boot/vmlinuz-$a && \
cp -f /usr/src/linux/System.map /boot/System.map-$a
-- to here --
At this point you should have this configuration or one very similar:
1) A system which boots the original setup with matching source tree.
2) W4L/kernel source in it's own directory tree.
3) makefile with version info which matches the directory name
4) build script with matching version info (unless you prefer to enter
the commands yourself :-) )
5) modified init which sets the proper symlink
The only complicated procedure left is the actual kernel configuration which
depends upon the hardware in your computer.
To recap, assuming you have made the bash scripts, enter these commands to
build your kernel.
make mrproper
make menuconfig (or xconfig. I prefer the console for this)
./build
If the configuration is correct the kernel will compile and the files will
all be in their proper place. Now you are ready for the boot configuration
steps. If this is the first time compile, you will need to add an entry into
your boot loader. Use the existing entries as an example.
For 'grub' you enter this info in the /boot/grub/menu.lst file. Then save
the file and reboot the computer.
For 'lilo' you enter it into /etc/lilo.conf and execute the command
/sbin/lilo which rebuilds the boot info.
If you have been paying attention, you will notice the lack of 'initrd'. I
prefer to avoid using this method unless there is no other alternative. When
booting from lilo or grub with a custom kernel, it is seldom needed. I have
used this method on my server which uses software raid with a Reiser file
system. All that matters is the important pieces are built into the kernel
and not modules.
One more caveat which applies to any W4L users who overclock their system.
If you are having any problems whatsoever, turn off the overclocking and try
things again.
Sorry this message is so long but I guess I'm making up for all the time I
spend just reading the digests without contributing. :-) I still miss the
old beta test group. I think many of the problems mentioned here would have
been corrected well before the official release. Unfortunately, NeTraverse
was often maligned by some users and I can't blame them for eliminating
it. As always, IMHO.
Cheers,
Mike T.
_______________________________________________
Win4Lin-users mailing list
[EMAIL PROTECTED]
https://lists.netraverse.com/mailman/listinfo/win4lin-users
