[Bug 2017401] Re: Unexpected / unwanted unattended-upgrades behaviour after kernel upgrade when Livepatch enabled

[Johannes Burk]

Steve wrote:

> However, this is an uncommon configuration (if you are configuring
your system to automatically reboot on kernel upgrade, you are getting
very little value out of livepatch on top of that since in the common
case the kernel deb is made available to the system before the
corresponding livepatch) so most users are not expected to be using both
in combination.

While I agree to the statement that there might be very little value
from combining automatic reboot with livepatch. I disagree on "this is
an uncommon configuration" because if you configured unattended-upgrades
to automatic reboot before (or after) and you just fired 'pro attach'
that configuration is the (unintended) result! livepatch is enabled by
default and will break the automatic reboot configuration.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/2017401

Title:
  Unexpected / unwanted unattended-upgrades behaviour after kernel
  upgrade when Livepatch enabled

Status in unattended-upgrades package in Ubuntu:
  Confirmed
Status in unattended-upgrades source package in Focal:
  Confirmed
Status in unattended-upgrades source package in Jammy:
  Confirmed

Bug description:
  Following the resolution for bug #1747499, after a kernel upgrade when
  Livepatch is enabled, the current behaviour in unattended-upgrades
  (2.3ubuntu0.2 and later) is not to touch /var/run/reboot-required so
  as not to confuse users with two separate messages calling for a
  restart in motd. This functionality is implemented in the script at
  /etc/kernel/postinst.d/unattended-upgrades.

  While this works as intended in terms of suppressing an extra message
  in motd, it defeats the ability of unattended-upgrades to restart
  automatically with the new kernel, which is reliant on
  /var/run/reboot-required being present.

  This is unexpected / unwanted behaviour in scenarios where a)
  Livepatch is being used to provide fast-response kernel patching; and
  b) Unattended-Upgrade::Automatic-Reboot is set to true, to enable
  automatic reboots during a regular maintenance window. In this case,
  without administrative intervention, the system could never boot into
  the new kernel even though it would be expected to, leaving Livepatch
  to do all the heavy lifting indefinitely, and unnecessarily.

  I believe this counts as a regression caused by the resolution to bug
  #1747499. It also has the potential to be a security threat if
  Livepatch doesn't work comprehensively for a particular kernel flaw,
  and an administrator is reliant on expected behaviour according to
  unattended-upgrades settings.

  Potential options for a fix that come to mind:
  1. Revert to original behaviour in /etc/kernel/postinst.d/unattended-upgrades, and change the ***System restart required*** message to be less alarming or confusing when the cause is a kernel upgrade that's being patched by Livepatch.
  2. Add an extra configuration setting (eg Unattended-Upgrade::Automatic-Reboot-After-Livepatch) that triggers a reboot when it's 'recommended' by Livepatch, not reliant on the presence of /var/run/reboot-required.
  3. Add support in /etc/kernel/postinst.d/unattended-upgrades for an extra file somewhere. When present, /var/run/reboot-required is always touched, even if Livepatch is enabled.

  (This is my first time reporting a bug in this system, and I apologise
  if I haven't followed the usual descriptive format.)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/2017401/+subscriptions