[lug] System.map issue

[D. Stimits]

Chris Riddoch wrote:
> 
> Hi, everyone.
> 
> I just installed Debian Testing on my new laptop (yay!) and so far,
> it's doing remarkably well. There are a couple glitches (Apache didn't
> like its new access.conf) but here's a quick question. I'm sure
> there's an easy answer.
> 
> /boot/System.map was created when I made my 2.4.17 kernel.  When I
> copied it to the right place and ran lilo, everything was fine.
> During the next bootup, I noticed a lot of errors like the following:
> 
> > Warning: /boot/System.map not parseable as a System.map
> 
> So I took a look at it, and found that it got corrupted somehow.  In
> case it's helpful for someone to see it,
> http://www.peakpeak.com/~socket/System.map
> is the corrupted version.

The web page isn't displayable. You may also wish to rename it on the
web page System.map.txt. The display is:
  [an internal server error occured] 

Is your file in /usr/src/linux/System.map (I assume this is the same
place in Debian as in RH and Slackware and many others) also corrupted?
Also, it is a *very* good idea to not copy it as System.map, but instead
use the name structure of the kernel. That name structure will allow
search for that file to identify the version for this particular kernel
when you have multiple kernels. Basically you add as suffix the value
that uname -r would have So if your new kernel had uname -r of "2.4.17",
you'd copy it as System.map-2.4.17. If you go into the toplevel
Makefile, you can also use the EXTRAVERSION line (do not leave excess
spaces in, they do count on the right side of the '=' symbol) to give it
a sub version for a particular build (but keep it short, there are name
length restrictions). For example, you might initially set it to:
EXTRAVERSION =-1

At that point, make clean and build again, your uname -r would be
2.4.17-1. Thus your system would find /boot/System.map-2.4.17-1 just
fine. It could coexist with all of your other System.map's no matter how
many versions you have available for multiple booting (e.g., rescue,
test versions, trying out new hardware options, so on). You can also
name your initial ramdisk in a similar fashion with a few details of
initrd and lilo or whatever bootloader, assuming you use an initial
ramdisk.

Anyway, getting back on track, I think only root needs to read this file
during boot, but possibly others will later. And if some strange daemon
runs as another user at some point during boot, perhaps a non-root user
needs to read it earlier on. Perhaps it is silly, but be sure it is
world readable. And if the file is different between the compile
directory root and the /boot/ version, then replace it again with the
compile directory version. If it is corrupted in both places you
probably need to recompile your kernel (if the kernel options are
exactly the same, you can try to recompile but copy *only* the
System.map and not all the other install procedures).

D. Stimits, stimits at idcomm.com

> 
> And yes, I did make sure lilo is pointed to the right System.map file
> and ran lilo -v it before rebooting. No errors. It's weird.
> 
> This doesn't happen until I shutdown or startup, and I'm not sure if
> something in the /etc/init.d/ scripts is hosing it or if I've got
> bigger problems. What's going on here?
> 
> --
> Chris Riddoch       | epistemological
> socket at peakpeak.com | humility
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug