On 31 Jul 1997, Manoj Srivastava wrote:
> What exactly does use /vmlinuz? The only thing I know is lilo;
> if you are booting up, the /vmlinuz has already served its purpose.
I don't know what, if anything, uses it. Fsstnd-1.2 doesn't require
/vmlinuz or /System.map.
As to mentioning a symlink named /vmlinuz in lilo.conf, IMHO it's not
a good idea to have symlink names for images there, but that's an
individual user decision. I say that because lilo doesn't understand
symlinks at boot time, it resolves them when lilo(8) is run. (or at
least that used to be so and, as far as I understand, it's still so)
If lilo.conf has the following stanza:
root=/dev/hda2
image=/vmlinuz
label=Linux
read-only
and /vmlinuz-->/boot/vmlinuz-2.0.27, and lilo is run, then subsequently
choosing "Linux" at the lilo boot prompt would boot /boot/vmlinuz-2.0.27.
If /vmlinuz is then changed to /vmlinuz-->/boot/vmlinuz-2.0.30,
but lilo is (for whatever reason) _not_ re-run, then choosing "Linux"
at the lilo boot prompt will _still_ boot /boot/vmlinuz-2.0.27, _not_
/boot/vmlinuz-2.0.30. Looking in /etc/lilo.conf, though, would
show image=/vmlinuz, and looking at /vmlinuz would show
/vmlinuz-->/boot/vmlinuz-2.0.30, but `uname -r` would show 2.0.27.
> As to System.map, ps already looks at these files:
[...]
> ****===> /boot/System.map-`uname -r`
>
> I see it as a defect in klogd that it does not do the same. (I
> think I'll file a feature request). If it did, there would be no
> problems with selection of kernels in lilo.
>
> Can you point out a solution to this *not* using
> kernel-package? or was this a feature request?
Guy Maor <maor@ece.utexas.edu> responded, regarding klogd:
> There's no need. You can specify which System.map to use, and the
> comments in /etc/init.d/sysklogd already tell you how:
>
> # Use KLOGD="-k /boot/System.map-$(uname -r)" to specify System.map
> #
Neither of these, however, seem to address an expressed need from
kernel hackers to have several alternative flavors of a single kernel
version around.
Perhaps the proper way to address this need would be for the kernel
hackers to modify the SUBLEVEL definition in /usr/src/kernel/linux/Makefile
to read e.g., "SUBLEVEL = 30-speed_hack" (or some such) before building
the kernel. That should get the kernel installed as
/boot/vmlinuz-2.0.30-speed_hack, and get `uname -r` to say
"2.0.30-speed_hack", and should allow differentiation between alternative
2.0.30 kernels. (I haven't tried this because I'm currently unable
to build kernels, but it looks to me like that's the way it would work).
--
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 .