Canonical Livepatch has experienced an internal error, on start up

kn flag

I am running Ubuntu 20.04 with kernel 5.11.0-40 and I am now experiencing a persistent error with Livepatch when starting my machine (the shield icon shows red). I have had this temporarily before, but it usually clears after a restart or rarely a software update.

The Software Updater window shows:

Canonical Livepatch has experienced an internal error. Please refer to for further information.

canonical-livepatch status shows:

last check: 4 minutes ago
kernel: 5.11.0-40.44~20.04.2-generic
server check-in: failed: livepatch check failed: POST request to " machine id /updates" failed
patch state: ✓ no livepatches needed for this kernel yet
tier: updates (Free usage; This machine beta tests new patches.)
machine id: removed for this post

The wiki and other questions have provided no help. All authoritative suggestions are greatly appreciated.


The error is on my desktop machine. I also have a laptop, which runs the same Ubuntu and kernel version, and Livepatch works fine there (nice green shield icon).

Note the following output from a terminal on the laptop:

$ uname -a
Linux nick-X555LAB 5.11.0-40-generic #44~20.04.2-Ubuntu SMP Tue Oct 26 18:07:44 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
$ sudo canonical-livepatch refresh
sudo: canonical-livepatch: command not found
$ canonical-livepatch refresh
2021/11/18 11:43:26 error executing refresh: please re-run using sudo

So pick the bones out of that - I can't!


I signed up for free Ubuntu Advantage and ran ua attach, as suggested somewhere. The o/p was:

$ sudo ua attach SOME TOKEN OR MY MACHINE ID
Enabling default service esm-infra
Updating package lists
UA Infra: ESM enabled
Updating 'livepatch' on changed directives.
Disabling Livepatch prior to re-attach with new token
Canonical livepatch enabled.
This machine is now attached to 'MY EMAIL ADDRESS'

This really should not have been a necessary procedure to follow without any warning from Canonical. I'm not impressed.

I forgot to add: Livepatch now shows a green shield icon.


After a reboot it continued to work. It was solved, I thought, but NO. It is back showing the red shield and

canonical-livepatch status last check: 24 seconds ago kernel: 5.11.0-40.44~20.04.2-generic server check-in: failed: livepatch check failed: POST request to "" failed


It appears that my error has vanished now (0921 GMT, November 21st), without intervention from me. - and now it has come back again by 11.59

muru avatar
us flag
Please don't add "solved" to the question. Either accept an existing answer if it solved your problem, or post an answer with the solution.
cn flag
sudo canonical-livepatch refresh

does that fix it for the current session?

If so and it does not work anymore after a reboot you might want to add this to a cron with an @reboot. The message comes from their server so it might be an issue on that end and not with your machine.

You need to file a bug report if your kernel is supported by livepatch. This

no livepatches needed for this kernel yet

would suggest it is not.

You are not the only one with issues in the past few hours

kn flag
No, that command just says that no updates are needed. Please see my update which details the difference between my laptop and my desktop machines, both running same Ubuntu version AND kernel !
cn flag
@NickT make it an answer! I'll remove mine :-)
kn flag
I had added that the problem was solved, as is common practice in many forums, including launchpad I think. A self appointed guardian of this forum, edited that update out. I'm done with trying to be helpful and tried to delete this question, but no luck with that. I hope the downvoters and editors are happy.
kn flag
It's a good job that I didn't post it as an answer - see my Update 3. It's broken again. It should work 'out of the box' and Canonical need to fix it. I'll do no more scratching around on the command line.

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.