Paul Boddie <[email protected]> skribis: > 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!
Great that you found out! Ludo’.
