Bug#383600: behaviour of update-initramfs -u has changed, only updates latest kernel initrd
first of all this not serious,
update-initramfs -u doesn't update _all_ initramfs
and it never did. so this bug report is bogus.
On Mon, Aug 28, 2006 at 10:07:42AM +0200, Sven Luther wrote:
> On Mon, Aug 28, 2006 at 12:59:53AM +0200, Michael Biebl wrote:
> >
> > I'm raising the severity to serious, because as already outlined,
> > packages that call update-initramfs -u in postinst (such as udev) won't
> > update all installed initrds anymore. These means that security fixes of
> > these packages aren't applied to all installed kernels anymore keeping a
> > system potentially vulnerable (the latest kernel is not necessarily the
> > default boot kernel!)
you are expected to run the latest and greatest linux-image,
we don't support old uname!
> > I'm filing these bug against initramfs-tools itself, because you missed
> > to inform other maintainers in advance, giving them time to change their
> > postinst scripts, that you intend to change the default behaviour of
> > update-initramfs -u.
no, again it is an intended behaviour.
and the recommended action.
> > If you want to keep the current behaviour, you should file bug reports
> > against all affected packages and add them as blocking bugs against this
> > one.
>
> Maks, Manoj, rest of the kernel team, ...
>
> Would not the right solution to this be to have a system wide configuration
> option managed by debconf or something, but eventually also in the
> /etc/kernel-img.conf, which would allow to set the behaviour of this ?
i'd like to have a better /etc/kernel-img.conf, but Manoj doesn't
want to update that config file at all so you have to stop installation
to add obvious things there like do_initrd=yes.
even if you add this you get prompted anyway on kernel upgrades..
nor does Manoj want to add the do_bootloader response to aboves config
file.
> It affects other packages too, like mkvmlinuz and maybe bootloader installer,
> which are called after the ramdisk generators, and it is clear from this
> thread that diverse people expect diverse behaviour on this.
>
> It could even be done to handle the prefered choice kernel in a debconf dialog
> also this way, in case multiple kernels are present, with a medium priority
> question when a new choice is available or the default choice is removed, and
> a low priority question in the other cases. At high priority it would default
> to the last installed kernel, as is done right now. (but which has a flip-flop
> undeterministic behaviour in case 2.6.17 and 2.6.16 are both installed and
> upgraded since both are present in the archive right now).
first of all i'm against useless propagation of debconf dialog,
when you can't do the obvious.
the obvious is to be conservative and not touch all initrd,
due to potential boot trouble, but still propagate the fixes
to the newest initramfs.
regards
--
maks
Reply to: