We have tried the extra kernel postinst script and it doesn't seem to function appropriately.
The core issue for us is that our organization monitors our servers using Qualys, and Qualys reads the kernel version on disk. Qualys isn't intelligent enough to know that Livepatch has patched the running kernel. So Qualys ends up flagging all of our servers as having critical vulnerabilities (again, because it only checks the kernel version on disk), even though technically the vulnerability has been patched in the running kernel. It is very frustrating to have to try and explain to our central security team that the Qualys results are a false positive every time this happens and we are contacted about it. We are an Ubuntu Pro customer and we did open a ticket about this in January 2025, but no ETA is available regarding this bug, sadly. We hope that Canonical starts working on this situation soon. We would rather not disable Livepatch, but given comments above, it seems like the corporate view at Canonical is that we should disable it because (according to them) we are not getting any value from it. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, 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 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : [email protected] Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
