Snaps stopped working after 2020-12-30 update

I use two snaps, GoLand and GitKraken, and at least GoLand worked fine this morning. Then I updated Manjaro a few hours ago, and now I get the following message when I try to start GoLand/GitKraken from the terminal:

cannot query current apparmor profile: Invalid argument

Does anyone know how to fix this, do I need to reinstall them?

4 Likes

The following packages got updated:

:: Different overlay package(s) in repository extra x86_64

-------------------------------------------------------------------------------
                             PACKAGE           2020-12-03           2020-12-30
-------------------------------------------------------------------------------
                            apparmor              3.0.0-2              3.0.1-1
                   apparmor-profiles              3.0.0-2              3.0.1-1
                               snapd               2.48-1             2.48.2-1

Can you try running snap run --strace=--raw superproductivity and post the log to a pastebin? (the log may be too long for posting in here). You need to pacman -S strace first

It might have to do with snapd update or both. I’ll check if snapd was built before apparmor 2.x.x -> 3.x.x switch.

I got (when running the snap run... command):

error: cannot find current revision for snap superproductivity: readlink /var/lib/snapd/snap/superproductivity/current: no such file or directory

I got the same problem. All my snap applications throw this error:

cannot query current apparmor profile: Invalid argument

I also tried to run snap run... with the result:

error: cannot find current revision for snap superproductivity: readlink /var/lib/snapd/snap/superproductivity/current: no such file or directory

A sorry, seems superproductivity is an application. See also here: AUR (en) - snapd

What is the output of: cat /proc/self/attr/current

Call your app like this and replace <app> with your snap application: snap run --strace=--raw <app>

For me : unconfined

For GoLand, I got the following result:

