|
From: | Omar Tarabai |
Subject: | Re: GUIX on fedora 14 |
Date: | Wed, 8 Jan 2014 23:15:55 +0100 |
Hello,
Omar Tarabai <address@hidden> skribis:
Right. The original report is at <http://bugs.gnu.org/15209>.
> 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.
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?
> As mentioned by Ludovic in a previous conversation with MatthiasYes. You could comment out the few lines that set up the loopback
> 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
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.
> It seems that for some reason on this system, processes started with rootWhat makes you think so? To me it seems to be about working around the
> privileges does not get the CAP_SYS_ADMIN capability.
assumptions that there’s a separate network interface name space, etc.
I hope this helps. What would be best is to switch to a newer kernel
and libc. :-)
Thanks,
Ludo’.
[Prev in Thread] | Current Thread | [Next in Thread] |