Missing explicit indication whether running kernel is supported by Livepatch
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Canonical Livepatch Client |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
Either I'm missing an implicit meaning of one of the lines of the verbose status output or I'm misreading the help contents, but AFAIK, the following output of "canonical-
last check: 15 minutes ago
kernel: 5.15.0-
server check-in: succeeded
patch state: ✓ no livepatches needed for this kernel yet
tier: updates (Free usage; This machine beta tests new patches.)
machine id: <hidden>
client version: 10.2.3
architecture: x86_64
cpu model: Intel(R) Xeon(R) CPU E5-2660 v3 @ 2.60GHz
boot time: 3 days ago
... does not indicate whether the running kernel--in this case, installed using "apt-get -t focal-proposed install ..."--is supported or not. In case it's *not* covered by the Livepatch service, would/should the patch state indicate that? Having this information would save me/us a lot of (internal) discussions.
information type: | Proprietary → Public |
Hi,
Apologies for the delay on this report. You are correct that the output of `canonical- livepatch status` did not indicate the support status of the running kernel. This has been partially addressed near the end of last year with the release of v10.3.0. Since this release if the running kernel is not supported the status of `patch state` will change to indicate the lack of livepatch support for this kernel (the location of this messaging is planned to be adjusted slightly in the future).
For a clearer view run `canonical- livepatch status --format json` to return a machine-readable response which, again since v10.3.0, should contain a field "Status[ 0].Supported" that will indicate the kernel's supported status. Documentation in this regard will also be improving soon.