Hi, I can reproduce this. It doesn't seem related to the /usr merge because that was disabled with the stretch rc1 installer and it persists after installing with that. Or maybe I'm just seeing the "failure to execute snap-exec", I get this:
root@debian:~# hello.universe execv failed: Permission denied root@debian:~# journalctl | tail -n2 Jan 16 10:41:40 debian audit[600]: AVC apparmor="DENIED" operation="exec" profile="/usr/lib/snapd/snap-confine" name="/usr/lib/snapd/snap-exec" pid=600 comm="snap-confine" requested_mask="x" denied_mask="x" fsuid=0 ouid=0 Jan 16 10:41:40 debian kernel: audit: type=1400 audit(1484516500.606:8): apparmor="DENIED" operation="exec" profile="/usr/lib/snapd/snap-confine" name="/usr/lib/snapd/snap-exec" pid=600 comm="snap-confine" requested_mask="x" denied_mask="x" fsuid=0 ouid=0 So, um. Needs an apparmor person I think? Cheers, mwh On 15 January 2017 at 23:25, Stéphane Graber <stgra...@stgraber.org> wrote: > Package: snapd > Severity: important > Version: 2.20-2 > > Hello, > > On a clean stretch install, booted with apparmor enabled > (security=apparmor apparmor=1), snapd fails to run due to apparmor > failures. > > It appears to be caused by the fact that /lib is a symlink to /usr/lib, > with the symlinks getting resolved and so failing because the apparmor > profile only contains /lib paths. > > There is that and a failure to execute snap-exec if I remember correctly. > > > > It'd be great to have this fixed as snapd will very actively try to use > apparmor if it's enabled in the kernel. To the point where disabling the > apparmor profiles for snapd leads to another failure as snapd fails to > manually change profile then. > > Stéphane >
