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

Bug#505609: new lilo package maintainer? (was lilo removal in squeeze or please test grub2)



On Tue, 2010-06-08 at 09:43 -0400, Stephen Powell wrote:
> On Tue, 08 Jun 2010 07:39:58 -0400 (EDT), Vincent Danjean wrote:
> > On 07/06/2010 17:37, Stephen Powell wrote:
> >> But for a kernel install or reconfigure, it is the responsibility of the
> >> kernel maintainer scripts to invoke the bootloader.  See also, for example,
> >> linux-image-2.6.26-2-s390.postinst, where zipl is assigned as the bootloader
> >> on line 38.  This really is an "open and shut case", if only I can the kernel
> >> people to actually look at it!  Please look at it!
> > 
> > If I recall correctly, kernel maintainers have introduced
> > /etc/kernel/post{inst,rm}.d/ in order to avoid to hardcode each possible
> > bootloader in their script.
> > Can't lilo provide a script here ?
> 
>    do_bootloader = yes
> 
> in /etc/kernel-img.conf means "run the historic boot loader for this platform".
> For the i386 platform (and amd64) the historic boot loader is lilo.  For
> the s390 platform, that boot loader is zipl.  The kernel maintainer scripts
> for the s390 platform still specify zipl as the boot loader
> 
>    my $loader            = "zipl"; # lilo, silo, quik, palo, vmelilo, nettrom, arcboot, or delo
> 
> so that
> 
>    do_bootloader = yes
> 
> in /etc/kernel-img.conf will work.  The kernel maintainer scripts for i386 and amd64
> for Lenny and beyond specify a null string.  That is inconsistent.  It should specify
> 
>    my $loader            = "lilo"; # lilo, silo, quik, palo, vmelilo, nettrom, arcboot, or delo
> 
> for consistency between platforms.
[...]

This code and the file /etc/kernel-img.conf are vestiges of
kernel-package which are gradually being removed from the official
kernel packages.  Therefore I don't think we should reinstate this idea
of the default loader but we should change the code so that it doesn't
silently fail if do_loader is set and loader is not.

All packages that need to react to kernel installation or removal should
install appropriate hook scripts in the directories under /etc/kernel
instead of relying on specific support in the kernel maintainer scripts.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.

Attachment: signature.asc
Description: This is a digitally signed message part


Reply to: