Kernel Creation (was Mwave Winmodem)

ME dugan at passwall.com
Tue Dec 10 13:08:27 PST 2002


When you configure a new kernel, you only prepare the source tree of a
kernel to be compiled with support for the options you have selected.
The source code is not the same as a new kernel or new os. The new
kernel is the product of using the instructions fromt he source tree to
build a kernel.

What changes when you get a new kernel?
You can get changes  support for hardware. Sometimes this means loss of
support for some hardware, but most of the time, the new kernels means
more support for more hardware or better support for older hardware.

You should generally only upgrade a kernel if there is some new feature
that you feel you need. (Security updates are a good example.)

Improper kernel building can mean forgetting to include support for
critical hardware - leaving your system unbootable...

Generally speaking, there are some risks when compiling your own kernel.
RedHat does things a bit differently with their packaged kernels, and
unless you know a lot about building kernels, you can leave yourself in
a bad position.  :-(

I want to encourage you in building your own kernel, but suggest some
items for you to examine as you are testing new kernels that you build
by hand so that you (hopefully) dont leave yourself in a position where
your system is unbootable. (Small risk if you follow the rules.)

1) If you are using kernel based RAID (mirroring, etc) for the volume
that contains your "root" (/) filesystm, then you will need to examine
used of an initrd. (There is redhat software to help you with this, but
I will assume you have not set up mirroring orsoftware RAID on your
box.)

2) Whenever you first build a kernel, it is a very good idea to to to
get the ".config" file used by your vendor to build their kernel. This
will save you *much* time.

3) When you "install" the new kernel (tell your boot manager, (lilo,
grub, partition magic) do *not* discard your old kernel! You know that
kernel works, and you may need to fall back on it if/when something in
your new kernel does not work as it should.

If you can get a previous kernel's (with same "major" number) ".config"
file, you can make your life much easier.

Take that ".config" file and copy it to your newer kernel's source
tree's base directory. Them try: # make oldconfig
you will see an older interface (no menus) and you will see text fly by
the screen for options previously set on the previously "working"
kernel. It should only stop and actually ask you for input when it
encounters an option not previously available in the kernel from which
the ".config" file was copied.

Only after you get to the end, will the new information you have
selected be stored in the ".config" file.

After you have used the "make oldconfig" and the new .config file has
been saved, try: # make menuconfig
(this require curses/ncurses libs be installed, but seems to be
installed on most major distros anyway)

This will permit you to use the menu interface to select and review the
same options you saw before if you configured another kernel.

Shorter Rankin said:
> OK so you want another rookie question?
> I went to www.kernel.org and got
> linux-2.4.20.tar.gz (new kernel
> sources). Copied the tarball to
> /usr/src ran gzip -cd linux-2.4.20.tar.gz | tar xvf -
> So far so good. Now if I run configure am I
> just installing the new kernel or am I
> recompiling the whole system?
>
> The existing kernel is 2.4.18-14
> RH 8 demo. Do I need to
> create a symbolic link somewhere?
>
> Can I run menuconfig and if so
> from what directory? Among
> other things I want to build in
> support for an old Iomega
> Zip 100 parallel drive.
>
> TIA,
> Shorter





More information about the talk mailing list