Re: Processed: Re: Bug#114150: Use alternatives for bootloaders.
G'day all,
please excuse the long quoting, but it helps explain the background.
Quoting Manoj Srivastava <srivasta@debian.org>:
> Hi,
>
> Herbert> This is a kernel-package issue.
>
> I beg to differ. kernel-package can't just go and unilaterally
> call a non-existent file, /usr/sbin/update-bootloader, thereby
> breaking all current systems. Firthermore, one does not know what
> options to give that missing file.
>
> Donovan> The Debian alternatives system should be used to select
> Donovan> bootloaders. This way the kernel packages can simply call
> Donovan> /usr/sbin/update-bootloader in their post inst script,
> Donovan> rather than attempt to detect/fix/update which ever
> Donovan> bootloader i in use. Additional bootloaders can also be
> Donovan> added without special support adde to the kernel packages.
>
> Donovan> I have submitted this against kernel because it affects the
> Donovan> kernel and all bootloaders, particularly lilo and grub. I
> Donovan> could file this as seperate bugs against each bootloader and
> Donovan> kernel, but they all need to be fixed together.
>
> Donovan> Note that Progeny already does this and their scripts could
> Donovan> be just adopted, though they need small fixes to support the
> Donovan> 2.4 cramfs initrd images Debian uses (currently they search
> Donovan> only for .gz initrd images). Grub is already working on a
> Donovan> update-grub script, though from the bugs listed it looks
> Donovan> like it is less developed than the Progeny script, and there
> Donovan> doesn't seem to be any moves towards using alternatives to
> Donovan> select update-grub as update-bootloader.
>
> Donovan> I have looked at this fairly intensively, and can put
> Donovan> together patches or provide advice/assistance if people
> Donovan> really want.
>
> Could you please put together a proposal, including transition
> paths to upgrading to such s system? We would need not to break
[...]
I asked for that, didn't I :-)
How fancy does a proposal need to be? Here's my first cut, based exactly on
what Progeny uses;
Final objective
---------------
Booloaders are smart enough to update themselves using a "/usr/sbin/update-
(lilo|grub|floppy|whatever)" script that takes no parameters. It is the
responsibility of this script to find installed kernels and initrd images,
prompting the user if necisary using debconf, to update the bootloader.
The Debian alternatives system is used to create a link "/usr/sbin/update-
bootloader" to the apropriate "/usr/sbin/update-(grub|...etc)". The kernel
package post-inst scripts just call "/usr/sbin/update-bootloader" to update the
prefered bootloader.
All bootloaders should provide "bootloader", and kernel packages should depend
on or at least recomend "bootloader".
Transition plan
---------------
Currently the kernel post-inst scripts perform a variety of backflips to try
and identify what bootloader is in use, and how to update it. The transition to
this plan would go as follows;
1) update kernel package post-inst scripts to look for and
use "/usr/sbin/update-bootloader" as the prefered update method. The existing
back-flips are left in as a fallback if "/usr/sbin/update-bootloader" does not
exist and cannot be executed.
2) add "/usr/sbin/update-(grub|lilo|floppy|whatever)" scripts that perform as
described above to the bootloader packages, and make them use the alternatives
system to set the link "/usr/sbin/update-bootloader"
3) After all kernel images and bootloaders have been updated and all vestiges
of the old bootloaders and kernels have vanished, the backflip fallbacks can be
removed from the kernel package post-inst scripts.
Note that 1) and 2) can be done in any order, but 3) cannot happen till both 1)
and 2) have been completed.
Possible Variations
-------------------
These are not used by Progeny, but could be useful enhancements.
1) have the kernel post-inst scripts pass the paths of the kernel and initrd
image to the /usr/sbin/update-bootloader script. These scripts can then use or
ignore these parameters as they see fit.
> One should put the appropriate bootloader@package.debian.org
> addresses in the CC for that proposal, and perhaps even
> debian-policy@lists.debian.org.
[...]
done.
--
ABO: finger abo@minkirri.apana.org.au for more information.
Reply to: