ksymoops packaged ? System.map issues ...
I recently had a OOPS caused by my cdrom's module (in 2.0.33 ;).
After asking for help on the kernel list, I was pointed out to the
Right Way to handle this case. It involved:
1) compiling ksymoops from the kernel source tree.
2) building a valid ksym-table and reproduce the oops to feed its
output + the generated ksym-table to ksymoops.
This was not much of a problem to me, but could prevent some debian
users to help tracking such problems, due to the amount of work needed
with a standard distribution. The work needed is:
* installing the kernel sources to get ksymoops.cc
* installing the c++ compiling suite (ie. the compiler + the libs)
These packages should not be needed on a non-developper machine, and
they may be too large for the sysadmin to even consider installing -
this advocates for a compiled ksymoops to be shipped in one of the
base packages, so that noone has to search where it is.
* building the kernel symbol table for the interesting state (needs a
"cat /proc/ksyms | cut -f1 | sort", but should be done with a simple
script)
The script is trivial to write. However, feeding ksymoops the right
symbol table (ie. the one matching the oops' output) may not be
easy, especially if the oops is not easily reproduced (I was lucky
in this respect, however)
I was pointed out by Erik Andersen <andersee@debian.org> that a
wrapper around modprobe, that would regenerate the symbol table,
would make the table in sync with the kernel's state, with respect
to modules. However, doing it simply by replacing the previous
table will cause problems in the cases (such as the one I
experienced) in which the oops occurs on module-unloading - then the
interesting table is lost. It would be useful to use rotatelogs on
the saved System.map.
However, this auto-generated map should probably replace the one
installed by one of the kernel-image packages, as info about loaded
modules will surely be useful to all apps accessing the table.
How are the /boot/System.map-* files used, when they do not relate to
the running kernel ? Can we simply get rid of them ? Are there some
systems NOT running the /proc filesystem, that would still require
this static map ? etc. ... ?
I guess this stuff would belong to modutils. Any comments ?
Regards,
--
Yann Dirson <ydirson@a2points.com> | Stop making M$-Bill richer & richer,
alt-email: <dirson@univ-mlv.fr> | support Debian GNU/Linux:
debian-email: <dirson@debian.org> | more powerful, more stable !
http://www.a2points.com/homepage/3475232 | Check <http://www.debian.org/>
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: