On Monday 11. December 2017 12.03.56 Ludovic Courtès wrote: > > Paul Boddie <[email protected]> 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! Paul
