Re: boot-time kernel selection and /System.map mismatch
"Karl M. Hegbloom" <karlheg+debdev@inetarena.com> said:
> I've found that even with the correct System.map file, `lsof' will
> not work once a module has been loaded.
Perhaps so. `lsof' has never worked for me. Still, that would be a
problem peculiar to `lsof'. This apparent problem nonwithstanding,
should debian attempt at boot time to symlink either or both of
/System.map and /vmlinuz to files corresponding to the actual booted
kernel?
Martin Buck <Martin-2.Buck@student.uni-ulm.de> points out:
> You can use $BOOT_IMAGE (set by LILO) to select the right System.map.
Yup. That would work for LILO users, providing they followed
rules for choosing image labels which were compatible with
our boot-time symlink resolution processing. That would probably
be to use the basenames of the /boot/System.map-* and /boot/vmlinuz-*
files as the lilo.conf image label. (e.g., vmlinuz-2.0.27-scsi,
vmlinuz-2.0.27-nonscsi, vmlinuz-2.0.27-hacked, etc.). There's
probably a limit on the number of chars in the lilo image name.
However, as Erik Andersen <andersen@inconnect.com> points out:
> [...] Not just Lilo, but loadlin, chos, GRUB, etc. [...]
I see that `cat /proc/version' produces something like:
Linux version 2.0.27 (root@S001) (gcc version 2.7.2.1) #3 Mon Feb 24 16:18:43 PST 1997
This is the linux_banner string from /usr/src/linuxi/init/version.h.
If we named the files in /boot with name-version-timestamp
(e.g., vmlinuz-2.0.27-16:18:43), we would be able to use
this to do the symlinking, provided (1) the /proc filesystem
is available, and (2) the format and location of this linux_banner
remains stable.
(--aside
The '#3" in the linux_banner string is the build count from the
/usr/src/linux/.ver file in the source code installation.
It would be less ugly to use that instead of the timestamp,
but not reliablei, as builds from different installations of the
same version of sources would produce duplicate build counts.
)
That file naming is ugly, and is not particularly convenient for
the kernel hacker to use in tagging e.g., the scsi vs. non-scsi
versions of a kernel, but the scheme seems workable. This could
even be done in the absence of the /proc filesystem by grubbing
through /dev/kmem to find the linux_banner string.
Is it worth the trouble, though? Is there a better approach?
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: