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

Re: Proposal: make kernel install easier



On 20 Aug 2003 16:04:50 -0400, Adam C Powell IV <hazelsct@debian.org> said: 

> On Wed, 2003-08-20 at 14:46, Manoj Srivastava wrote:
>     On 20 Aug 2003 10:51:54 -0400, Adam C Powell IV
>     <hazelsct@debian.org> said:

>> Greetings, Installing a new kernel package can be a bit of a pain,
>> especially for newbies, what with hand-editing lilo.conf or config

>     	Why on earth are you hand editing the lilo.conf file for every
>      kernel image? The postinst already manages two symlinks for you
>      that can be in the lilo.conf file.

>     	If you have to hand edit lilo.conf for every kernel image, you
>     	are doing something wrong.

> See my reply to Josh Lauricha: kernel-image packages corrupt the
> vmlinuz(.old) symlinks when removing a kernel, and switching between
> kernels with and without initrd.img is not supported.

	You can replace the symlink handling of kernel-image packages
 on the target machine, without modifying kerel-package. And yes, lilo
 conf files can be tricky with the default symlink handling --- but
 the example postinstall hook script demonstrates that all this canm
 be handled exernally to kernel-image packages. 

>     	For the clever, you can manage any number of symlinks
>      automatically for yourselves; the latest kernel-package gives
>      an example of creating a set of symlinks for 2.4 kerels,
>      another set for 2.5 kernels, and so on.

>> files for other bootloaders, from grub

>     	Another bad example. For grub you do not need to muck around
>      with symlinks at all, you have update-grub, and again, the
>      kernel-package package gives examples on how to use this
>      script.

> Then /usr/lib/bootloaders/grub would be very small and easy to
> write.  My proposed mechanism would add finer-grained control of
> boot options (e.g. "apm=on" for 2.2 kernels but not 2.4) and of menu
> entry names/labels, with little additional coding.

	The apm=on for 2.2 kernels can already be handled (see the
 sample postinst hook script provided for hints). I suppose
 dynamically creating labels is desirable, but all this can be a light
 weight /usr/sbin/update-lilo-conf  script. 

> Please forgive me, I had not known that a newer version of quik had
> just been uploaded which supports such features, and that's what I
> use to boot my one fully-unstable machine (i.e. not just a chroot).

	quik does not follow symlinks?

> Now that there are hook scripts, this makes some sense.  But if you
> think about it for a few seconds, the "bloat" and "creeping
> featurism" of the proposed bootloader scripts is no greater than
> that required for hook scripts -- in fact, that's what they are
> (inspired by e.g.  update-cluster).

	I have no idea what update-cluster is, so I doubt if they were
 inspired by that (I am an emacs user, hooks are old hat to us). In
 any case, kernel-package alreasy impolements hooks.

	The fact that you came in talking about patching
 kernel-package without even being aware of current capabilities is
 disheartening -- and leads one to suggest you look at what
 kernel-image postinst does before you create new solutions. 

>     	It has not only been brought up, solutions have been found and
>      have been implemented.

> Again forgive me, I had not known these solutions had been applied
> to aboot, quik, palo, etc.

	So do some research about what the postinst does already. If
 you want to create a third party set of scripts to handle updating
 various boot loaders, fine. But your use cases for such a change were
 ill chosen. 

> Thank you for the kind and courteous reply,

	Thank you for the courtesy of researching the problemset
 before proposing solutions.

	manoj
-- 
%DCL-MEM-BAD, bad memory VMS-F-PDGERS, pudding between the ears
Manoj Srivastava   <srivasta@debian.org>  <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C



Reply to: