Re: [vserver] VServer on armel architecture

Hi,

Jakob Lell wrote:
> Hi,
>
> I am trying to get vserver work on the armel architecture. The hardware
> used is a Marvell SheevaPlug with Debian Squeeze.
>
> The first step was to compile the kernel. This only required adding one
> missing "#include <linux/vs_memory.h>" to arch/arm/include/asm/tlb.h
> after the line " #else /* !CONFIG_MMU */". With this small fix, the
> kernel compiles and boots without any errors.
>
> The next thing to do is the userspace utility. The main problem here is
> that the ABI for calling linux system calls has changed. I've attached a
> patch which fixes this with an appropriate #ifdef. The program compiles
> fine with this patch and system calls seem to work. Since dietlibc is
> not yet working on armel, I had to compile util-vserver with glibc. I
> could already create a new vserver using the following command (before
> doing /etc/init.d/util-vserver start):

Thanks for the patch, will apply.

> vserver test build -m debootstrap --hostname test --rootdir /mnt/stick/
> --interface eth0:192.168.1.21/24 -- -d lenny
>
> However, starting the vserver using "vserver test start" fails with the
> following error message:
> /proc/uptime can not be accessed. Usually, this is caused by
> procfs-security. Please read the FAQ for more details
> http://linux-vserver.org/Proc-Security

Right, you need vprocunhide.

> After running "/etc/init.d/util-vserver start", trying to start the
> vserver using "vserver test start" fails with a different error message:
> vspace: clone(): No space left on device
>
> Here is the strace output line of the failing clone system call:
> clone(child_stack=0, flags=CLONE_VFORK|CLONE_NEWNS|SIGCHLD) = -1 ENOSPC
> (No space left on device)

Is CONFIG_CGROUP_NS enabled in your kernel?

> Some debugging in /etc/init.d/util-vserver showed that this problem
> occurs after running the mount_cgroup function. Have you got any hints
> about how to resolve this problem?
>
> I've now finally found a workaround: When running
> "/etc/init.d/vprocunhide start" and not "/etc/init.d/util-vserver
> start", it is possible to start and use the vserver. When doing so, the
> clone system call works successfully even though it uses exactly the
> same parameters as the failing call above:
> clone(child_stack=0, flags=CLONE_VFORK|CLONE_NEWNS|SIGCHLD) = 7149
>
> Regards
> Jakob Lell

-- 
Daniel Hokka Zakrisson