Dear Maintainer,

Hook script "initramfs-hook/flash-kernel" will be called when update-initramfs
is invoked. However flash-kernel only build the latest kernel version it find,
rather than the specific version passing from update-initramfs.

For example, after running "update-initramfs -uk <kver>", the <kver> is
successfully passed to "initramfs-hook/flash-kernel", and then "flash-kernel"
script, but "flash-kernel" script simply ignore that version, except adding
a "--force" flag, which is why this patch is here.

I also checked the log for initramfs-hook/flash-kernel, as commit 7bacb9 the
kernel version was actually not passed to "flash-kernel" script, but from
commit e05fc9, this has been changed, which I think it means the flash-kernel
script need to honor what kernel version update-initramfs is working on.

Thanks and looking forward to your comments.

Cheers,
Roger

initramfs for <kver>, it is not intended to mean "and boot <kver> next
time", that is not update-initramfs's job (on other platforms it does
not e.g. call grub-set-default or grub-reboot either).

flash-kernel normally always tries to keep the latest kernel installed.
It offers a command line override for this, but this is not expected to
be used by automatic callers. Really this capability is more for
debugging (by booting an older kernel once or twice) than anything
else. If you want to permanently boot <kver> then at the moment you
have to arrange that <kver> is the newest installed kernel.

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'm afraid not, when called from the initramfs-hook flash-kernel should
arrange for the update only if operating on the newest kernel.

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 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.

The fall through from option 2 to option 3 is important, otherwise a
kernel removal/upgrade/install (which invokes flash-kernel) may find
itself unable to complete if the desired kernel is missing and abort
the whole operation, which will be potentially tricky to recover from
since it will block further apt/dpkg operations until it is sorted out.
Installing the latest kernel if the preferred option is not available
seems better than failing in this case.

People who then want to boot an older kernel could set
LINUX_KERNEL_VERSION and call flash-kernel to make it take effect.

Ian.

Dear Ian,

Thanks for your detailed comments!

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.

So I consider there's a "bug" here need to be fixed.

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.
I see there're a few scripts under /etc/kernel/postinst.d/ which seems
to monitor the kernel ABI changing. (also noticed the existence of
flash-kernel script there...)

I'm not familiar with that part, so need some time to go over.
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.

I totally agree.
Thanks for your consideration in overall!
I'll think your points over again, and try to work out a solution.

Cheers,
Roger

Control: severity -1 wishlist
Control: tag -1 -patch

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.

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.

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.

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.