[00:35] kyrofa and? [00:55] sergiusens, seems to work, but my test case is broken anyway (opencv) so I still want to poke at it some more tomorrow. Left some comments on the PR [00:59] zyga-suse: not crazy urgent, not warranting a point release on its own, but it is something we need sorted to have LXD actually be at feature parity with the deb package. Custom seccomp policies is a feature we've had quite a bit of interest for lately and it's pretty unfortunate that it's not working with the snap. [01:08] kyrofa it would be nice to know how it is broken and what is the test case, I'll most likely be off tomorrow but all the info you can get would be good [01:21] sergiusens, it's the bug I logged about snapcraft on trusty [01:21] Details are there === chihchun_afk is now known as chihchun === JoshStrobl is now known as JoshStrobl|zzz [05:24] stgraber: I understand, I'll talk to mvo [05:40] stgraber: zyga-suse: not sure what I see here: https://paste.ubuntu.com/25770362/ [05:41] that's a snapd bug [05:41] that got fixed in a 2.28 point release [05:41] ah good to know [05:41] which isn't yet in stable as it seems [05:43] stgraber: yeah, with latest candidate of core it seems to be fixed [06:03] morphis: indeed, this is fixed in one of the point releases after 2.28, try .5 to be sure [06:10] snappy-m-o autopkgtest 1630 xenial:amd64:integration [06:10] elopio: I've just triggered your test. [06:18] ogra_: hi. Looks like psplash is not present in cm3? Is it like forgotten there? [06:46] mvo: good morning [06:46] hey zyga-suse [06:46] zyga-suse: how ar ethings? [06:46] mvo: sorry to start like that straight when you join [06:47] https://bugs.launchpad.net/snapd/+bug/1724697 [06:47] Bug #1724697: snap-confine shouldn't setup a seccomp policy if policy is @unrestricted [06:47] we need to solve this quickly [06:47] mvo, stgraber said it's not a 2.28.6 thing but important for him [06:48] mvo: I think the idea to keep the file and put a unique string into it is simple and should be enough [06:49] zyga-suse: ok, sounds reasonable [06:49] zyga-suse: I'm just reading the bugreport [07:09] zyga-suse: I can work on a fix this morning, just doing some pi2 related research but I'm almost done [07:10] mvo: I can help too [07:10] mvo: I'm working on loads of tests for the new overlayfs mount feature [07:10] zyga-suse: overlays are priority [07:10] ok [07:10] zyga-suse: at least that is my understanding :) [07:10] zyga-suse: hey, if we could get that for 2.29 ... [07:10] zyga-suse: maybe as a experimental thing or so? [07:11] I think it's too soon as neither gustavo nor jamie saw it yet [07:11] but we'll see :) [07:11] I need to land a prereq branch [07:11] I may yet tweak it to move files around and shrink diff for future PRs but not my priority yet [07:34] o/ [07:37] morning :) [07:43] kalikiana: thinking about hardening `get_os_release_info`, as suggested by kryofa. What about a little bit more robust `get_os_release_info` and some `get_os_release_fieldname` that wrap the first and provide fallback? Like `get_os_release_version_id()`. This way, the user does not need to know the actual dictionary key name [07:45] c-lobrano: Hmm maybe one step further and make it a little class? [07:50] kalikiana: yes, that would be good [08:47] PR snapcraft#1633 opened: recording: record information from the image in container builds [08:50] elopio: since you're awake: we hit the timeout again in snapcraft#1632 :-( [08:50] PR snapcraft#1632: libraries: exclude the full set of libc6 [08:57] I'm working on the split. [08:57] * zyga-suse -> coffee [09:06] awesome [09:10] pedronis: how're things? [09:10] mvo: has #4050 earned your +1? [09:10] PR #4050: cmd/snap: tell translators about arg names and descs req's [09:14] Chipaca: I look in a tiny bit [09:15] mvo: how's things? [09:15] Chipaca: I can foresee nitpicking about tidyNoticef, as the name gives no hint that it transforms into a panic under certain conditions. but I have not made up my mind much [09:16] Chipaca: otherwise things are good mostly, looking at pi firware stuff right now [09:16] mvo: do we have a reproducer for the insane flip-flops? [09:18] Chipaca: what flip-flops, do you have a reference to a forum post or a bugreport? [09:20] PR snapd#4054 opened: snap-{confine,seccomp}: make @unrestricted fully unrestricted [09:20] zyga-suse: and you may say "told you so" now :) I remeber we talked about fully unrestricted seccomp and iirc you suggested we should do it in the above way [09:21] aaaaaaaaaaaaaaaaaaaaaaaaaaaaa3aaaaaaad [09:21] sorry [09:25] mvo: sorry, i meant the thing where sergio's pi3 would boot into one thing but think it's booting into another? something like that [09:26] Chipaca: we know it is caused by the ubuntu-image snap, once sergio uses the deb things are ok. my plan was to look into it more once I have a pi3 (should arrive today) [09:26] ah ok [09:26] Chipaca: which is a huge relief that its not a snapd issue [09:27] mvo: we can shake our fists at barry and move on :D [09:30] Chipaca: :-D [09:38] mvo: impossible, I don't recall saying that ;-) [09:39] * zyga-suse is progressing thrgough testing, with some nice simplifications and improvements to code in result of finding tiny details off [09:46] mvo, zyga-suse: https://github.com/canonical-docs/snappy-docs/pull/138 [09:46] PR canonical-docs/snappy-docs#138: Update Fedora snapd to 2.28.5 [09:46] davidcalle ^ [09:46] zyga-suse: this will likely be the end of the line for Fedora 25 [09:47] as by the time 2.29 becomes available, Fedora 25 will EOL [09:49] zyga-suse, you should reach out to pitti at some point to talk about downstream Fedora CI [09:49] he's been working on a project to introduce the equivalent of autopkgtests in Fedora for a while now [09:59] zyga-suse: does "cannot open current mount profile: /run/snapd/ns/snap.**.fstab:permission denied" ring any bell? we got a bugreport about this, I can forward [10:17] * kalikiana break [10:20] PR snapd#4055 opened: daemon: generate a forbidden response message if polkit dialog is dismissed [10:21] PR snapd#4056 opened: tests: improve revert related testing [10:44] mvo: hmmm, no, not immediately, looks like apparmor [10:44] mvo: please forward [10:44] zyga-suse: I did [10:44] zyga-suse: its the mail from pierre, I don't have many details yet [10:44] mvo: ePierre? [10:48] zyga-suse: yeah, I think so [10:49] zyga-suse: does http://paste.ubuntu.com/25771634/ ring a bell? [10:49] mvo: that looks like a custom base snap with no /dev [10:50] zyga-suse: that is from core stable -> edge auto refresh test http://paste.ubuntu.com/25771638 has the debug [10:51] zyga-suse: anyway, I have a look [10:51] zyga-suse: but it looks like pierre foudn a bug [10:51] mvo: this code didn't change [10:51] mvo: I bet it's /dev missing [10:51] mvo: FYI, I'm chatting with ePierre on #chekbox [10:51] #checkbox [10:52] zyga-suse: aha, ok [10:52] I want to collect some quick info since pierre is likely to EOD any time now [10:52] mvo: can you forward the rport please? [10:53] zyga-suse: I did that already, you are in the CC [10:54] zyga-suse: message-id: 20171019102101.h7wlysxnpqjfufqk@bod [10:54] I get 0 matches [10:54] maybe gmail doesn't filter on those [10:56] mvo: ok, I understand the issue now [10:56] mvo: not sure why it happens but here's what happens: [10:57] mvo: when we introduced snap-update-ns as the namespace initializer [10:57] mvo: we removed the ability to read / process .fstab files from snap-confine [10:57] mvo: after reverting we are running on the profile from the +next version [10:57] mvo: I think it looks like a bug in the code that re-builds snap-confine's apparmor profile [10:58] mvo: does that make sense? [10:58] mvo: after revert we should immediately rebuild the profile [10:59] mvo: what is curious here is that since the profile is *path based* it should not be a problem [10:59] the old profile is around [10:59] mvo: (around as in loaded in memory) [11:00] zyga-suse: well, we reboot in between in tests on core [11:00] zyga-suse: but yeah, it makes sense [11:00] hmmm [11:01] zyga-suse: I mean, if its loaded in memory it will get lost accross the reboot [11:01] this should not be an issue on core [11:01] yes [11:01] well [11:01] no [11:01] zyga-suse: the report is about core afaict [11:01] across reboot we'll keep the file in /etc/apparmor.d [11:01] so it will get re-loaded [11:01] was this on core on classic? [11:01] zyga-suse: from what I read its a regular core device (caracalla/stlouis9 [11:01] ) [11:01] right [11:01] * zyga-suse thinks [11:02] it doesn't seem device specific [11:02] so we should be able to reproduce it [11:02] yeah [11:02] that was edge->stable? [11:02] I did a PR that tests some more things with reverts [11:02] yeah [11:02] thank you [11:02] do you want me to explore or shall I keep at layouts? [11:02] see the linked PR [11:03] ack [11:03] I can work a bit on this and get a reliable test, then we can brainstorm again [11:03] zyga-suse: just wanted to double check that its not something obvious [11:03] (or known) [11:04] no, nothing obviously smoking-gun-wrong [11:04] ta [11:10] mvo: when we run reexecing snap-confine do we follow the current symlink? [11:11] meh [11:11] mvo: I'm dumb [11:11] mvo: I understand now [11:11] mvo: on core / is the core snap [11:11] mvo: so when we get new core via update [11:11] mvo: (and we don't reload the profile there) [11:12] mvo: so when we get the new core, we must not follow any current symlinks and must use the old profile [11:12] mvo: right? [11:12] mvo: so we literally run /usr/lib/snapd/snap-confine [11:13] zyga-suse: correct [11:14] mvo: so dump my other theories, the cause still is likely (we removed the right to touch .fstab profiles) but why it gets applied here is unclear [11:14] mvo: (assuming before reboot) [11:19] I'm getting hungry, let's break for some lunch [11:22] zyga-suse: good idea [11:56] mwhudson: Hey! I was wondering if we should discuss snapcraft#1557 a bit [11:56] PR snapcraft#1557: cleanbuild: add a --image option to build in a different image [12:07] re [12:07] kalikiana: you know it's 1am for mwhudson, yes? [12:08] Chipaca: Oh, I didn't realize. What timezone is he in? [12:09] kalikiana: NZ [12:09] "the far side of the moon^Hearth" [12:09] Heh [12:09] Thanks [12:09] I'll try to ping him at a better time then [12:10] kalikiana: that's not to say he isn't sometimes around at this time, but it's usually bad news :-) [12:14] * zyga-suse works on 4008 [12:14] I can put some future code there to make eventual diff smaller [12:15] hmm [12:15] on go 1.9.1 I cannot "go test" stuff anoymre [12:16] *anymore [12:16] zyga@faroe:~/snapd/cmd/snap-update-ns> go test . [12:16] # github.com/snapcore/snapd/vendor/gopkg.in/tomb.v2 [12:16] flag provided but not defined: -goversion [12:16] niemeyer: ^ does this ring any bells? [12:20] * zyga-suse reboots [12:22] ok, all good now [12:22] probably stale env after update [12:28] zyga-suse: overlayfs? I thought this was being done with bind mounts... [12:36] jdstrand: with both [12:37] zyga-suse: No, I've never seen that flag either I think [12:37] niemeyer: it's all good now [12:38] zyga-suse: Perhaps go tool was out of date with underlying tooling [12:38] yes, I just updated; it's okay now, probably some stale stuff while I was logged in [12:42] mvo, I am creating a test for gsettings interface, an I am getting "gsettings: not found" when I execute a command [12:42] cachio: curious what this is about [12:42] cachio: it is installed and in /usr/bin/gsettings I pressume? [12:43] yes [12:44] mvo, it is just a wrapper for gsettings command [12:45] the snap makes gsettings "$@" [12:46] mvo: just saw this from go vet [12:46] cmd/snap-repair/runner.go:254: arg r.RepairID() for printf verb %d of wrong type: string [12:46] cmd/snap-repair/runner.go:415: arg repair.RepairID() for printf verb %d of wrong type: string [12:46] mvo: shall I fix? [12:48] odd, I don't see the issue [12:48] %d is printing int's [12:49] pedronis, hey, tests/lib/assertions/auto-import.assert is expired, do you know how to generate a new one? [12:50] zyga-suse: I was unaware that layouts required overlayfs. when was the greenlight given on overlayfs? we can't guarantee it is going DTRT with apparmor in modern kernels or in backported apparmor to older kernels. overlayfs is unbackportable to older kernels. all the same arguments as always... [12:51] zyga-suse: in 451, it's doing ("... %s/%d != %s/%d", repair.BrandID(), repair.RepairID(), brandID, repairID) [12:51] jdstrand: this is a new development (relatively), we plan to use overlayfs to poke writable holes over squashfs; I made a RFC branch that does this [12:51] Chipaca: I know, I think go vet is wrong here [12:52] sborovkov, i changed teams and all, i simply didnt get to cm3 yet, but should be ready before end of this week (i'm currently working on the remaining bits for cm3 and dragonbard splash support) [12:52] Chipaca: especially after fixing it tests are failing [12:52] zyga-suse: RepairID() returns a string [12:52] aha [12:52] zyga-suse: obviously it's a new development :) my question is where was it discussed? it seems to be ignoring the previous discussions [12:52] jdstrand: I don't remember if it was a hangout recently or IRC recently [12:53] jdstrand: I recall the earlier discussion but this is an experiment to see if we can use overlay for this purpose [12:53] zyga-suse: I thought things like this were supposed to be captured in the forum? this is a major technical decision [12:53] jdstrand: as it presents simpler semantics and has easier undo story [12:54] jdstrand: indeed, I wanted to talk to you about this because it's a big change but all the sprints/holidays were in the way [12:54] jdstrand: the short summary is that we'd like to use overlayfs over squashfs [12:54] jdstrand: as a hole-poking tool [12:55] Chipaca: no, it's an int: [12:55] ... error string = "cannot fetch repair, repair id mismatch canonical/%!s(int=2) != canonical/4" [12:55] ... regex string = "cannot fetch repair, repair id mismatch canonical/2 != canonical/4" [12:55] jdstrand: anyway, let's put that on hold now [12:55] jdstrand: (the discussion) [12:55] zyga-suse: i was wrong ¯\_(ツ)_/¯ [12:56] * Chipaca tries to find out why he was wrong [12:56] jdstrand: I'll have a thread and PR to review (very short) soon after https://github.com/snapcore/snapd/pull/4008 lands [12:56] PR #4008: cmd/snap-update-ns: create missing mount points automatically [12:56] (that's what I'd like to focus on now) [12:57] I understand that. I have little confidence it is going to work reliably with apparmor considering people are backporting apparmor to older kernels (or even an unpatched kernel). I mean, it might work with a recent Ubuntu kernel. note that overlayfs wasn't even an official thing in the upstream kernrel til relatively recently. this makes snaps that utilize the feature impossible to use on older kernels where you can't backport overlayfs [12:57] * Chipaca disappears again [12:58] * zyga-suse nods [12:59] tyhicks: warning ^. the plan is to try overlayfs to poke holes in squashfs in an exploratory PR [13:00] tyhicks: (in support of layouts) [13:00] jdstrand: I have the undo logic to tweak but it looks promising (so far) [13:00] jdstrand: the diff is very small so far, which is also very very promising [13:00] ohg [13:00] standup [13:00] well, except the technologies you are utilizing have to actually work right [13:01] not to mention my point that overlayfs is new so its use means those snaps can't work on older kernels [13:03] PR snapd#3972 closed: interfaces: sanitize plugs and slots early in ReadInfo [13:03] zyga-suse: I should also stress that overlafs didn't land in its current form. it landed early and had lots of trouble with LSMs. It still has trouble with LSMs. this means that there is a huge test matrix to make sure the feature even works for kernels that claim to support the feature [13:04] * jdstrand still wonders why he or tyhicks weren't pulled into the conversation [13:04] or jj [13:05] pobably zyga will simply fix all missing LSM bits with overlayfs on the go then ;) [13:09] ... will just delay the ETA for the feature by a few years :) [13:20] Hi guys, I'm trying to build an image for my Nvidia TK1. I made an attempt on a snap gadget for the device and have created the model.json. But to make it into a image I need the gadget snap to be available. I'm on Ubuntu 16.04 (amd64) but the device I'm building for is armhf. So I can't use the snap install --dangerous to install the gadget snap I need. How do I build the image on my arm64 workstation? [13:21] skjensen, you need to use the ubuntu-image tool (theer is a snap with it) and use the --extra-snaps optin to point to your local gadget [13:22] skjensen, https://docs.ubuntu.com/core/en/guides/build-device/image-building [13:22] I did try that but with little luck.. [13:22] see part 3 [13:23] sudo ubuntu-image -c edge --extra-snaps /path/to/your/gadget.snap /path/to/your/model.assertion [13:27] Still can't find it.. [13:27] whats the exact error ? [13:27] skj@laptop:~/Documents/snap/TK1$ sudo ubuntu-image -c edge --extra-snaps /home/skj/Documents/snap/TK1/tk1_16-0.1_armhf.snap /home/skj/Documents/snap/TK1/tk1.model [13:27] error: cannot find snap "tk1_16-0.1_armhf": snap not found [13:27] COMMAND FAILED: snap prepare-image --channel=edge --extra-snaps=/home/skj/Documents/snap/TK1/tk1_16-0.1_armhf.snap /home/skj/Documents/snap/TK1/tk1.model /tmp/tmp904xzqti/unpack [13:28] and I have defined the gadget like this in the model.json file "gadget": "tk1_16-0.1_armhf", [13:28] ah [13:29] you just want the name in there [13:29] "tk1" [13:29] change that and re-create the assertion [13:30] Yes, that's working.. :) [13:30] ;) [13:30] I had it with only the name to start with, but because it couldn't find it I changed to the complete name of the file.. [13:31] Okay, so far so good.. Now I need the kernel snap.. ogra, did you say I can use the bbb kernel? [13:31] yeah "linux-generic-bbb" is the name ... [13:32] though ubuntu-image might complain that this isnt a "canonical" package ... in that case use snap download oor grab it from https://code.launchpad.net/~snappy-dev/+snap/linux-generic-bbb/+build/76303 and use the --extra-snaps arg for it as well [13:33] It found it correctly.. [13:33] cool [13:34] i knoow there is some builtin policy that the owner of the gadget must match the owner of the kernel snap ... unless the kernel is owned by canonical ... seems we dropped it [13:34] Nope.. you are right.. Just a delayed error message.. [13:34] error: cannot use kernel "linux-generic-bbb" published by "QfOqF7d2M1Pk2O0SbEKqTdB9Ry2aI0BP" for model by "bdSXYoRKHbnUgDeg0MU6rJIID8IODntX" [13:35] so just pull it from the LP build page and use --extra-snaps [13:35] that should ignore the requirement [13:35] It's downloading.. :) [13:35] (i hope) [13:36] Me too.. Unfortunately I got to go pick up my son.. so will have to wait before I can test the image.. I'm right in saying I can flash this image to a SD card and boot from that? [13:36] yes [13:37] (if your booard generally can boot from SD indeed) [13:37] It's one of it's best features, if there is a bootable SD card it will boot from that by default.. [13:39] Okay, I'm gone.. Thanks a lot for the help again.. :) [13:39] then it shoould just woork (if your gadget is correct :) ) [13:49] ok, stuff is reabsed [13:49] now to tie overlay mount entries to things that use them [13:49] so that undo works :) [13:50] come to think of it, I think it's actually easier than I thought [13:51] perhaps we don't need to annotate overlays [13:51] we can just keep them IFF there's anything mounted underneath [13:51] so yeah, less patches needed :) [13:54] * kalikiana lunch time [13:58] zyga-suse: overlays? [13:58] are we using overlayfs now? [13:58] well, I'm trying to [13:58] zyga-suse if you have a discussion on irc or a hangout the "minutes" for it at least should really make their way to the forum [13:59] kalikiana kyrofa elopio et. al. reminder I am out today [13:59] sergiusens: are you referring to overlays or something else? [14:00] zyga-suse yes, but anything really needs to go there if it "matters" [14:01] kyrofa mind looking at snapcraft#1607 and snapcraft#1583 ? Those are yours and getting those failures out of the way would be great! ;-) [14:01] PR snapcraft#1607: python plugin: use extracted pip [14:01] PR snapcraft#1583: ament plugin: new plugin [14:01] yes, you are right; I wanted to describe this on the forum but I had a few crazy days and I spent most of the time on just coding this [14:02] I'll write something now [14:02] so for once, a feature that actually already has SELinux support :) [14:04] Son_Goku: https://github.com/zyga/snapd/commit/f34aca5625013b3d02ee6dba384e9918770f94ef#diff-4480ffd44957efa3395867c929f88014R145 [14:11] mvo, same error using devmode [14:11] to use gsettings [14:11] cachio: any denials? [14:11] mvo, no [14:11] zyga-suse, I am using snap try [14:12] zyga-suse, could that affect? [14:12] hmm [14:12] yes, perhaps [14:42] kyrofa: mind taking another look at snapcraft#1412 today? I hope I made it clearer now what's addressed there vs. the other PR [14:42] PR snapcraft#1412: lxd: snapcraft refresh in containers [14:46] kyrofa, elopio: also snapcraft#1627 should be fairly straight-forward. I'm splitting lxd.py into different classes/ files to make the code more maintainable. It's getting a bit unwieldy :-D so might even be better to get this in first, since it probably makes other PRs easier to review [14:46] PR snapcraft#1627: lxd: split container classes into different files [14:46] kalikiana, will do. Just want to fix my branches now that slow tests have landed etc. [14:47] niemeyer: gentle ping about https://github.com/snapcore/snapd/pull/3958 [14:47] PR #3958: many: add support for /home on NFS [14:48] kyrofa: Aye, no rush. Let me know if you need another review from me there. === JoshStrobl|zzz is now known as JoshStrobl [14:51] cachio: if you post your work-in-progress branch I can have a look [14:51] mvo, sure === chihchun is now known as chihchun_afk [14:56] mvo, this is the branch https://github.com/sergiocazzolato/snapd/tree/tests-interface-gsettings [14:57] Agh, test_list_plugins will be the death of me [14:57] niemeyer, I think the problem about the refresh core is that after I start the stable version I see https://paste.ubuntu.com/25773077/ [14:58] zyga-suse: Ack [14:58] cachio: Looking [14:58] niemeyer, I am using the stable version from long time ago [14:58] cachio: Yeah, so exactly what we discussed [14:58] so it triggers a refresh to the current stable [14:59] reboots the device and then I start the tests [14:59] running against stable instead of using beta [14:59] cachio: Yeah.. it's a simple race with auto-refresh [14:59] cachio: As mvo predicted [15:00] niemeyer, I should wait until the autorefresh is done to trigger the refresh to beta [15:00] cachio: Yeah, that should work [15:01] niemeyer, nice, thanks for the support [15:01] cachio: np! [15:06] elopio, kalikiana I'm getting this a lot on the pip PR: https://travis-ci.org/snapcore/snapcraft/jobs/289625934 [15:07] elopio, kalikiana have you guys seen that elsewhere? [15:07] It's definitely not my error, but it only surfaces when running pip stuff, which makes me think I'm doing something to surface it [15:07] kyrofa: Yeah, I've seen and mentioned that before... the answer I got in the past was "Re-run"... [15:07] kalikiana, oh really? Okay so maybe not this PR then [15:08] kalikiana, I wasn't seeing it elsewhere, so was starting to question myself [15:09] kyrofa: I try to add a comment these days quoting the last lines of such errors, so we can check other PRs for the same false negatives [15:09] Otherwise it really is difficult to keep track of === cachio is now known as cachio_lunch [15:30] zyga-suse: fwiw, I can reproduce the issue the ePiere was describing, I think I have a test, my local spread is just unhappy, steps are pretty simple, will send via mail [15:30] zyga-suse: i.e. the error is: "cannot open current mount profile: ....fstab: permission denied" [15:31] zyga-suse: and I get an apparmor denied from /usr/lib/snapd/snap-confine [15:32] mvo: aha [15:32] mvo: right [15:32] mvo: I'll check it out, let me look at the mail [15:33] zyga-suse: I have not written the mail yet [15:33] mvo: if you have access to the shell there [15:33] mvo: look at the profile in /etc/apparmor.d [15:34] mvo: you can also collect the data about the loaded profile in sysfs [15:34] mvo: can you paste the denial really quick please? [15:34] PR snapd#4057 opened: interfaces: remove duplicated MockPlug/MockSlot helpers from interface tests [15:35] zyga-suse, can you look at this trivial if you have a moment? ^ [15:35] zyga-suse: http://paste.ubuntu.com/25773282/ [15:35] mvo: you can also poke at /sys/kernel/security/apparmor [15:35] pstolowski: yes [15:35] zyga-suse: http://paste.ubuntu.com/25773287/ is the denial [15:35] mvo: and the denial? [15:35] ah [15:35] oh [15:36] mknod? [15:36] that's odd [15:36] that's totally unexpected [15:36] can you run with SNAP_CONFINE_DEBUG=yes [15:37] zyga-suse: this is the strace (the last few lines) http://paste.ubuntu.com/25773303/ [15:37] open("/run/snapd/ns/snap.test-snapd-tools.fstab", O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC, 0666) = -1 EACCES (Permission denied) [15:38]