[lug] System.map issue

[D. Stimits]

Chris Riddoch wrote:
> 
> "D. Stimits" <stimits at idcomm.com> writes:
> > 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]
> 
> Okay, I should've checked that before just assuming the server
> wouldn't treat .map files like that...
> 
> Try this, then:
> 
> http://www.peakpeak.com/~socket/System.map-corrupted.txt

Corrupted is indeed strange. Did you test if the actual copy from
/usr/src/linux/ to the /boot/ directory is uncorrupted *prior* to
running lilo? If it is corrupted before hand, you have a filesystem or
copy error. If it is corrupted only after running the boot loader
update, then it is your boot loader update that is the problem.

> http://www.peakpeak.com/~socket/System.map-original.txt
> 
> > 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?
> 
> No, it's not. I've posted that to the website so you can be sure of
> it.

Uncorrupted does look like it should.

> 
> > Also, it is a *very* good idea to not copy it as System.map
> 
> I didn't, originally. I apparently use the same naming convention as
> you for System.map, and I changed lilo.conf appropriately. I tried it
> both ways, and both ways, it gets corrupted.

Before or after running lilo or your boot loader program (some people
use grub these days)?

> 
> > ...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.
> 
> Yes, I noticed the permissions changed, too. This is the original:
> 
> socket at laptop:~$ ls -l /usr/src/linux/System.map
> -rw-r--r--    1 root     root       428641 Feb 21 13:15 /usr/src/linux/System.map
> 
> And this is what it gets changed to, in it's corrupted form.
> 
> socket at laptop:~$ ls -l /boot/System.map
> -rw-------    1 root     root        26624 Feb 22 12:53 /boot/System.map

It is truncated. Is /boot/ on the same partition as the main partition,
or is it a separate partition? If it is part of the root partition and
ext2, you will have a directory /lost+found/, and if /boot/ is its own
partition and ext2, you will have /boot/lost+found/. Go into whichever
applies, see if it has something there. If so, it means fsck had nodes
it couldn't figure out and  moved them there. Often a result of
rebooting or crashing while the filesystem is in use for writing. Btw,
just to be certain, after you run lilo update, run sync before reboot.
It should be entirely unnecessary, but it won't hurt considering you are
debugging.

> 
> > And if the file is different between the compile directory root and
> > the /boot/ version, then replace it again with the compile directory
> > version.
> 
> Every time I shutdown and start up again, it's corrupted. Every time I
> notice it's corrupted, I replace it with the original.  I'd like to
> not have to keep copying my System.map file every time I boot my
> machine.
> 
> I even tried removing write permissions from System.map. It *still*
> got changed.

Most bootup scripts will use root permissions and force any writes. I'm
curious if there is some access to /boot/ that is stalling out and thus
causing an unclean umount. Now if /boot/ is a separate partition, you
can run fuser -v on /boot and I would expect the only access just before
reboot would show up as "/boot  root kernel  mount  /boot". If you have
a shell open and have done a cd to that directory, it could conceivably
cause an unclean umount if the process of the shell or something the
shell is running fails to terminate before the filesystem umount.

> 
> *Something* is breaking this, and it's clearly not a problem with the
> original file.

What is in your lilo.conf? I would have to wonder if the System.map is
being named for something other than what it should be named as.

D. Stimits, stimits at idcomm.com


> 
> --
> 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