Livepatch has fixed kernel vulnerabilities. Or not???

[Keith]

On 4/18/23 1:27 AM, Bo Berglund wrote:

[snipped]

>>
>> Remove cached snap files in /var/lib/snapd/cache
>> Not directory, just files.
> there are 7 files in there all with very long names like this:
> 3aca523f924d16583217c9b029f8c626972012f9c6fab26b4cb987ec64b50e273751f8a7be35328d5bd6404d4db0af2d
> 
> and sudo rm /var/lib/snapd/cache/* just shows an error message:
> rm: cannot remove '/var/lib/snapd/cache/*': No such file or directory

I think that is a glob expansion issue. Do "sudo -s" and then try to 
remove the files as root.

> 
> When I specify one of the files by adding the start of the name:
> sudo ls -la /var/lib/snapd/cache/3*
> ls: cannot access '/var/lib/snapd/cache/3*': No such file or directory
> 
> Are these strange files the ones you refer to as "cached snap files"?

Yes, these are cached snap squashfs archives. The purpose in removing 
them is to make sure that when re-installing a snap, snapd downloads the 
snap archive from the website rather than using a cached copy. Normally, 
if there has been an update to a particular snap, snapd will download 
the new version instead using the cached version. I just wanted to be 
sure we were dealing with a non-cached version.
> 
> Had top stop here since I could not follow your instructions for removing....
> But I looked at the  commands and found some I do not really understand:
> 
>> Manually install canonical-livepatch snap
>> $ sudo snap install canonical-livepatch
>>
>> Enable canonical-livepatch
>> $ sudo pro enable livepatch
>>
>> Check ~/snap/canonical-livepatch
>> Is there a symbolic link "current" pointing to the revision of the
>> canonical-livepatch snap (196 for the latest/stable)?
>> If not, make one.
>> Do the same for /root/snap/canonical-livepatch
> 
> Please explain these commands, I do not understand how to make it manually...
> What is "revision of the canonical-livepatch snap"?
> Is that a file somewhere and is it named "196"???
> Also what do you mean by "do the same"? >

The revision of a snap is that part of the version number that that 
snapd presents to the user to handle and distinguish between installed 
snaps of the same release. Among other things it distinguishes between 
which snap is enabled/disabled. The 202 revision update was installed on 
my system after my previous post. So now the livepatch config/cache 
directories in ~/snap and /root/snap have a symbolic link "current" 
pointing to 202 to indicate that that is the currently enabled revision 
of the snap.

# ls -l /root/snap/canonical-livepatch
total 12
drwxr-xr-x 2 root root 4096 Feb  3 16:07 196
drwxr-xr-x 2 root root 4096 Feb  3 16:07 202
drwxr-xr-x 2 root root 4096 Feb  3 16:07 common
lrwxrwxrwx 1 root root    3 Apr 14 09:47 current -> 202


$ snap list --all canonical-livepatch
Name                 Version  Rev  Tracking       Publisher   Notes
canonical-livepatch  10.5.3   196  latest/stable  canonical✓  disabled
canonical-livepatch  10.5.4   202  latest/stable  canonical✓  -

Note in the livepatch example there has been a increment of the minor 
version number so it's a new version of the snap, but that's not always 
the case. For example,

$ snap list --all qt5-core20
Name        Version  Rev  Tracking       Publisher   Notes
qt5-core20  20.04    14   latest/stable  keshavnrj✪  disabled
qt5-core20  20.04    15   latest/stable  keshavnrj✪  -

qt5-core20 is a snap of the QT5 stack needed by some QT based snaps. 
Same version but different revision. The latest revision, 15, is enabled.

I didn't think about this at the time, but since you're using 20.04, you 
may be using a livepatch snap from a different channel that what 22.04 
uses. "Snap list canonical-livepatch" will tell for sure. The Rev number 
is what should appear in the canonical-livepatch directories in ~/snap 
and /root/snap.

My hunch as to why canonical-livepatch thinks you need to upgrade the 
kernel and restart the system is that there is possibly some file that 
when present signals the livepatch service of the restart state and that 
after a completed kernel patch and reboot, this file should have been 
removed but for some reason wasn't. So there might be some stale file 
present somewhere. I don't know if this correct, it's just a guess. 
Clearing out the leftover canonical-livepatch directories in /root/snap 
and ~/snap after uninstalling the livepatch snap and then letting them 
get created again after re-installing livepatch hopefully would have 
gotten rid of the stale file if it had existed.

To keep this to one message, I'll respond to your 2nd post here:

> sudo ls -la /home/bosse/snap/canonical-livepatch
> ls: cannot access '/home/bosse/snap/canonical-livepatch': No such file or
> directory

Shouldn't be necessary to use sudo here if /home/bosse is your logged-in 
user's home directory.  Is there a canonical-livepatch directory in 
/root/snap? On my system, I went through all the steps I advised in my 
message and those directories were recreated in both locations. Perhaps 
running the command "canonical-livepatch status" both as the login user 
and root will cause them to be recreated.

I'm afraid I'm all out of ideas if you've re-installed the livepatch 
snap but are still getting that motd message about needing a restart 
even after you've already rebooted a number of times. I'd recommend 
filing a bug at the link Oliver provided in his last response to you. 
I'd also check https://forum.snapcraft.io and post an inquiry there. 
Someone may be able to walk you through a debug session of what's 
happening and/or provide more accurate information on how livepatch 
determines when a system needs a kernel update and restart.

-- 
Keith