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

RFC: initramfs-tools postinst causes system inconsistency?



Current suituation - when initramfs for one semi-randomly selected 
linux-image package is updated, and others are not, and even administrator 
is not notified in any way, leads to system inconsistensy.

Which I believe is against debian quality standards.

I'm forwarding this to debian-devel for futher discussion.


> On Sun, 26 Nov 2006, Nikita V. Youshchenko wrote:
> > Looks line postinst script of initramfs-tools package just runs
> > 'update-initramfs -u'
>
> yes and it will stay like this.
>
> > This looks to update initramfs image for one of installed linux-image
> > packages, while keeping it as-is for all other packages. This could
> > lead to different sorts of inconsistency.
> >
> > E.g. on one of systems, I have linux-image-2.6.18-2-xen-k7 and
> > linux-image-2.6.18-2-k7 packages installed. Normally xen version is
> > running, but non-xen version is kept for the case if things will go
> > wrong.
>
> this is a known case where the sorting gets wrong,
> but power user, who have several kernels installed can
> take care of that.
>
> > So what is stated in the man page ('update-initramfs -u updates
> > the initramfs of the newest kernel') is not true. 2.6.18-2-xen-k7 *is*
> > newest, but it's initramfs image is not updated.
> > I think that '-u' whthout '-k' in it's current implementation does not
> > make sence at all, because aclually it updates initramfs of
> > semi-random kernel.
>
> just if you install several kernels of the same version,
> than it picks the image on alphabetical order.
>
> > I thinks that tho things should be done
> > - postinst should be changed either to call 'update-initramfs -u -k
> > all', or to ask somehow what images should be updated,
> > - update-initramfs should be modified either to require -k, or to use
> >   better logic to find out what kernel image is the 'latest'.
>
> the sorting algorythm could be refined,
> but needs to take into account that the current running
> is not the latest..
> postetch material anyway.

Attachment: pgpgCePR22Jtu.pgp
Description: PGP signature


Reply to: