What is a system map, part 2?
Jean-David Beyer
at my directory, /boot. Some of the stuff is there because I
did a rpm -Uvh kernel.* . The rest is there because I did
/sbin/lilo with the following in /etc/lilo.conf:
boot=/dev/sda
map=/boot/map
install=/boot/boot.b
prompt
linear
timeout=50
image=/boot/vmlinuz-2.2.14-5.0.14csmp
label=linux
root=/dev/sda5
read-only
image=/boot/vmlinuz-2.2.14-5.0.14c
label=linux-up
root=/dev/sda5
read-only
image=/boot/vmlinuz-2.2.12-0.1smp
label=linuxOld
root=/dev/sda5
read-only
image=/boot/vmlinuz-2.2.12-0.1
label=linux-upOld
root=/dev/sda5
read-only
Notice that the default kernel with which I run is the one in
/boot/vmlinuz-2.2.14-5.0.14csmp.
But when I list /boot, I see (boring stuff deleted):
lrwxrwxrwx 1 root root 25 Oct 9 18:12 System.map ->
System.map-2.2.14-5.0.14c
-rw-r--r-- 1 root root 205841 Aug 26 1999
System.map-2.2.12-0.1
-rw-r--r-- 1 root root 216825 Aug 26 1999
System.map-2.2.12-0.1smp
-rw-r--r-- 1 root root 203421 May 31 12:42
System.map-2.2.14-5.0.14c
-rw-r--r-- 1 root root 214729 May 31 12:32
System.map-2.2.14-5.0.14csmp
Similarly for these:
lrwxrwxrwx 1 root root 26 Oct 9 18:12 module-info ->
module-info-2.2.14-5.0.14c
lrwxrwxrwx 1 root root 22 Oct 9 18:12 vmlinuz ->
vmlinuz-2.2.14-5.0.14c
I guess my question is: does anyone (i.e., any process,
including the kernel) use these symbolic links? Because if so,
I should change them to point to the kernel I normally use. But
that raises another question: If I boot a different kernel,
perhaps because I installed one that is no good as the latest
one, I will get the wrong values for the symbolic links. What
are the consequences of this?
--
.~. Jean-David Beyer Registered Linux User 85642.
/V\ Registered Machine 73926.
/( )\ Shrewsbury, New Jersey
^^-^^ 7:40am up 3 days, 13:19, 2 users, load average: 2.17, 2.14, 2.10
J.Smith
Oh boy, here we go again... :)
For the viewers that have just tuned in, there was a tread on
comp.os.linux.misc not so long ago that discussed the need for and use of
the /boot/System.map file. There also seemed to be some confusion about how
to handle 2 different kernel's in /boot, and the two different
/boot/System.map files that go with it.
Although there was no conclusive evidence, the current status seems to be as
such:
System.map is a "map" of your kernel. It contains info about the entry
points of the functions you compiled into your kernel, and de-bug
information. The kernel itself knows the addresses and entry-points, but
that file is needed for some programs which need info about kernel entry
points. These programs are klogd(8), ksymoops(8), depmod(8), and the procps
tools (ps(1), top(1), ...). These programs don't all do the same thing in
looking for System.map files. depmod(8) doesn't need a System.map file if
it's operating on the currently running kernel. ps(1) and klogd(8) like to
find a System.map file, but don't look in the same places.
You may have noticed that I have taken the liberty of cross-posting this
message to os.linux.development. Although this may seem a little bit odd, or
off-topic for this newsgroup, but I guess that the only people who can
really clarify what system.map is used for and how you should handle two
kernels&map files are the guys who actually know something about the
source-code :)
------------------------------------------------------------
>
> All this talk about the "system.map" file prompted me to look
> at my directory, /boot.
Jean-David Beyer
> Oh boy, here we go again... :)
The reason we go here again is because it seems to me that there is no
justification for the symbolic link "System.map". If you have only one kernel
in /boot, you could do that, but since most of us have more than one kernel
around (I have both smp and up kernels, both current and old, and some may have
new or test ones as well, it is essentially useless to have that pointer. In my
case, there is only a 25% chance that it would be pointing in the right place,
presuming (falsely) that I boot each with equal probability.
My distribution seems to come with the smp version as the standard thing to
boot, but the links all point to the up versions of the files. Is my
distribution wrong and I chould change the symbolic links? Or does it not
matter because the symbolic links are not used? I have noticed no symptoms;
could someone suggest the symptoms I would get with the symbolic links pointing
to the wrong files?
These files are pretty different:
205841 Aug 26 1999 System.map-2.2.12-0.1
216825 Aug 26 1999 System.map-2.2.12-0.1smp
203421 May 31 12:42 System.map-2.2.14-5.0.14c
214729 May 31 12:32 System.map-2.2.14-5.0.14csmp
At least, I assume that since their sizes are different that their contents
are different as well.
> For the viewers that have just tuned in, there was a tread on
> comp.os.linux.misc not so long ago that discussed the need for and use of
> the /boot/System.map file. There also seemed to be some confusion about how
> to handle 2 different kernel's in /boot, and the two different
> /boot/System.map files that go with it.
>
> Although there was no conclusive evidence, the current status seems to be as
> such:
>
> System.map is a "map" of your kernel. It contains info about the entry
> points of the functions you compiled into your kernel, and de-bug
> information. The kernel itself knows the addresses and entry-points, but
> that file is needed for some programs which need info about kernel entry
> points. These programs are klogd(8), ksymoops(8), depmod(8), and the procps
> tools (ps(1), top(1), ...). These programs don't all do the same thing in
> looking for System.map files. depmod(8) doesn't need a System.map file if
> it's operating on the currently running kernel. ps(1) and klogd(8) like to
> find a System.map file, but don't look in the same places.
I get what seem to be correct /var/log/messages files even though my System.map
link is pointing to the wrong System.map-2.2.whatever. Likewise, the ps(1) and
top(1) commands work as expected.
> You may have noticed that I have taken the liberty of cross-posting this
> message to os.linux.development. Although this may seem a little bit odd, or
> off-topic for this newsgroup, but I guess that the only people who can
> really clarify what system.map is used for and how you should handle two
> kernels&map files are the guys who actually know something about the
> source-code :)
>
> ------------------------------------------------------------
>
> >
> > All this talk about the "system.map" file prompted me to look
> > at my directory, /boot.
> > I guess my question is: does anyone (i.e., any process,
> > including the kernel) use these symbolic links? Because if so,
> > I should change them to point to the kernel I normally use. But
> > that raises another question: If I boot a different kernel,
> > perhaps because I installed one that is no good as the latest
> > one, I will get the wrong values for the symbolic links. What
> > are the consequences of this?
> >
--
.~. Jean-David Beyer Registered Linux User 85642.
/V\ Registered Machine 73926.
/( )\ Shrewsbury, New Jersey
^^-^^ 2:20pm up 5 days, 19:58, 3 users, load average: 2.08, 2.12, 2.09
J.Smith
The following is cut 'n pasted from the reply of "Ben Caradoc-Davies", a
friendly netizen who replyed to a similar tread in
comp.os.linux/development:
-------------------------------------------
/boot/System.map is used by ksymoops to convert addresses (in kernel oops)
into symbols.
man ksymoops
Does lilo need it?
No.
Is it needed for loadable modules?
No.
Do other applications use this file?
There is nothing stopping them. :-)
/boot/System.map is a symbolic link to the appropriate map file. You can do
this by hand, or in the case of recent RedHat releases, this link is updated
at boot time by the following in rc.sysinit:
if [ -L /boot/System.map -a -r /boot/System.map-`uname -r` ] ; then
ln -s -f System.map-`uname -r` /boot/System.map
fi
s. keeling
>
> /boot/System.map is a symbolic link to the appropriate map file. You can do
> this by hand, or in the case of recent RedHat releases, this link is updated
> at boot time by the following in rc.sysinit:
>
> if [ -L /boot/System.map -a -r /boot/System.map-`uname -r` ] ; then
> ln -s -f System.map-`uname -r` /boot/System.map
> fi
I know, I sound like an Amiga fan, but if you used Debian,
kernel-package would manage all this for you.
--
keeling@.spots.ab.ca.INVALID (Stephen) TopQuark Software & Serv. Enquire within.
s/\.INVALID// Contract programmer, server bum.
Any technology distinguishable from magic is insufficiently advanced.