I remember back in '00 when [EMAIL PROTECTED] wrote:
> > > map=/boot/System.map
> > > install=/boot/boot.b
> > > prompt
> > > timeout=50
> > > image=/boot/bzImage
> > > label=linux
> > > root=/dev/sda1
> > > read-only
<...>
> when i did 'make install' the problem went away immediately, without even rebooting.
> it created two new map files in /boot however. System.map-2.2.14 is the same as
>/usr/src/linux/System.map (judging by size). the second new file was System.map,
>which wasn't a symbolic link, but a regular file. System.map-2.2.14 is 190k and
>System.map is 35k.
>
> does anyone know what this smaller System.map is?
Ok, I did some poking around on my Debian box, and I think I understand
what happened. (you can skip to THE SHORT ANSWER at the end if you're
not interested in the whole hairy story ;)
[ THE LONG ANSWER ]
There are two files referred to as maps that are being considered
here. There first is a the file generated by the linux kernel
compile which is located in /usr/src/linux/System.map and
gets copies to /boot/System.map-x.x.xx by (among other things)
the kernel's make install. This map file is used by various programs,
including, but not limited to klogd and ps to map addresses in the
kernel to the functions/data they represent. klogd uses the information
to generate a backtrace on kernel OOPS that has function names
and not just numbers. I have the following in my logifles from
when I was playing with the agpgrat module:
Jan 3 11:57:19 cesum kernel: agpgart: Detected an ALi M1541 Chipset
Jan 3 11:57:19 cesum kernel: agpgart: Physical address of the agp aperture: 0xe0000000
Jan 3 11:57:19 cesum kernel: agpgart: Agp aperture is 64M in size.
Jan 3 11:58:36 cesum kernel: Unable to handle kernel paging request at virtual
address c804d3bc
Jan 3 11:58:36 cesum kernel: printing eip:
Jan 3 11:58:36 cesum kernel: c01c62cb
Jan 3 11:58:36 cesum kernel: *pde = 013c2063
Jan 3 11:58:36 cesum kernel: *pte = 00000000
Jan 3 11:58:36 cesum kernel: Oops: 0000
Jan 3 11:58:36 cesum kernel: CPU: 0
Jan 3 11:58:36 cesum kernel: EIP: 0010:[misc_open+43/160]
^^^^^^^^^^^^^^^^
Jan 3 11:58:36 cesum kernel: EFLAGS: 00010206
Jan 3 11:58:36 cesum kernel: eax: c804d3bc ebx: 00000000 ecx: c57e8480 edx:
0000000a
Jan 3 11:58:36 cesum kernel: esi: 00000001 edi: c57e8480 ebp: c785cd40 esp:
c761ff58
Jan 3 11:58:36 cesum kernel: ds: 0018 es: 0018 ss: 0018
Jan 3 11:58:36 cesum kernel: Process gpm (pid: 155, stackpage=c761f000)
Jan 3 11:58:36 cesum kernel: Stack: c785cd40 c7a57760 0000000a 00000001 000000ff
c01fda81 c024a8c0 c012aa17
Jan 3 11:58:36 cesum kernel: c785cd40 c57e8480 c57e8480 00000000 c785cd40
c0129970 c785cd40 c57e8480
Jan 3 11:58:36 cesum kernel: 00000000 c2f28000 00000001 bffffccc c0129b4e
c2f28000 00000002 bffffa98
Jan 3 11:58:36 cesum kernel: Call Trace: [tvecs+14461/23100] [chrdev_open+63/76]
[filp_open+192/260] [sys_open+58/212] [system_call+52/56]
^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^
^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^
Jan 3 11:58:36 cesum kernel: Code: 39 30 75 f2 3d 60 5f 25 c0 75 3e 56 6a 0a 68 d0 14
23 c0 8d
(sorry for the long lines...)
ps uses this same information to tell you where your proecsses are waiting
if they are blocked for I/O:
cesum [249] [8:16am] [/var/log] -# ps -e -o pid,cmd,wchan
PID CMD WCHAN
1 init select
2 [kflushd] bdflush
3 [kpiod] kpiod
4 [kswapd] kswapd
15 update nanosleep
77 /sbin/portmap select
80 [rpciod] rpciod
81 [lockd] svc_recv
137 /sbin/syslogd select
139 /sbin/klogd syslog
146 dictd 1.4.9: 0/0 wait_for_connect
150 ./distributed-ne nanosleep
<...>
Without the System.map for your kernel, those selects and nanosleeps,
would just be numbers. I'm pretty sure that this file isn't essential
for kernel operation (though maybe it's also used for module
operations??)
* * *
The second map file is related to lilo. My best understanding of
the map file is that it is the table of contents to tell lilo where
all of your kernels and associated files are. Without this,
lilo can't boot the kernel, since it doesn't (to my knowledge)
understand filesyatems. It just looks at sector XXX of deivce
YY using standard BIOS calls--to find the map file. Then the map
tells lilo that kernel version Z.Z.ZZ is at some location (maybe
one some other device). You can display the map file that lilo
uses by typing lilo -q (for more info add -v's):
cesum [247] [8:26am] [/] -# lilo -v -v -v -q | more
LILO version 21, Copyright 1992-1998 Werner Almesberger
Caching device /dev/hda (0x0300)
Caching device /dev/hda1 (0x0301)
Caching device /dev/hda2 (0x0302)
<... a list of device numbers vs /dev/ names skipped ...>
Caching device /dev/sdb8 (0x0818)
Device 0x0301: BIOS drive 0x80, 16 heads, 16383 cylinders,
63 sectors. Partition offset: 63 sectors.
Reading boot sector from /dev/hda
Global settings:
Delay before booting: 0.0 seconds
Command-line timeout: 10.0 seconds
Always enter boot prompt
Serial line access is disabled
Boot prompt message is 308 bytes
No default boot command line
Images:
Linux2210 * <dev=0xc0,hd=0,cyl=2,sct=165>
No password
Boot command-line won't be locked
No single-key activation
VGA mode is taken from boot image
Kernel is loaded "high", at 0x00100000
No initial RAM disk
Device 0x0301: BIOS drive 0x80, 16 heads, 16383 cylinders,
63 sectors. Partition offset: 63 sectors.
Device 0x0301: BIOS drive 0x80, 16 heads, 16383 cylinders,
63 sectors. Partition offset: 63 sectors.
No fallback
Device 0x0301: BIOS drive 0x80, 16 heads, 16383 cylinders,
63 sectors. Partition offset: 63 sectors.
Options: "ro root=304 BOOT_FILE=/boot/vmlinuz-2.2.10"
Linux2335 <dev=0xc0,hd=0,cyl=2,sct=184>
No password
Boot command-line won't be locked
No single-key activation
VGA mode is taken from boot image
Kernel is loaded "high", at 0x00100000
No initial RAM disk
Device 0x0301: BIOS drive 0x80, 16 heads, 16383 cylinders,
63 sectors. Partition offset: 63 sectors.
Device 0x0301: BIOS drive 0x80, 16 heads, 16383 cylinders,
63 sectors. Partition offset: 63 sectors.
No fallback
Device 0x0301: BIOS drive 0x80, 16 heads, 16383 cylinders,
63 sectors. Partition offset: 63 sectors.
Options: "ro root=304 BOOT_FILE=/boot/vmlinuz-2.3.35"
<... more kernels skipped ...>
It's all the junk that lilo needs to get linux loaded. This
map file has nothing to do with your System.map file. In my
lilo.conf, there is a line map=/boot/map. When you told lilo
to write its map at /boot/System.map, it was happy to comply,
but various utilties were confused since they excpeted a
totally different kind of file there.
Since (according to the man page) ps looks for System.map
file named /boot/System.map-x.x.xx before it looks at
/boot/System.map, the make install fixed the problem.
[ THE SHORT ANSWER ]
I would just change the map= line in your lilo.conf to
read map=/boot/map, rerun lilo, and then when you're sure that
you are using that new /boot/map and not the old /boot/System.map,
delete it to avoid future confusion. (probably reboot first,
after you're sure lilo got updated correctly).
Sorry to be so long winded, but this was an interesting
question to answer. :-)
Matt
--
/* Matt Sayler -- [EMAIL PROTECTED] -- (512) 494-7360
DO ABSTAIN FROM INTERCAL */
---------------------------------------------------------------------------
Send administrative requests to [EMAIL PROTECTED]
