Re: initrd-tools and booting root on lvm with new kernel

[Sven Luther <sven.luther@wanadoo.fr>]

On Thu, Oct 06, 2005 at 08:24:49PM +0200, Jonas Smedegaard wrote:
> > >         I guess we could add a version specific check into the
> > >  postinst to default to using yaird or mkinitramfs , if installed,
> > > in preference to mkinitrd, though I am usually hesitant to add in
> > >  version dependencies into kernel-package in general, I could be
> > >  persuaded that an exception is justified in this case.
> 
> Alternatively kernel-package could fallback to other (installed) tools
> if the default one fails, instead of hardcoding version numbers. Still
> the priority of tools looked for and attempted would make sense to
> adapt to the kernel version, but would then be less intrusivese.
> 
> mkinitrd could then have hardcoded that 2.6.13 and newer Will Fail(tm).

That is a neat idea, have all three initrd tools know what version they
support and not, and do the check. Or even have a :

  --supported-version <version>

option which could be queried to check if this version is ok, then we need
only to be able to set the ordering of the different tools like :

mkimage_order = mkinitrd.yaird mkinitramfs mkinitrd

for example, and kernel-package would query those executable (if present) to
know if they support the kernel version which is tried to be installed, and
then try the one with higher priority. 

> yaird by design is quite knowledgable at build time about the chances of
> an image being broken (because it probes hardware at build time, where
> mkinitramfs probes at runtime) and will fail if something is wrong.

How does it react when running a 2.2 or 2.4 kernel and upgrading to a 2.6
kernel though ?

> Don't know avbout mkinitramfs but at least situations like "needs 2.6.12
> or newer" could be hardcoded if it would otherwise silently build a
> broken image.

Indeed.

> > there are archs which should prefer mkinitrd at current state of
> > affairs.
> > 
> > also it would be _very_ cool to do the switch after a major upload.
> > just the switch to the newer tools and nothing else.
> > ubuntu has been bitten by this transition.
> > the user won't recognise that the oops is not the kernel fault.
> > the best plan would be to do it after an 2.6.13-1 upload:
> > an 2.6.13-2 with only this change.
> 
> If I understand you correctly then that only helps users frewuently
> bringing their system up-to-date, and not someone doing a dist-upgrade
> a year from now...

Well, it helps the developers in helping make atomic changes to the package,
so we know it breaks because of 2.6.13 weirdness or because of the initrd
creation changes :)

Friendly,

Sven Luther