Is anyone here getting an apparmor error? I'm getting:
$ hello-world
cannot query current apparmor profile: Invalid argument
| 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 .. 10 11 12 13 14 15 16 17 18 19 20 .. 28 Next › Last »
Is anyone here getting an apparmor error? I'm getting:
$ hello-world
cannot query current apparmor profile: Invalid argument
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...
@codyps applied, thank you!
Package currently fails to build for me with the error:
loadelf: $WORK/b060/_pkg_.a(_x011.o): 284706: sym#70: ignoring symbol in section 1 (type 0)
.rela: relocation target _cgo_26061493d47f_C2func_getaddrinfo not defined
/usr/lib/go/pkg/tool/linux_amd64/link: too many errors
This is fixed by adding -linkmode external to the go flags used. This is based on the current go packaging guidelines (https://wiki.archlinux.org/index.php/Go_package_guidelines)
Here's a patch: https://gist.github.com/5a8dec1b14f1869d7882feb1bd7832ea
@henrylaxen this still looks wrong, I do not have to modify anything in a chroot and I don't understand why need to do so. I can only recommend you build the AUR packages in clean chroots.
Thanks bboozzoo for the pointers. I got it to compile by changing:
CPPFLAGS="-D_FORTIFY_SOURCE=2"
to CPPFLAGS="-D_FORTIFY_SOURCE=2 -O2"
Best wishes, Henry Laxen
@henrylaxen it builds fine in my system and in a clean chroot. Maybe you're setting something in your environment? The /etc/makepkg.conf file is owned by pacman, so maybe you can try reinstalling that to reset whatever modifications you have there.
If that doesn't help you can always try and debug the recipe, adding -x -v to go build commands will produce more useful output.
I never changed them from the default. I think these are the ones you are looking for:
CPPFLAGS="-D_FORTIFY_SOURCE=2"
CFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fno-plt"
CXXFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fno-plt"
LDFLAGS="-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now"
If there are other flags, just let me know. Best wishes, Henry Laxen
@henrylaxen what build flags are set in /etc/makepkg.conf?
When trying to install, I get: In file included from /usr/include/bits/libc-header-start.h:33, from /usr/include/stdlib.h:25, from _cgo_export.c:3: /usr/include/features.h:397:4: error: #warning _FORTIFY_SOURCE requires compiling with optimization (-O) [-Werror=cpp] 397 | # warning _FORTIFY_SOURCE requires compiling with optimization (-O) | ^~~~~~~ cc1: all warnings being treated as errors ==> ERROR: A failure occurred in build(). Aborting...
Not sure how to proceed from here. Any pointers will be appreciated. Best wishes, Henry Laxen
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.