[lug] System.map issue

[Chris Riddoch]

"D. Stimits" <stimits at idcomm.com> writes:
> > 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?

I'm quite positive that /usr/src/linux/System.map is NOT corrupted.
Again, it's at http://www.peakpeak.com/~socket/System.map-original.txt
if you're unconvinced.

> > 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[...]?

It gets corrupted sometime between the time I run 'shutdown -r now'
and the time the init scripts start trying to do things that touch
System.map for whatever reason.

grepping /etc/init.d/ for System.map shows that it only gets passed as
a parameter to /sbin/klogd. I wonder if klogd is doing it?

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

Nope.

socket at laptop:/boot$ sudo md5sum System.map
78274e85a299d62404d8776859e235ea  System.map 
socket at laptop:/boot$ cd
socket at laptop:~$ dd if=/usr/src/linux/System.map of=./Sys.map bs=1 count=22624
22624+0 records in
22624+0 records out
socket at laptop:~$ ls -l Sys.map
-rw-rw-r--    1 socket   socket      22624 Feb 22 16:37 Sys.map
socket at laptop:~$ md5sum Sys.map
330fd046a390c73e2fb80fc2809da7a7  Sys.map

Now, if it were only *truncated*, the md5sum would match here, wouldn't it?

socket at laptop:~$ md5sum System.map-corrupted.txt 
78274e85a299d62404d8776859e235ea  System.map-corrupted.txt

If you, or someone else, could help me figure out what the heck it's
being replaced *with*, that would probably be a hint about what's
going on here. 'file System.map' just says a rather uninformative
"data". It's at a URL I've already given in this thread.

> Is /boot/ on the same partition as the main partition, or is it a
> separate partition?

Separate partition.

socket at laptop:~$ ls /boot/lost+found/
socket at laptop:~$ ls /lost+found/
socket at laptop:~$

And there's no fscking going on at bootup. No evidence of crashing or
general trashing of the filesystem.

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

User processes *should* get killed long before the unmount processes
run.  In my experience, unmount operations are relatively conservative
and will refuse to unmount a busy system - so if this were the case,
I'd at least notice something like what happens when I try to unmount
my CDROM when I'm playing MP3s from it:

umount: /cdrom: device is busy

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

This is the significant part of what's in my lilo.conf:
map=/boot/System.map

Previously, it was:
map=/boot/System.map-2.4.17

The only thing this seems to determine is which file gets corrupted.
The same thing happens either way.

In case it's relevant, lilo is the one from debian's testing package:
22.1-6

-- 
Chris Riddoch       | epistemological
socket at peakpeak.com | humility