From: Fran Firman (fran_at_netgate.net.nz)
Date: Sun 15 Dec 2002 - 23:11:46 GMT
It seems to be related to that the folder /vservers is an nfs mount.
When I have it on the local HD, every thing works ok, but not via the
nfs mount.
This is using the tared kernal on the vserver site, and the rpm
(aliened) to deb from the site.
server4:/usr/sbin# vserver knottsberry start
Starting the virtual server knottsberry
Server knottsberry is not running
Cding to the folder /vservers/knottsberry
/vservers/knottsberry
ipv4root is now 210.54.14.137
Host name is now knottsberry
New security context is 3
Can't chroot to directory . (Permission denied)
On Fri, 2002-12-13 at 15:39, Paul Sladen wrote:
> On 13 Dec 2002, Fran Firman wrote:
>
> Hi Fran,
>
> > Just upgraded to 2.4.19ctx-15 and vserver 0.22
> > Can't chroot to directory . (Permission denied)
>
> The code the prints this is in `capchroot.cc' source: (shown reformatted)
>
> if (chroot (argv[dir]) == -1)
> fprintf (stderr,
> "Can't chroot to directory %s (%s)\n",
> argv[dir],
> strerror(errno));
>
> By the time this is called, the `vserver start' has already changed to the
> correct directory: (this is from the "vserver" command)
>
> # We switch to $VSERVER_ROOT/$1 now, because after the
> # security context switch $VSERVER_ROOT directory becomes a
> # dead zone.
> cd $VSERVER_ROOT/$1
> [...]
> $NICECMD $CHBIND_CMD $SILENT $IPOPT --bcast $IPROOTBCAST \
> $CHCONTEXT_CMD $SILENT $DISCONNECT $CAPS $FLAGS
> $CTXOPT $HOSTOPT $DOMAINOPT --secure \
> $SAVE_S_CONTEXT_CMD /var/run/vservers/$1.ctx \
> $CAPCHROOT_CMD $CHROOTOPT . $STARTCMD
> -----------^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> One thing you could try for testing, is adding a `pwd' just above this to
> find out which directory is it trying to change into and whether it managed.
>
> > This is on a debian host.
>
> Are you using a packaged version, or the source tarball? (Not that I
> believe this is relevant).
>
> > With 2.4.19ctx-13 and vserver 0.21 everything seems to be ok.
>
> [Apologies for asking]. Could you try patching the `ctx-13' against
> *exactly* the same kernel as `ctx-15' didn't work against, rather than
> comparing it to a working kernel that's probably a few weeks old.
>
> What I'm wondering is whether it is the main kernel tree that you have
> compiled against, rather than the patches that is causing the problem.
>
> Also do you get this problem when using `ctx-13' with `vserver-0.22'.
> Note: that the userspace is backwards compatible, but kernel-side is not.
>
> Hope this helps,
>
> -Paul