Hi,
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 > > 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 > > It seems that for some reason on this system, processes started with root > > privileges does not get the CAP_SYS_ADMIN capability. > > What makes you think so? To me it seems to be about working around the > assumptions that there’s a separate network interface name space, etc. > > Can you elaborate on this point? > I hope this helps. What would be best is to switch to a newer kernel > and libc. :-) > > Unfortunately we are stuck with this for now :( Thanks a lot, Omar > Thanks, > Ludo’. >