execve("/usr/lib/snapd/snap-confine", ["/usr/lib/snapd/snap-confine", "--classic", "snap.goland.goland", "/usr/lib/snapd/snap-exec", "goland"], 0x7ffc57b737a8 /* 71 vars */) = 0
access("/etc/suid-debug", F_OK)         = -1 ENOENT (No such file or directory)
brk(NULL)                               = 0x561df6eb6000
arch_prctl(0x3001 /* ARCH_??? */, 0x7fff799b0630) = -1 EINVAL (Invalid argument)
fcntl(0, F_GETFD)                       = 0
fcntl(1, F_GETFD)                       = 0
fcntl(2, F_GETFD)                       = 0
access("/etc/suid-debug", F_OK)         = -1 ENOENT (No such file or directory)
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=206179, ...}) = 0
mmap(NULL, 206179, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fb85ee67000
close(3)                                = 0
openat(AT_FDCWD, "/usr/lib/libudev.so.1", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0@@\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=157792, ...}) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fb85ee65000
mmap(NULL, 162080, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fb85ee3d000
mprotect(0x7fb85ee41000, 139264, PROT_NONE) = 0
mmap(0x7fb85ee41000, 98304, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x4000) = 0x7fb85ee41000
mmap(0x7fb85ee59000, 36864, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1c000) = 0x7fb85ee59000
mmap(0x7fb85ee63000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x25000) = 0x7fb85ee63000
close(3)                                = 0
openat(AT_FDCWD, "/usr/lib/libcap.so.2", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0  \0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=34528, ...}) = 0
mmap(NULL, 36920, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fb85ee33000
mmap(0x7fb85ee35000, 16384, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2000) = 0x7fb85ee35000
mmap(0x7fb85ee39000, 8192, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x6000) = 0x7fb85ee39000
mmap(0x7fb85ee3b000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x7000) = 0x7fb85ee3b000
close(3)                                = 0
openat(AT_FDCWD, "/usr/lib/libapparmor.so.1", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0 @\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=84456, ...}) = 0
mmap(NULL, 86920, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fb85ee1d000
mmap(0x7fb85ee21000, 36864, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x4000) = 0x7fb85ee21000
mmap(0x7fb85ee2a000, 28672, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xd000) = 0x7fb85ee2a000
mmap(0x7fb85ee31000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x13000) = 0x7fb85ee31000
close(3)                                = 0
openat(AT_FDCWD, "/usr/lib/libpthread.so.0", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0000\201\0\0\0\0\0\0"..., 832) = 832
pread64(3, "\4\0\0\0\24\0\0\0\3\0\0\0GNU\0\307Y\373z\3054\277z\21\35\225\341\273\304<\223"..., 68, 824) = 68
fstat(3, {st_mode=S_IFREG|0755, st_size=158744, ...}) = 0
mmap(NULL, 135600, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fb85edfb000
mmap(0x7fb85ee02000, 65536, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x7000) = 0x7fb85ee02000
mmap(0x7fb85ee12000, 20480, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x17000) = 0x7fb85ee12000
mmap(0x7fb85ee17000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1b000) = 0x7fb85ee17000
mmap(0x7fb85ee19000, 12720, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fb85ee19000
close(3)                                = 0
openat(AT_FDCWD, "/usr/lib/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220\202\2\0\0\0\0\0"..., 832) = 832
pread64(3, "\6\0\0\0\4\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0"..., 784, 64) = 784
pread64(3, "\4\0\0\0\20\0\0\0\5\0\0\0GNU\0\2\0\0\300\4\0\0\0\3\0\0\0\0\0\0\0", 32, 848) = 32
pread64(3, "\4\0\0\0\24\0\0\0\3\0\0\0GNU\0\207\360\21\247\344\314?\306\nT\320\323\335i\16t"..., 68, 880) = 68
fstat(3, {st_mode=S_IFREG|0755, st_size=2159552, ...}) = 0
pread64(3, "\6\0\0\0\4\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0"..., 784, 64) = 784
mmap(NULL, 1868448, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fb85ec32000
mmap(0x7fb85ec58000, 1363968, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x26000) = 0x7fb85ec58000
mmap(0x7fb85eda5000, 311296, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x173000) = 0x7fb85eda5000
mmap(0x7fb85edf1000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1be000) = 0x7fb85edf1000
mmap(0x7fb85edf7000, 12960, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fb85edf7000
close(3)                                = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fb85ec30000
arch_prctl(ARCH_SET_FS, 0x7fb85ec313c0) = 0
mprotect(0x7fb85edf1000, 12288, PROT_READ) = 0
mprotect(0x7fb85ee17000, 4096, PROT_READ) = 0
mprotect(0x7fb85ee31000, 4096, PROT_READ) = 0
mprotect(0x7fb85ee3b000, 4096, PROT_READ) = 0
mprotect(0x7fb85ee63000, 4096, PROT_READ) = 0
mprotect(0x561df6cdf000, 4096, PROT_READ) = 0
mprotect(0x7fb85eec6000, 4096, PROT_READ) = 0
munmap(0x7fb85ee67000, 206179)          = 0
set_tid_address(0x7fb85ec31690)         = 8478
set_robust_list(0x7fb85ec316a0, 24)     = 0
rt_sigaction(SIGRTMIN, {sa_handler=0x7fb85ee02b90, sa_mask=[], sa_flags=SA_RESTORER|SA_SIGINFO, sa_restorer=0x7fb85ee0f0f0}, NULL, 8) = 0
rt_sigaction(SIGRT_1, {sa_handler=0x7fb85ee02c30, sa_mask=[], sa_flags=SA_RESTORER|SA_RESTART|SA_SIGINFO, sa_restorer=0x7fb85ee0f0f0}, NULL, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0
prlimit64(0, RLIMIT_STACK, NULL, {rlim_cur=8192*1024, rlim_max=RLIM64_INFINITY}) = 0
prctl(PR_CAPBSET_READ, CAP_MAC_OVERRIDE) = 1
prctl(PR_CAPBSET_READ, 0x30 /* CAP_??? */) = -1 EINVAL (Invalid argument)
prctl(PR_CAPBSET_READ, CAP_CHECKPOINT_RESTORE) = -1 EINVAL (Invalid argument)
prctl(PR_CAPBSET_READ, CAP_BLOCK_SUSPEND) = 1
prctl(PR_CAPBSET_READ, CAP_PERFMON)     = -1 EINVAL (Invalid argument)
prctl(PR_CAPBSET_READ, CAP_AUDIT_READ)  = 1
brk(NULL)                               = 0x561df6eb6000
brk(0x561df6ed7000)                     = 0x561df6ed7000
umask(000)                              = 022
openat(AT_FDCWD, ".", O_RDONLY|O_NOFOLLOW|O_CLOEXEC|O_PATH|O_DIRECTORY) = 3
fstat(3, {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0
chdir("/")                              = 0
getresuid([1000], [0], [0])             = 0
getresgid([1000], [1000], [1000])       = 0
openat(AT_FDCWD, "/var/lib/snapd/cookie/snap.goland", O_RDONLY|O_NOFOLLOW|O_CLOEXEC) = 4
read(4, "VbuIQe-vpjye2cnFrUvhID7RRVRtO5rS"..., 254) = 52
close(4)                                = 0
openat(AT_FDCWD, "/sys/module/apparmor/parameters/enabled", O_RDONLY) = 4
read(4, "Y\n", 2)                       = 2
close(4)                                = 0
futex(0x7fb85ee32374, FUTEX_WAKE_PRIVATE, 2147483647) = 0
openat(AT_FDCWD, "/proc/mounts", O_RDONLY|O_CLOEXEC) = 4
fstat(4, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
read(4, "proc /proc proc rw,nosuid,nodev,"..., 1024) = 1024
stat("/sys/kernel/security/apparmor", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
close(4)                                = 0
openat(AT_FDCWD, "/proc/8478/attr/apparmor/current", O_RDONLY) = -1 ENOENT (No such file or directory)
futex(0x7fb85ee32368, FUTEX_WAKE_PRIVATE, 2147483647) = 0
write(2, "cannot query current apparmor pr"..., 37cannot query current apparmor profile) = 37
write(2, ": Invalid argument\n", 19: Invalid argument
)    = 19
exit_group(1)                           = ?
+++ exited with 1 +++
error: exit status 1

Did you guys tried different kernel series by now?

mhwd-kernel -li
mhwd-kernel -l
sudo mhwd-kernel -i [kernel]

Replace [kernel] with the kernel you want to try out.

I’m currently in contact with my friends at Canonical. Maybe some certificates or policies ran out. When I get some solution, I’ll post it here.

FS#68943 : AppArmor aa_getcon fails on LTS kernel

So you guys may want to try newer kernels than 5.4 … Also I’m trying with Canonical Developers to fix that issue early 2021.

Interesting, I was running 5.4 (LTS, Recommended) so the previous output was from 5.4, But since you asked about kernels, I figured I’ll try and install 5.9, and then GoLand IS running…

…BUT the terminal where I started GoLand from ended up in an infinite loop of time-out messages until I closed GoLand. So there is definitely a problem here.

A portion of the output (end part) : [pid 2598] futex(0x7f3dec122928, FUTEX_WAKE_PRIVATE, 1) = 0[pid 2598] futex( - Pastebin.com

EDIT : The infinite output happens when I start it with:

snap run --strace=--raw goland

but when I start it with just:

goland

everything seems to work fine. So maybe it works in 5.9 after all, either way, I am happy with running 5.9, from now on. That is the next LTS and recommended kernel anyway, right?

Current feedback from Canonical:

Canonical, [31.12.20 12:16]
Philip you can build that C snippet and try to reproduce it

Philip M, [31.12.20 12:16]
will see when I get to it

Canonical, [31.12.20 12:18]
i don’t think we execute a scenario with snap-confine linked to libapparmor 3.xx running on older kernels, the snapd snap is built on 16.04 such that it link with the oldest libc and thus works on all systems

Canonical, [31.12.20 12:18]
on distros such as leap there is one kernel version so there’s no risk on incompatiblilty between libapparamor and the kernel’s aa stack

Canonical, [31.12.20 12:19]
that leaves only arch, manjaro and a handfull of derivatives where you can switch between the new and old kernels bu the userland stays unchanged :confused:

Philip M, [31.12.20 12:20]
[phil@development tmp]$ gcc a.c -lapparmor
[phil@development tmp]$ ./a.out
aa_getcon: Invalid argument
[phil@development tmp]$ uname -a
Linux development 5.4.85-1-MANJARO #1 SMP PREEMPT Mon Dec 21 21:38:53 UTC 2020 x86_64 GNU/Linux

Canonical, [31.12.20 12:21]
yup, and it should work on 5.9/5.10

Canonical, [31.12.20 12:22]
and this is where the init of the path to read the atribute from happens in libapparmor: libraries/libapparmor/src/kernel.c · master · AppArmor / apparmor · GitLab

Canonical, [31.12.20 12:23]
looks like there is a fallback but for some reason it isn’t used

Philip M, [31.12.20 12:24]
Seems to be an apparmor issue then

Canonical, [31.12.20 12:25]
yeah,

Canonical, [31.12.20 12:25]
the logic around that check is complex

Canonical, [31.12.20 12:25]
maybe just too-many !

We will continue on that issue in January/February.

3 Likes

In case you don’t scroll up, and look at the edit I made to my previous post:

5.10 is tagged LTS.

1 Like

I switched to 5.10 and everything works fine! :slight_smile:

2 Likes

Due to some unpleasant reasons, I can not switch to 5.10 (“Black Screen” :frowning_face:). So I’m waiting for bug-fix in 4.14 :laughing:.

3 Likes

I can confirm that upgrading from the 5.4 to the 5.10 kernel resolved this particular issue for me.

3 Likes

Bless this thread, I just noticed my snap install not working yesterday night, and I come back after celebrating new years to find this. Thank you.

2 Likes

I was fine on kernel 5.9 using ZFS 0.8.5 and applied the 2020-12-30 update today which bumped ZFS to 2.0 and now snapd is busted for me, but I do not see the same messages as above. I can reproduce this on kernel 5.9 and kernel 5.10… so I’m assuming this is more related to the ZFS update.

On my laptop which has been updated to 2020-12-30, kernel 5.10, ZFS 2.0 as well, my existing applications seem fine, but any attempt to add a new application results in messaged like below.

First off, my snap package list is now empty:

$ snap list
Name  Version    Rev   Tracking       Publisher   Notes
core  16-2.42.5  8268  latest/stable  canonical✓  core

Anything I try gives me messages like this:

$ sudo snap refresh core
error: cannot perform the following tasks:
- Mount snap "core" (10577) (cannot undo partial setup snap "core": umount: /var/lib/snapd/snap/core/10577: not mounted.)
- Mount snap "core" (10577) (cannot proceed, expected snap "core" revision 10577 to be mounted but is not)

$ sudo snap install mattermost-desktop
error: cannot perform the following tasks:
- Mount snap "core18" (1944) (cannot undo partial setup snap "core18": umount: /var/lib/snapd/snap/core18/1944: not mounted.)
- Mount snap "core18" (1944) (cannot proceed, expected snap "core18" revision 1944 to be mounted but is not)

Not sure what would be useful …

$ ls -l /var/lib/snapd/snap/
total 32
drwxr-xr-x 2 root root   2 Jan  2 13:25 bin
drwxr-xr-x 4 root root   5 Jan  2 14:04 core
drwxr-xr-x 3 root root   3 Jan  2 13:23 core18
-r--r--r-- 1 root root 590 Dec 31  2019 README

$ ls -l /var/lib/snapd/snap/core      
total 19
drwxr-xr-x  2 root root  2 Jan  2 14:04 10577
drwxr-xr-x 24 root root 24 Dec  6  2019 8268
lrwxrwxrwx  1 root root  4 Dec 31  2019 current -> 8268

Thanks a ton @philm ! Upgrading the kernel to 5.10 fixed it.

Liked this thread from the VSCode Github issue tracker (my initial issue) Snap package not loading on Manjaro Linux · Issue #113637 · microsoft/vscode · GitHub.

I am having a similar issue. None of my installed SNAPS show up in Application Dashboard, however in ADD/Remove they all show installed. I can only run a snap through CL by typing snap run app.

I am fully upgraded running kernel 5.10.2-2. Any Ideas?

Thanks!!