Re: GUIX on fedora 14

[Omar Tarabai <tarabai@devegypt.com>]

[-- Attachment #1: Type: text/plain, Size: 2343 bytes --]

Hi,


On Tue, Jan 7, 2014 at 11:55 PM, Ludovic Courtès <ludo@gnu.org> wrote:

> Hello,
>
> Omar Tarabai <tarabai@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’.
>

[-- Attachment #2: Type: text/html, Size: 3769 bytes --]