AUR (en) - snapd

Search Criteria

Enter search criteria

Search by

Keywords

Out of Date

Sort by

Sort order

Per page

Package Details: snapd 2.66.1-1

Package Actions

Git Clone URL:	https://aur.archlinux.org/snapd.git (read-only, click to copy)
Package Base:	snapd
Description:	Service and tools for management of snap packages.
Upstream URL:	https://github.com/snapcore/snapd
Licenses:	GPL3
Conflicts:	snap-confine
Submitter:	Barthalion
Maintainer:	bboozzoo (zyga, mardy)
Last Packager:	bboozzoo
Votes:	217
Popularity:	4.47
First Submitted:	2018-01-07 17:37 (UTC)
Last Updated:	2024-11-13 08:24 (UTC)

Pinned Comments

bboozzoo commented on 2018-10-25 11:56 (UTC) (edited on 2024-04-09 07:39 (UTC) by bboozzoo)

Package update notes

2.36

2.36 is the first release with AppArmor enabled by default on Arch.

If you do not have AppArmor enabled at boot there should be no functional changes visible.

If you wish to use snaps with Apparmor, first make sure that Apparmor is enabled during boot, see https://wiki.archlinux.org/index.php/AppArmor for details. After upgrading the package, you need to do the following steps:

Reload the profiles: systemctl restart apparmor.service
Restart snapd: systemctl restart snapd.service
Load profiles for snaps: systemctl enable --now snapd.apparmor.service

2.62

Since 2.62 snapd generated additional files describing the sandbox. The snapd service needs to be restarted after the update for snaps to continue working (unless the system is rebooted after the update, in which case no additional steps are needed). To restart, run systemctl restart snapd.service

Latest Comments

« First ‹ Previous 1 .. 6 7 8 9 10 11 12 13 14 15 16 .. 25 Next › Last »

dmp1ce commented on 2020-12-11 12:33 (UTC)

@bbozzoo: booting up non-LTS works fine. Do you still want the information on the LTS version?

bboozzoo commented on 2020-12-11 06:49 (UTC) (edited on 2020-12-11 07:21 (UTC) by bboozzoo)

@dmp1ce thanks, this is highly unexpected. Everything else suggests that AppArmor is enabled, but then it really isn't working:

openat(AT_FDCWD, "/proc/1051439/attr/apparmor/current", O_RDONLY) = -1 ENOENT (No such file or directory)
futex(0x7fabaf3ad368, FUTEX_WAKE_PRIVATE, 2147483647) = 0
write(2, "cannot query current apparmor pr"..., 37cannot query current apparmor profile) = 37

Can you cat /proc/slef/attr/apparmor/current in a shell? Does it work? Does aa-status work?

Maybe it has something to do with the LTS kernel, I would suggest trying to boot the non-LTS one. Another thing to try, is to rebuild the snapd package, perhaps it was last built on your system before apparmor 2.x.x -> 3.x.x switch.

Edit: can you try building and running this snippet https://gist.github.com/dmp1ce/8a321608fbcf4c3ea61fce134e1f0b0d ?

dmp1ce commented on 2020-12-11 00:01 (UTC)

@bboozzoo: Thanks for looking into this. https://gist.github.com/dmp1ce/8a321608fbcf4c3ea61fce134e1f0b0d

bboozzoo commented on 2020-12-10 20:13 (UTC) (edited on 2020-12-10 20:14 (UTC) by bboozzoo)

@dmp1ce interesting, can you try running snap run --strace=--raw superproductivity and post the log to a pastebin? (the log may be too long for poasting in a comment here)

Edit: you need to pacman -S strace first

dmp1ce commented on 2020-12-10 20:01 (UTC)

@bboozzoo: Here is my output.

david@bar:~$ cat /proc/self/attr/current
unconfined
david@bar:~$ SNAPD_DEBUG=1 SNAP_CONFINE_DEBUG=1 snap run superproductivity
2020/12/10 14:59:51.067755 tool_linux.go:68: DEBUG: re-exec not supported on distro "arch" yet
2020/12/10 14:59:51.082619 cmd_run.go:407: DEBUG: SELinux not enabled
DEBUG: umask reset, old umask was  022
DEBUG: security tag: snap.superproductivity.superproductivity
DEBUG: executable:   /usr/lib/snapd/snap-exec
DEBUG: confinement:  non-classic
DEBUG: base snap:    core18
DEBUG: ruid: 1000, euid: 0, suid: 0
DEBUG: rgid: 1000, egid: 1000, sgid: 1000
cannot query current apparmor profile: Invalid argument

