2006/1/13, Jens Holze <email@example.com>:
> 2006/1/11, Herbert Poetzl <firstname.lastname@example.org>:
> > On Wed, Jan 11, 2006 at 04:03:58PM +0100, Jens Holze wrote:
> > > Hi!
> > >
> > > I updated VServer from 2.00 to 2.01 by patching a new 220.127.116.11-kernel
> > > and installing the utils (209) from self-build rpms on Fedora Core 4.
> > maybe the installation of your 'self built' utils is a
> > little incomplete ... I'd try with the source tar, and
> > after a proper configuration (to get your pathes right)
> > do the 'make install' and 'make install-distribution'
> I erased the rpms and installed from source (with the prefix=/).
> Everything is in place now, save_ctxinfo in /lib/util-vserver/ .
> > > Everything worked prior to that but since then I can't manage to start
> > > any debian-based Vservers. I thought something with the kernel went
> > > wrong so I build it anew but that didn't solve anything.
> > > When trying to start a vserver I get:
> > >
> > > // RTNETLINK answers: File exists
> > this means that the 'configured' IP(s) already exists,
> > maybe with a different netmask/prefix, check with
> > 'ip addr ls' and remove the 'offending' IP(s)
> Yeah I know, this one is not the problem, I just took existing
> settings and made a new server from it hoping that would eliminate the
> save_ctxinfo problem...
> > > // save_ctxinfo: execv(): No such file or directory
> > this very much looks like the save_ctxinfo is failing
> > possible reasons could be:
> > - /lib/util-vserver/save_ctxinfo (or wherever it is
> > on your distro) is not executable or missing
> > - /etc/vservers/.defaults/run.rev is not pointing
> > to a valid directory to store the info
> > - the directory /var/run/vservers.rev is not writeable
> > or does not exist
> I thought so but: save_ctxinfo is at the exact location and
> executable... /run.rev is there and pointing to /var/run/vservers.rev
> which exists and is writeable (there are directories inside for the
> fedora vservers which are running!). It must be something special that
> is done in debian vservers which doesn't happen with fedora core
> Also, I wonder where the vserver starting script looks for this file,
> is it possible that I have to edit any config file? I mean it's in the
> same directory so why doesn't he find it?
> > > // An error occured while executing the vserver startup sequence; when
> > > // there are no other messages, it is very likely that the init-script
> > > // (/etc/init.d/rc 3) failed.
> > > //
> > > // Common causes are:
> > > // * /etc/rc.d/rc on Fedora Core 1 and RH9 fails always; the 'apt-rpm' build
> > > // method knows how to deal with this, but on existing installations,
> > > // appending 'true' to this file will help.
> > > //
> > > // Failed to start vserver 'debian_two'
> > >
> > > The common causes don't really help and I can't think of anything
> > > else. I even build an all new debian vserver but even this one doesn't
> > > boot. Other (Fedora-based) vservers do work perfectly. Any help would
> > > be greatly appreciated.
> > yes, well, to explain all kinds of errors in a tool
> > of this complexity is almost impossible ...
> Of course it is, it's just that its obviously a different problem as
> far as I get it.
> > HTH,
> > Herbert
> > >
> > > Jens
> > > _______________________________________________
> > > Vserver mailing list
> > > Vserver@list.linux-vserver.org
> > > http://list.linux-vserver.org/mailman/listinfo/vserver
I had an intense look at the installation since obviously something
must have gone wrong there (as you pointed out, too). I checked for
vprocunhide being in place and executed (which is the case) and then
ran the testme.sh once more where I first got an error with chcontext
in /usr/sbin/chcontext. There should be no such file since I erased
those with rpm and then installed from source to
/(etc,lib/util-verser,sbin). That drew my attention to the fact that
obviously some files of the prior rpm installation remained on the
system and I wondered whether that causes the problem (allthough I
still wonder why it only happens with debian based vservers). After I
deleted the redundant chcontext the testme.sh found no error at all.
Then I deleted /usr/sbin/vserver presuming that /sbin/vserver should
be used. However, the problem remained, the servers fail to boot while
directories for their context are created under /var/run/vservers.rev
and the run files do point to the respective files in
/var/run/vservers as if the servers actually were running. Maybe he's
looking for the save_ctxinfo in all the wrong places?
I'm sure it's just some really stupid tweak I simply couldn't think of
yet. Any other suggestions?
Vserver mailing list
Received on Wed Jan 25 11:46:23 2006