@rsevero pacman -Qlp snapd-2.42.2-1-x86_64.pkg.tar.xz | grep 'snapd /lib' yields nothing here, that's because there's no files under /lib shipped by the package. This isn't Arch, is it?
Can you post the build log somewhere?
| 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) |
| Last Packager: | bboozzoo |
| Votes: | 231 |
| Popularity: | 3.35 |
| First Submitted: | 2018-01-07 17:37 (UTC) |
| Last Updated: | 2026-04-20 08:01 (UTC) |
« First ‹ Previous 1 .. 14 15 16 17 18 19 20 21 22 23 24 .. 28 Next › Last »
@rsevero pacman -Qlp snapd-2.42.2-1-x86_64.pkg.tar.xz | grep 'snapd /lib' yields nothing here, that's because there's no files under /lib shipped by the package. This isn't Arch, is it?
Can you post the build log somewhere?
Can't install snapd-2.42.2-1:
(1/1) checking for file conflicts [########################################################] 100% error: failed to commit transaction (conflicting files) snapd: /lib exists in filesystem (owned by filesystem) Errors occurred, no packages were upgraded.
Ideias? Suggestions?
@bboozzoo It's fixed. Thanks.
@archplayer this should be fixed now with the latest update to 2.42.1.
@archplayer would it be possible for you to provide the output of eu-readelf -n /usr/lib/snapd/snap-seccomp ? eu-readelf is part of elfutils package.
If that's easier, then readelf -n /usr/lib/snapd/snap-seccomp output is fine too.
The issue reported by @archplayer is now tracked as https://bugs.launchpad.net/snapd/+bug/1850914
Hi. Ever since end of May 2019, snappy daemon fails to start on my system (with or without apparmor). This is what I see in the output of
$ sudo journalctl -u snapd.service
...
cannot run daemon: state startup errors: [cannot obtain snap-seccomp version information: invalid format of version-info: "6f33567a6d5533534e6273424138556e5a7757582f654153436e383650336a61346537544b673975482f565059786473696e77496b3275724a39755f6d6d2f48314d544863384d51344c417a4c387845717976 2.4.1 8c73f36d3de1f71977107bf6687514f16787f639058b4db4c67b28dfdb2fd3af bpf-actlog"]
@malathion is there anything in dmesg that would suggest AppArmor blocked it? Anything in journalctl -u snapd? Does uname -r list the same kernel version as reported by pacman -Q linux?
$ sudo snap install <thing>
error: system does not fully support snapd: cannot mount squashfs image using "squashfs": mount:
/tmp/sanity-mountpoint-581485990: mount failed: Operation not permitted.
Pinned Comments
bboozzoo commented on 2018-10-25 11:56 (UTC) (edited on 2025-07-10 11:42 (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:
systemctl restart apparmor.servicesnapd:systemctl restart snapd.servicesystemctl enable --now snapd.apparmor.service2.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.service2.70
Snapd 2.70 drops setuid permissions on /usr/lib/snapd/snap-confine in favor of explicit file capabilities. After an upgrade to 2.70, the users are prompted to restart the
apparmor.serviceotherwise attempts to run snaps will error withcannot set capabilitiesmessage.