[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: splitting up kernel-image into two pieces

On Jul 19, Manoj Srivastava wrote:
> >>"Nick" == Nick Cabatoff <ncc@cs.mcgill.ca> writes:
>  Nick> I don't want to specify the kernel in my lilo because I want to be
>  Nick> able to use the same lilo.conf for all, or at least most, of our ~100
>  Nick> debian machines.  I don't want to have to change lilo.conf just
>  Nick> because I change the kernel.
> 	I guess I don't understand. Here is the lilo.conf I use on
>  around a dozen machines I have access to. It never changes; all I
>  ever do is move a few symlinks around and rerun lilo.
> 	Indeed, not having to change the the lilo.conf was one of the
>  major motivations for the current symlink handling. 
>  Now, if you do not want the symlinks handled automatically, modify
>  your lilo.conf to never look at /vmlinuz* (create differently named
>  links for yourself), and set do_symlinks to no.
>  	How does this fail to address your needs? (Surely you do not
>  need a complicated script to change a few symlinks around when you
>  are making all the decisions?)

I thought I'd explained this in previous mails, but perhaps some of
them weren't to the list.

I want the *option* of a package handling the symlinks.  I want to be
able to install various kernel images, in any order, without having
my lilo symlink targets affected; this much I can apparently achieve
in the potato version of kernel-package by setting do_symlinks to no.  

However, I also want to be able to specify which kernel on a given
machine is the one that the vmlinuz symlink should point to.  I liked
the idea of representing the selection as a package because then I
could use the current kernel-image postinst/postrm more or less as is,
and because I thought it was nice to be able to see what kernel is in
use on the machine by looking at a package listing.

(Part of my motivation for doing it this way is that I'm managing
these machines by means of automated calls to apt-get, such that any
configuration is done by homegrown packages.)

Anyway, I've got it working to my satisfaction, so this is moot.  If
noone else has any interest in this approach, so be it.

Reply to: