Compile kernel: System.map?

iaMMai · 05-18-2005, 06:52 PM

Hi all,
I'm wondering if I'd like to use 2 kernel(2 different versions), for example I'm not sure whether the new kernel works or not, in this case how should I deal with the System.map? If I change System.map symbolic link to the new kernel's System.map, what'll happen when I boot with the old kernel?
Help me,pliz.
Best regards.

syg00 · 05-18-2005, 07:19 PM

Presuming you have things in the correct place, the system will look after itself.
Do some searching, this comes up all the time.

I would also suggest you include your distro - in you profile would be best.
Can certainly affect the answer in this case.

iaMMai · 05-19-2005, 04:01 AM

oh, sorry, my distro is Red Hat 9. I thought it's a general issue. I've searched in Google, but haven't found the answer yet.

If the system can look after itself,then why have we always copy the corresponding System.map to /boot and change the symbolic link:

$ cp arch/i386/boot/bzImage /boot/bzImage-KERNEL_VERSION
$ cp System.map /boot/System.map-KERNEL_VERSION
$ ln -s /boot/System.map-KERNEL_VERSION /boot/System.map

(from this source http://www.digitalhermit.com/linux/K...l#INSTALLATION )

syg00 · 05-19-2005, 05:35 AM

Quote:

Originally posted by iaMMai
If the system can look after itself,then why have we always copy the corresponding System.map to /boot and change the symbolic link

Bloody good question for second post.
Unnecessary in your case - RH adjusts the link for you each boot. Hence my request for your distro.
Have a look at /etc/rc.d/rc.sysinit if you're interested.

I never bother with the symlink, but I do like to keep kernel/config/Sysmap together in /boot with the kernel level in the name. Gentoo documents it this way, and it works. I probably have around 6 kernels in /boot at any time - helps if they are self-documenting.

abisko00 · 05-19-2005, 06:27 AM

The System.map is not used by the kernel, but by 'ksymoops' and 'ps -l'. Hereby the System.map will be searched automatically in the following order:

Code:

/boot/System.map-`uname -r`
/boot/System.map
/lib/modules/`uname -r`/System.map
/usr/src/linux/System.map

As you see, if the System.map is named with the kernel version, the symlink will become unnecessary. In general, the System.map is not a vital component of your system.

This information is from my favourite kernel-HowTo ( www.thomashertweck.de/kernel26.html ), which is unfortunately only available in german and italian.

iaMMai · 05-19-2005, 06:40 AM

Thanks a lot.

Can I ask you another question: what maybe the cause, if the net doesn't work with the new kernel? the network configuration is the same as in case of the old kernel, and I think I have choosen all(or not? :-) ) necessary components for the networking when configuring the kernel in Networking options menu.

syg00 · 05-19-2005, 06:41 AM

Try here for an English equivalent (I hope).

abisko00 · 05-19-2005, 06:47 AM

Quote:

Try here for an English equivalent (I hope).

Nice link, thanks!

Quote:

what maybe the cause, if the net doesn't work with the new kernel?

Many potential causes! Start with the hardware first: is the driver present and is it loaded correctly? Continue with the logfiles (bootlog, messages, warn etc.)...sorry, can't be more specific if you aren't as well

syg00 · 05-19-2005, 06:51 AM

Seems like you missed something - if it was a loadable module, you should still be getting it.
try

Code:

dmesg | less

to see if there are any relevant messages on start-up.
Mind you, RH is a fairly old 2.4 - if you are going to a current kernel, that is quite a jump.
Basically a matter of "eyeballing" the config I suspect.

jschiwal · 05-19-2005, 08:05 AM

If you started out with a different kernel version, (there isn't a .config then in the beginning) you should copy your last .config file and run "make oldconfig" to pick up your old configuration options, and select new options that were not present in the old kernel. Then fine tune it with "make xconfig" or one of the alternatives. Old pro's at this often use an editor to make changes, and then run "make oldconfig" to validate their changes.