Bug#383600: behaviour of update-initramfs -u has changed, only updates latest kernel initrd
On Mon, Aug 28, 2006 at 12:59:53AM +0200, Michael Biebl wrote:
> severity 383600 serious
> Sven Luther wrote:
> > On Fri, Aug 18, 2006 at 07:03:52PM +0200, Michael Biebl wrote:
> >> Eduard Bloch wrote:
> >>> #include <hallo.h>
> >>> * Michael Biebl [Fri, Aug 18 2006, 01:07:34PM]:
> >>>> Eduard Bloch wrote:
> >>>>> #include <hallo.h>
> >>>>> * Michael Biebl [Fri, Aug 18 2006, 10:26:53AM]:
> >>>>>> I suggest to revert to the old behaviour and make "-u" update all
> >>>>>> installed kernels. Atm I have to specify each kernel separately vi -k to
> >>>>>> update them all.
> >>>>> Why should one update _all_ initramfs images when beeing interested in
> >>>>> only single one?
> >>>> Why should I be only interested in only a single one? If I install e.g.
> >>> Because usualy it gets executed when you install a kernel-image package?
> >> Just grep for update-initramfs in /var/lib/dpkg/info/*.postinst.
> >> I get uswsusp, cryptsetup, mdadm and udev on my machine.
> >> They all simply call update-initramfs -u.
> >> This means that security updates of these packages are not automatically
> >> applied to all installed kernels which is a major security issue imho.
> >> If you insist that update-initramfs -u only updates the latest kernel,
> >> you should file bug reports against all packages using update-initramfs -u.
> 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!)
> 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.
> 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
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 ?
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).