This is what I have done:

untar the kernel source in /usr/src/
tar xzvf (new-kernel)

delete the softlink rm /usr/src/linux

create a new link to my new kernel source ln -s /usr/src/kernel linux

make mrproper ==> This deletes the file .config! So if you want to compile using your old info then dont run this.

make menuconfig

make dep

make bzImage

make clean (I think it is appropriate here)

make modules

make modules_install

I copied the resulting ..../arch/i386/boot/bzImage to /boot/vmlinuz-2.4.22-new

cp /arch/i386/boot/bzImage /boot/vmlinuz-2.4.22-new

I copied the System.map to /boot/System.map-new

cp System.map /boot/System.map-new

I also have System.map-old and vmlinuz-2.4.22-old in /boot/

Finally I am using LILO.



Now my questions are (primarily out of curiosity)...

1) How do the two kernels distinguish what modules they need to be using in /lib/modules? Is there something that happens during the compile that points the kernel to the proper file in /lib/modules? In that case I cant really move those files around or rename them.

2) What does System.map do and why, if it is important, do I only have to specify only one of them in LILO? Wouldnt this somehow cause problems for me to use System.map-new when booting into vmlinuz-2.4.22-old?

Well I just found out: you should make a softlink System.map --> System.map-(using.this.one) to avoid errors when booting. What I read didnt give specifics though about whether or not the old/new conflict from 2) is a big deal or not....


3) After I compiled my new kernel, I began to get error messages about being unable to (not sure about terminology) run certain modules. I never had that happen before the compile. Why would something like this happen?

I am very picky about doing things incorrectly and having those errors pop up are particularly annoying. My guess is that System.map must indicate something about modules. I am scouring the internet until I find out. If you know something, though, please let me know.

Thanks.

1) It doesn't . You should modify first the uncompressed new 2.4.22 Makefile. @ line EXTRAVERSION= adding something like myker or whatever you like in order to create a new /lib/modules/2.4.22myker directory containing the modules required for the fresh compiled kernel.
2) It is not very important as it tell the kernel what is your configuration that will slighty differ from the previous one. Anyway put in /boot the new System.map.
The old kernel will properly work with the new System.map as well.
3) This should be due to @1) reasons
Ciao

Hey urka58,

Thanks for the reply! Yeah, I used the EXTRAVERSION line to make sure that I would not install over my old modules. I guess what I am curious about is how are those modules accessed by the kernel that I boot? If I boot to vmlinuz-old how does it know to access /lib/modules/linux-old instead of /lib/modules/linux-new?

(Those arent the names of my modules directories of course

And as far as the system.map is concerned, yeah, I can boot into either kernel even if System.map --> System.map-new

I just want to know if there is a way to make sure that LILO calls the proper System.map for the proper kernel. That is all

The kernel does it automatically.(sorry for the stupid response)
Look @ this
http://www-106.ibm.com/developerwork.../tutorials.jsp
there are a lot of nice explanations.
About System.map you the kernel chhose automatically his one if you leave the old System.map in /boot directory,
I guess it will not work to make new System.Map to point the old one or viceversa
Ciao

Thanks for asking this question; I've been trying my hand at recompiling my kernel (first time), and am getting problems with the modules too.

1) I think that the modules path is defined by the kernel version string. For example, before you make bzImage, try editing the /usr/src/linux/Makefile. At the top of the file, you will see a set of variables: VERSION, PATCHLEVEL, SUBLEVEL, and EXTRAVERSION. The first three define the numeric version of your kernel (e.g. 2.4.22). The EXTRAVERSION variable is for any custom string that you want to add to the kernel version; you can add your own here, such as "-custom-031129".

When you make bzImage, the kernel's version, as indicated by the command `uname -r` will be VERSION.PATCHLEVEL.SUBLEVEL+EXTRAVERSION e.g. 2.4.22-custom-031129.

If you remove your prior /lib/modules/2.4.22 directory (and back it up), then do make modules, make modules_install, the new modules path will be named after the new kernel's version (probably through the use of `uname -r`) e.g. /lib/modules/2.4.22-custom-031129.

2 & 3) I don't know what System.map does, but I'd be interested to find out. I've read it, it's a plain text file, but pretty cryptic.

I am also getting errors with modules compiled after a kernel recompile, but l think it has to do with conflicts with prior module dependencies. Still working on this.

You might find kernelnewbies.org helpful.

Well I just found this and it gives a couple hints at the end

from http://www.skybuilders.com/products/...wToKernel.html

Specifically, one should run the following after finishing all kernel compiling and copying files around etc...

depmod

mkinitrd

Well, maybe depmod will solve our problems? That is my guess.

As for mkinitrd I have seen some people complain about not being able to reboot when they have installed, say, their root partition in the ext3 format. I think that stuff like that will be taken care of by mkinitrd.

So if anyone has that problem use

mkinitrd /boot/initrd-2.4.19.img 2.4.19

"initrd-2.4.19.img is the name of the image that you are creating. You can give the name you want to that file but you will have to specify the same name on lilo.conf or grub.conf (see below). 2.4.19 is the name of the kernel found from /lib/modules that you need to use to build the initrd image."
courtesy of this website:

http://www.linuxadvisory.com/article15-page4.html

Take a look at the link so that you can see how to edit lilo or grub to use the new initrd file

Well spurious and urka58, if I figure anything else out I'll post again!

Hey Spurious,

I have found that (and maybe youve found this too by now) by editing modules.conf you can eliminate the errors like char-major not found. Last night I was having errors about something to do with LVM and although I havent fixed them yet, the proper settings in modules.conf will definitely do the trick. Unfortunately I am still a little bit shady about what to write The following is from a post that I found online:

> On Sun, 28 Oct 2001 03:07:19 -0500, Sparhawk said:
> > INIT: version 2.82 booting
> > Bringing up the loopback interface.modprobe: modprobe: Can't locate
> > module net-pf-9 [ OK ]
>
> You need to put
> alias net-pf-9 off
> in you /etc/modules.conf file
> It some kind of networking module, unfortunaly I don't recall what it's
good
> for. If you don't know what it is, you can safely disable it with the line
> above.
>
> > Setting clock.modprobe: modprobe: Can't locate module char-major-10-135
> > [ OK ]
>
> You should put
> alias char-major-10-135 rtc
> in /etc/modules.conf
> It's because you compiled Real Time Clock support as a module in the
kernel.
> Also make sure you have
> crw-r--r-- 1 root root 10, 135 Aug 2 20:39 /dev/rtc
>
> or similar for /dev/rtc

One has to run depmod -a (not sure what -a is for...just havent looked at the man page yet) after doing this to make sure everything is in synk.

Anyway, this isn't specific to my problem but the general idea applies.

Later

Thanks for the advice about depmod; I'm staying away from initrd because I keep getting kernel panics with it, even when I compile filesystem support directly into the kernel instead of modules.

Yo Spurious,

Well I finally found a place where we can answer our questions about the System.map file.

Enjoy

www.dirac.org/p/linux/system.map/

It is an easy read. I am glad to finally understand what that file is used for! Just a detail freak I guess.