Re: Bootstrapping on a new platform

[ludo@gnu.org (Ludovic Courtès)]

Paul Boddie <paul@boddie.org.uk> skribis:

> On Monday 11. December 2017 12.03.56 Ludovic Courtès wrote:
>> 
>> Paul Boddie <paul@boddie.org.uk> skribis:
>> > This resembling what I showed before. Meanwhile in the child process log
>> > (/tmp/guix.797) the clone call with EINVAL is this one:
>> > 
>> > clone(child_stack=0xbffedfa4,
>> > flags=CLONE_NEWNS|CLONE_NEWUTS|CLONE_NEWIPC|
>> > CLONE_NEWPID|CLONE_NEWNET|SIGCHLD) = -1 EINVAL (Invalid argument)
>> > 
>> > Again, this is using the 4.9.67 kernel.
>> 
>> This suggests that namespaces are not fully supported with this kernel.
>> The clone(2) page has this:
>> 
>>    EINVAL CLONE_NEWIPC  was specified in flags, but the kernel was not
>> configured with the CONFIG_SYSVIPC and CONFIG_IPC_NS options.
>> 
>>    EINVAL CLONE_NEWNET was specified in flags, but the kernel  was  not 
>> configured  with  the  CONFIG_NET_NS option.
>> 
>>    EINVAL CLONE_NEWPID  was  specified  in  flags,  but  the kernel was not
>> configured with the CONFIG_PID_NS option.
>> 
>>    EINVAL CLONE_NEWUTS was specified in flags, but the kernel was not
>> configured with the CONFIG_UTS option.
>> 
>> Could it be one of these?
>
> I ran "make menuconfig ARCH=um" and saw that "User namespace" and "PID 
> Namespaces" were not enabled. So I enabled them, rebuilt the kernel, and then 
> ran the User Mode Linux instance again.
>
> This time, it would appear that running the daemon and then running a build 
> command gets the daemon to do some work. There have been some problems with 
> hashes, as reported before, but the problem with clone seems to have been 
> solved.
>
> Sorry for the noise, but I guess this is what happens when someone tries to do 
> things the hard way. Thanks for identifying the cause of the problem!

Great that you found out!

Ludo’.