Re: GUIX on fedora 14

[Omar Tarabai]

On Wed, Jan 8, 2014 at 11:39 PM, Ludovic Courtès <address@hidden> wrote:

Omar Tarabai <address@hidden> skribis:

> On Tue, Jan 7, 2014 at 11:55 PM, Ludovic Courtès <address@hidden> wrote:
>
>> Hello,
>>
>> Omar Tarabai <address@hidden> 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 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’.