Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Help building a new kernel...



On Fri, 8 Oct 1999, Christoph wrote:

> I'm trying to build a new kernel for my system and not having much luck.

Well, here's my usual process:
1) download a new kernel/patchset.
 * For a kernel, just do a tar -zxvf linux-xxxxx.tar.gz.  This makes a
   "linux" directory for you.  /usr/src is a good place to do this :)

 * For a patchset, usually 'gunzip <patch> | patch -p0' works, I think.
   Whenever I forget, I look at the kernel howto.

2) Move into the directory, and do a make clean/make mrproper if it's a
   patchset.  Clean removes all object files, etc., whereas mrproper blows
   away everything from kernel configuration to the compilation count
   (look at 'uname -a' sometime...the #xx is a compilation count).

3) Make menuconfig/config/xconfig.  I usually am ssh'd in, so menuconfig
   is kinda nice.  But, if you have an X display, xconfig might be nicer.

4) Follow the instructions after config (It says either to 'make clean;
   make dep' or to 'make dep; make clean'.  I can't remember at the
   moment).

*** The rest must be done as root ***

5) make install (bzInstall/zInstall).  This usually takes care of all the
   file locations for you.

6) make modules; make modules_install

7) Look at your /etc/lilo.conf, and make sure it says what you want.
   Specifically, you should have an entry for your old kernel.  If it
   doesn't, look for the old kernel - it should be in the same directory 
   as the new one.  Add a new entry by copying the entry for the current
   kernel, changing the image path appropriately.  If you have to do this, 
   then re-run /sbin/lilo.  (install does this for you; if you change it,
   you have to do it again)

8) Re-boot and be happy:)


> System: Intel DK440LX MB with single PII 266 (kernel I'm building
> includes SMP)
>     OS: RedHat 6.0

OK, is there a reason you're using an SMP kernel?  Would that be an SMP
board?  If it's a single board, then SMP is just spare code to eat up your
CPU cycles (much like WinNT), and you should probably remove it in a
kernel recompile.  If it's a dual board with a single processor, then I
don't really know what to suggest; has anybody tried a single processor
kernel on a setup like that?  I can't imagine that really hurting
anything...

> I don't understand a few key points and can't seem to find adequate
> documentation.  Here are my questions...

How up-to-date is the kernel HOWTO?  And have you tried looking under the
Documentation directory for the kernel tree?

> 	1) How do I build a kernel with a new version identifier, such that
> 	   when it is working, uname -r will report the new version?
> 	   And more importantly, it'll find it's modules in
> 	   /lib/modules/[new-version]

Once you reboot with a new kernel, it should happen automagically :)

uname gets its information from the kernel itself; you can do something
similar by catting /proc/version (IIRC).

As for the module path, I remember 'back in the day' just using
/lib/modules/default, and having an init script check the kernel version
at startup, change the symlink to the appropriate real directory, check to
see if all the module stuff has been done, and do it if it hasn't.
Nowadays I think that RedHat does all that for you.

> 	   * Note : I just looked at /etc/rc.d/rc.sysinit and believe the
> 	   module path it actually set in there with depmod

Ah, so RedHat does do it for you.  :)

> 	2) What is the function of /boot/initrd-xxxxxxxxx?
> 	   There exists such a file for the supplied and installed kernel,
> 	   but not for my newly built kernel.  Where does it come from?

That I'm not sure of.  I've never seen it before.  I do know, however,
that initrd is kinda short for init root disk, which is important for
making floppies bootable.  I'm not sure that you really need it.

Oh, and from hat I hear, kucos for not using the kernel upgrade rpms; I
hear they are a true pain in the neck.

HTH,
--Mark

-
Subcription/unsubscription/info requests: send e-mail with
"subscribe", "unsubscribe", or "info" on the first line of the
message body to discuss-request at blu.org (Subject line is ignored).




BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org