[Bug 2017401] Re: Unexpected / unwanted unattended-upgrades behaviour after kernel upgrade when Livepatch enabled
Steve Langasek
2017401 at bugs.launchpad.net
Thu Aug 31 16:05:47 UTC 2023
There has been a discussion between the several engineering teams
involved regarding a path forward on this bug. It's acknowledged that
this is a regression which breaks the statement of user intent expressed
by setting the Unattended-Upgrade::Automatic-Reboot option. 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. And we have agreed that we should be getting richer
information from canonical-livepatch about the security bug coverage of
available livepatches vs kernel debs that will allow a more nuanced
decision about whether to tell the user a reboot is required. This work
is planned for the 24.04 development cycle and we believe will cover
this regression as well; so a targeted fix for this issue is not
currently a priority.
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to unattended-upgrades in Ubuntu.
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
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
More information about the foundations-bugs
mailing list