Bug#794403: flash-kernel: command "update-initramfs -uk <kver>" result in boot images in false version
Control: severity -1 wishlist
Control: tag -1 -patch
On Tue, 2015-08-04 at 02:00 +0900, Roger Shimizu wrote:
> Dear Ian,
>
> Thanks for your detailed comments!
>
> > I think your patch will break things by automatically installing
> > (via
> > the initramfs hook in the kernel postinst) whatever kernel was most
> > recently installed/upgraded, instead of the latest kernel by
> > version.
> > We do not want this: consider people who still have stable+testing
> > in
> > their sources.list and the stable+testing kernel's both installed,
> > they
> > are expecting to use the testing kernel and do not want to get a
> > surprise stable kernel installed whenever a DSA is issued against
> > the
> > Linux package in stable.
>
> I understand your concern.
> Yes, the patch will change the behavior as the case you mentioned.
> However I feel it's still strange by current mechanism, using your
> case as example, the "testing" kernel images will get rebuilt when DSA
> (to "stable") is issued.
> In this case I think only stuff related to stable kernel can be
> modified, and all testing kernel stuff should be left untouched.
If you have both stable and testing kernel installed then flash-kernel
will automatically trigger only for the newest kernel, otherwise the
triggers are inactive. By default the expected and by design behaviour
is that the latest installed kernel is always installed to the flash.
flash-kernel should not, by default, run when the stable kernel update
is installed and it is not expected that the stable kernel would be
copied to the flash (overwriting the testing kernel) when this happens.
> So I consider there's a "bug" here need to be fixed.
I think it is wishlist, the feature you are requesting here is "cause
flash-kernel to write something other than the latest kernel to flash".
The command "update-initramfs -uk <kver>" is expected to update the
initramfs in /boot but it is not expected necessarily to write that
update initramfs to flash. By default it is expected to only do so if
<kver> is the latest installed version.
>
> > An acceptable alternative to your patch might be to add support for
> > a
> > new option in /etc/default/flash-kernel e.g. LINUX_KERNEL_VERSION
> > which
> > names an explicit version which is the one which should should
> > always
> > be installed in flash (unless overridden on the command line). Care
> > would need to be taken that the kernel exists and to do the right
> > thing
> > if it is is removed.
>
> I like the idea to introduce an option for kernel version, but I also
> feel terrible considering that option need to be updated manually when
> kernel ABI gets changed.
If you want to choose to use something other than the latest installed
kernel then you will need to take manual action to do so, and will need
to take responsibility for tracking this when things change.
If you don't want this then uninstall the newer kernels.
> > I think a suitable algorithm for determining the version would be to
> > consider in order:
> >
> > 1. The version on the command line, if any. If one is given but
> > doesn't exist then error out.
> > 2. The version from /etc/default/flash
> > -kernel:$LINUX_KERNEL_VERSION, if it doesn't exist then fall
> > through to next option(*) with a big fat warning printed.
> > 3. The currently installed version with the greatest version
> > number.
>
> I feel comfortable with this order.
> And I think there need to be added another rule: only if the kernel
> version (deciding from the order list) matches the <kver> from
> update-initramfs command, the flash-kernel should not update boot
> images otherwise.
Yes, my use of "on the command line" in #1 was ambiguous. I meant that
case to cover the user typing "flash-kernel 3.4.5-kirkwood" on the
command line not the case here some other tool calls flash-kernel
giving a specific verison.
Refreshing my memory of the code, what I really meant with #1 was
"flash-kernel --force", since that is how a user manually asks flash-
kernel to install a specific kernel in a one-shot manner (i.e. only
until the next time a script or hook triggers an update).
Ian.
Reply to: