On Wed, Jan 8, 2014 at 11:39 PM, Ludovic Courtès <l...@gnu.org> wrote:
> Omar Tarabai <tara...@devegypt.com> skribis: > > > On Tue, Jan 7, 2014 at 11:55 PM, Ludovic Courtès <l...@gnu.org> wrote: > > > >> Hello, > >> > >> Omar Tarabai <tara...@devegypt.com> skribis: > >> > >> > I have Guix 0.5 installed on a fedora 14, 2.6.32 kernel. > >> > > >> > Running the following: > >> > guix package --verbose -i tar > >> > > >> > I get the error: > >> > guix package: error: build failed: unable to fork: Operation not > >> permitted > >> > > >> > I traced the error to the clone() operation in build.cc. > >> > >> Right. The original report is at <http://bugs.gnu.org/15209>. > >> > >> However, CLONE_NEWNET & co. appeared in 2.6.24 according to clone(2), so > >> this kernel should have them. Perhaps the libc headers lack the > >> definitions; could you check if they’re in /usr/include/bits/sched.h? > >> What libc version is it? > >> > >> > > They are all there in /usr/include/bits/sched.h, libc version 2.13 > > OK. > > >> > As mentioned by Ludovic in a previous conversation with Matthias > >> > Wachs, it seems to be a problem of a missing capability CAP_SYS_ADMIN. > >> > I tried running the daemon as root only or with > >> > --build-users-group=guix-builder but I get the same error. I also > >> > tried isolating the clone operation in a test script to verify the > >> > problem, fails again (running as root). > >> > > >> > I tried removing all the CLONE_* flags as recommended by Ludovic, I > get > >> the > >> > error: > >> > build error: cannot set loopback interface flags: Permission denied > >> > > >> > I assume its because of the missing CLONE_NEWNET > >> > >> Yes. You could comment out the few lines that set up the loopback > >> interface in build.cc, line 2074 onwards. The global ‘lo’ interface > >> will be visible in the build environment anyway. > >> > >> Let us know how far that gets. > >> > >> > > Now I get the error: > > build error: unable to make filesystem `/' private: Operation not > permitted > > That’s mount(2) with MS_PRIVATE failing here. I don’t see why it would > fail this way as root. > > According to capabilities(7), CAP_SYS_ADMIN does indeed allow use of the > CLONE_ flags. So I understand now why you were mentioning it as a > possible cause. > > Could you try to set that capability on the guix-daemon file with the > ‘setcap’ command? > > No luck with setcap either. Its possible that since planetlab nodes we are using are running on linux-vservers <http://www.linux-vserver.org/Paper>which is an operating system-level visualization and perhaps it applies some restrictions on the user capabilities to prevent applications from escaping the VM, we will have to look more into that. Anyway, thanks a lot for your support. > Thanks, > Ludo’. >
