*** crazynig has joined #buildstream | 01:12 | |
crazynig | ANOTHER NIGGER ACTING CRAZY!! | 01:13 |
---|---|---|
crazynig | https://www.youtube.com/watch?v=ySSdeYpoWBU | 01:13 |
crazynig | realnigzlqctosqu.onion or realnigzlqctosqu.onion/6667 | 01:13 |
crazynig | paulsherwood laurenceurhegyi adds68 uajain persia hergertme benbrown jjardon[m] waltervargas[m] mattiasb mrmcq2u[m] cgmcintyre[m] ptomato[m] anahuelamo juergbi brlogger gitlab-br-bot ironfoot | 01:13 |
*** crazynig has left #buildstream | 01:13 | |
*** tristan has joined #buildstream | 01:16 | |
*** ChanServ sets mode: +o tristan | 06:26 | |
paulsherwood | marvellous what idiots can achieve on the internet, dontcha think? | 07:23 |
paulsherwood | this makes me wonder, is it possible to edit the irc logs? would be a shame to have that kept for posterity | 07:24 |
*** bochecha has joined #buildstream | 07:57 | |
*** jonathanmaw has joined #buildstream | 08:14 | |
tristan | here ? | 09:06 |
tristan | oh was there a spam bot ? | 09:07 |
tristan | That can happen | 09:07 |
tristan | ah yeah, sometimes its that, sometimes its all praise allah | 09:08 |
tristan | sometimes it's come see our darkweb thing ! | 09:08 |
*** tlater has joined #buildstream | 09:13 | |
paulsherwood | tristan: time to put on your BD hat :) | 09:36 |
tristan | paulsherwood, ah are we talking my metric ton of emails ? | 09:57 |
tristan | heh | 09:57 |
paulsherwood | yup. "Encourage debate where necessary, but if things get bogged down, be a benevolent dictator" | 09:58 |
tristan | Yeah, it's over now | 09:58 |
paulsherwood | :) | 09:58 |
*** bochecha has quit IRC | 10:13 | |
*** tristan has quit IRC | 10:49 | |
*** tristan has joined #buildstream | 11:34 | |
*** bochecha has joined #buildstream | 12:12 | |
*** tlater has quit IRC | 12:54 | |
*** tlater has joined #buildstream | 12:57 | |
jonathanmaw | hrm, I'm running buildstream on an ARM system, and I'm getting the error "Creating new namespace failed, likely because the kernel does not support user namespaces. bwrap must be installed setuid on such systems." when I try to start building. | 12:59 |
jonathanmaw | first occurs when running ldconfig for the first time. | 13:00 |
jonathanmaw | I've already tried `chmod u+s /usr/bin/bwrap` | 13:00 |
jonathanmaw | is there a difference being "installed setuid" and "the binary has setuid permission"? | 13:07 |
jonathanmaw | also, getting a kernel that has user namespaces enabled is going to be a problem for me, since I'm not quite sure where the kernel for this came from, and especially not how to get a uImage for it (aarch64) | 13:09 |
tlater | Hm. Mounting the fuse mount in the sandbox root causes mount to hang. | 13:34 |
tlater | I think it's because sandbox mount->fuse mount point, fuse mount point->sandbox mount | 13:34 |
tlater | But I can't make out what the correct mount paths should be if that's wrong] | 13:35 |
tristan | jonathanmaw, it must be setuid root | 13:41 |
jonathanmaw | tristan: the bwrap binary has full permissions "-rwsr-xr-x 1 root root 43064 Jul 25 20:10 /usr/bin/bwrap" | 13:42 |
tristan | tlater, I doubt this is the reason | 13:42 |
jonathanmaw | I thought that was setuid root | 13:42 |
tristan | tlater, you might just try to manual fusermount something and then mount something in a subdir to test it, though | 13:43 |
tristan | jonathanmaw, ummm that should be correct permissions | 13:44 |
tristan | it's same as I have here | 13:44 |
tlater | tristan: What path is the sandbox supposed to run in? $BUILDDIR/root or $BUILDDIR/scratch/<something> | 13:44 |
tlater | Because right now I'm mounting $BUILDDIR/root -> $BUILDDIR/scratch/_ -> $BUILDDIR/root | 13:45 |
tristan | jonathanmaw, oh wait, that error message; might actually mean what it says, and if it does; I dont think there is anything to be done for it | 13:45 |
tristan | sigh | 13:46 |
* tristan now has to remember all the details of how he setup the mount map ? | 13:46 | |
tristan | I cant say off the top of my head really | 13:46 |
tlater | Well, I can bash my head into this for a bit longer, just if you happened to know :) | 13:47 |
tristan | The scratch directories are so that the fuse mounts have a dedicated place to cache things | 13:47 |
tristan | The _s are substituted /s | 13:47 |
tristan | (s being the plural of the char) | 13:48 |
tlater | Ah, so _ would just be / | 13:48 |
tlater | And _ is a cache of / | 13:48 |
tristan | maybe, I cant recall | 13:48 |
tlater | Hm. Well, more debugging required then. | 13:48 |
jonathanmaw | tristan: hrm, googling around, it's possible that it's a problem that's fixed in newer versions of bwrap. | 13:49 |
tristan | aha | 13:51 |
tristan | tlater, So it's like this | 13:52 |
tristan | tlater, see sandboxbwrap.py Mount() class __init__() | 13:53 |
jonathanmaw | this chroot is debian unstable, so I'm surprised that the version is as old as 0.1.8. looks like I'm going to have to build it from source | 13:54 |
jonathanmaw | hrm, 0.1.8 looks like the newest bubblewrap. | 13:55 |
tristan | tlater, if there is safe hardlinks, then: "The mount source will be $BUILDDIR/scratch/{normalized_sandbox_relative_path}/mount" | 13:55 |
tristan | jonathanmaw, your kernel has linux namespaces ? | 13:55 |
jonathanmaw | CONFIG_NAMESPACES=y | 13:56 |
tristan | tlater, and "The mount origin will be $BUILDDIR/root/not/normalized/sandbox/path | 13:56 |
tristan | " | 13:56 |
jonathanmaw | CONFIG_USER_NS is not set | 13:56 |
tristan | tlater, so there is an origin and a source; the source is the only thing of concern for users of that Mount() class that exists in _sandboxbwrap.py | 13:57 |
tristan | tlater, the source is the mount point we use to remount into $BUILDDIR/root during sandbox.run() | 13:57 |
tristan | So yes; the mounts are intentionally remounted *in place* | 13:58 |
tlater | tristan: So I should indeed mount $SOURCE -> $BUILDDIR/root ? | 13:58 |
tristan | tlater, this means that once everything is staged and a build fails, you dont have this crazy directory structure with things staged all over the place | 13:58 |
tristan | well, maintaining a single dir is intentional, I suppose it could be implemented a bit differently | 13:59 |
tlater | Darn, I hoped this would be the issue. I'm still not sure why mount fails in this case. | 13:59 |
tristan | tlater, the answer to your last is No. Unless it's the one case that you happen to be mounting the rootfs :D | 13:59 |
tlater | tristan: That's exactly the case where it fails :( | 13:59 |
tristan | Are they happening in the right order ? | 14:00 |
tristan | that's of course important | 14:00 |
tlater | tristan: Pretty sure they are. Even if I comment out all other mounts it still fails. | 14:00 |
tristan | jonathanmaw, you probably need that yeah | 14:00 |
tristan | jonathanmaw, I dont see how on earth bubblewrap could create a namespace without it | 14:00 |
tristan | a user namespace, of course | 14:01 |
tlater | That is, if by correct order you don't mean $SOURCE -> $BUILDDIR/root, $FUSE_WIZARDRY -> $SOURCE | 14:01 |
tristan | tlater, as I said; try it in a shell | 14:01 |
tristan | tlater, I rather meant, mounting / before mounting /buildstream | 14:02 |
tlater | tristan: Yeah, those are done in the right order. Hm, I'll try doing it completely manually. | 14:02 |
tristan | exactly | 14:02 |
tristan | I cant say exactly for sure that the bubblewrap mounts are of the same nature, but I *think* they are just regular bind mounts done by privileged bwrap | 14:03 |
tristan | so if that's the case; it should be the same with calling mount | 14:03 |
tlater | tristan: I've read through the bubblewrap source, I'm pretty sure they are. Which is why I'm so confused by this. | 14:04 |
tristan | nod | 14:04 |
tristan | tlater, I wonder; if you are perhaps failing to cleanup your devpts/tmpfs/procps mounts | 14:07 |
tlater | tristan: For debugging I've completely removed any mounting besides root - in this case that shouldn't matter. | 14:08 |
tristan | maybe trying to mount foo/bar/baz on top of itself, when foo/bar/baz/dev is mounted devpts, causes an issue by hiding an existing devpts ? | 14:08 |
tristan | especially if it's busy ? | 14:08 |
tristan | Ah | 14:08 |
tristan | tlater, this can be helpful: https://github.com/skorokithakis/python-fuse-sample/blob/master/passthrough.py#L130 | 14:10 |
tristan | tlater, thats a python fuse example, and the bottom shows how you can take our SafeHardliksOps and use it in a standalone main() | 14:11 |
tlater | tristan: Cool, ta, easier than reading the buildstream source :) | 14:11 |
tristan | so you could reproduce in the shell better | 14:11 |
tristan | you could even try the example verbatim and possibly reproduce I dont know, but you could just copy/paste ours and run it just as easy :) | 14:12 |
* tristan tries to disappear again... | 14:12 | |
tristan | jonathanmaw, since you ran into this; it wouldnt be bad to file a bug | 14:19 |
tristan | jonathanmaw, we should probably be able to tell you that it's not going to work at install time | 14:19 |
* tlater understands FUSE now \o/ | 14:19 | |
tristan | tlater, not until you've dug though libfuse C library | 14:20 |
tristan | which is, gross | 14:20 |
* tlater will avoid doing that | 14:20 | |
gitlab-br-bot | buildstream: issue #92 ("buildstream fails and prints an error message from bwrap when run on a system running a kernel lacking CONFIG_USER_NS") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/92 | 14:24 |
tlater | Well, I've confirmed that I'm definitely doing *something* wrong when mounting the way I currently do :) | 14:34 |
tlater | HAHA, I was right! The sandbox is supposed to run in $BUILDDIR/scratch/_/mount | 14:55 |
*** tristan has quit IRC | 15:35 | |
*** adds68 has quit IRC | 15:54 | |
*** adds68 has joined #buildstream | 15:56 | |
*** jonathanmaw has quit IRC | 16:28 | |
*** adds68 has quit IRC | 16:28 | |
*** adds68 has joined #buildstream | 16:28 | |
*** adds68 has quit IRC | 16:30 | |
*** bochecha has quit IRC | 16:45 | |
*** tlater has quit IRC | 17:02 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!