bboozzoo commented on 2020-12-10 16:28 (UTC)

@dmp1ce what does cat /proc/self/attr/current show?

Can you upload the logs of SNAPD_DEBUG=1 SNAP_CONFINE_DEBUG=1 snap run superproductivity to some pastebin?

dmp1ce commented on 2020-12-10 16:03 (UTC)

@bboozzoo, I think something is wrong with snapd, because restarting apparmor didn't help me. I am using an LTS kernel.

Here is what I tried:

david@bar:~$ superproductivity 
cannot query current apparmor profile: Invalid argument
1 david@bar:~$ sudo systemctl restart apparmor
[sudo] password for david: 
david@bar:~$ superproductivity 
cannot query current apparmor profile: Invalid argument
1 david@bar:~$ uname -a
Linux bar 5.4.82-1-lts #1 SMP Tue, 08 Dec 2020 12:10:59 +0000 x86_64 GNU/Linux

bboozzoo commented on 2020-12-10 10:12 (UTC)

@dmp1ce hit this today after the kernel update, but restarting apparmor.service fixed it. Looks like aa_getcon() from libapparmor returned EINVAL, which is weird because it's supposed to go and read /proc/self/attr/current AFAIK.

dmp1ce commented on 2020-12-09 13:36 (UTC)

Is anyone here getting an apparmor error? I'm getting:

$ hello-world
cannot query current apparmor profile: Invalid argument

sbussetti commented on 2020-11-07 23:05 (UTC)

I've done a full system update as of 20201107.

Attempting to install the latest version of snapd from here (currently '2.47.1-2') fails for me in the following way:

$ git clone https://aur.archlinux.org/snapd.git
$ cd snapd
$ makepkg -si

==> Making package: snapd 2.47.1-2 (Sat 07 Nov 2020 06:03:31 PM EST)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
  -> Found snapd-2.47.1.tar.xz
==> Validating source files with sha256sums...
    snapd-2.47.1.tar.xz ... Passed
==> Extracting sources...
  -> Extracting snapd-2.47.1.tar.xz with bsdtar
==> Starting prepare()...
==> Removing existing $pkgdir/ directory...
==> Starting build()...
*** Setting version to '2.47.1-2' from user.
# github.com/snapcore/snapd/cmd/snap
panic: runtime error: slice bounds out of range [:3965974062] with capacity 566288

goroutine 1 [running]:
cmd/internal/goobj2.(*Reader).StringAt(...)
        /usr/lib/go/src/cmd/internal/goobj2/objfile.go:539
cmd/internal/goobj2.(*Reader).StringRef(0xc00063a7e0, 0x9f83, 0x38, 0x252)
        /usr/lib/go/src/cmd/internal/goobj2/objfile.go:561 +0x112
cmd/internal/goobj2.(*Reader).Pkg(...)
        /usr/lib/go/src/cmd/internal/goobj2/objfile.go:597
cmd/link/internal/loader.(*Loader).resolve(0xc00061c000, 0xc000620cc0, 0x38a7ffffffb, 0x40a4)
        /usr/lib/go/src/cmd/link/internal/loader/loader.go:603 +0xe5
cmd/link/internal/loader.Reloc2.Sym(0x7fcc5a07fbe8, 0xc000620cc0, 0xc00061c000, 0x0, 0x40a4)
        /usr/lib/go/src/cmd/link/internal/loader/loader.go:83 +0x48
cmd/link/internal/ld.(*deadcodePass).flood(0xc0000640a0)
        /usr/lib/go/src/cmd/link/internal/ld/deadcode.go:154 +0x1e9
cmd/link/internal/ld.deadcode(0xc000073880)
        /usr/lib/go/src/cmd/link/internal/ld/deadcode.go:264 +0xcc
cmd/link/internal/ld.Main(0x86f840, 0x20, 0x20, 0x1, 0x7, 0x10, 0x0, 0x0, 0x6dab5f, 0x1b, ...)
        /usr/lib/go/src/cmd/link/internal/ld/main.go:235 +0xd3c
main.main()
        /usr/lib/go/src/cmd/link/main.go:68 +0x1dc
==> ERROR: A failure occurred in build().
    Aborting...