feel free to ignore my below input, as i have no intentions of using your debian packages (i backport the official debian package instead), but just to provide an alternate perspective. On Mon, 29 Nov 2010 11:45:02 +0100 Ghislain <gadnet@aqueos.com> wrote: > > > This is a problem with the package util-vserver-basic-debian. If it > > isn't installed on an already existing vserver kernel, it won't work. > > I think Ghislain who builds those packages might be interested in > > sorting that out. > > > > The workaround is to reboot with the new kernel (which installed fine > > for you), then to run > > > > apt-get -f install > > > > to get the utils installed. > > > > Cheers, > > == > > From Ben Green > > yes perhaps i should simply refuse to install on non vserver enabled > kernel. Do you see any useful scenario where the util should install on > a non vserver enabled kernel ? yes: i install debian and later install a vserver-enabled kernel and the utils... but you want me to first install the vserver-enabled kernel, reboot, and then install the utils? > with kernel that are not enable barrier setting fails so don't set the barrier on non-vserver-enabled kernels. /etc/init.d/util-vserver:98 "if [ -e /proc/self/vinfo ]" > and therefor the > user is responsible to create it later why not automate it for the user on every restart (in case the user creates a new guest or moves one since he installed your package and you set the barriers)? /etc/init.d/util-vserver:127-138 # Then set the chroot barrier for vserver in `ls /etc/vservers` do vdiractual=`readlink -f /etc/vservers/$vserver/vdir` if [ -d "$vdiractual" ] then setattr --barrier $vdiractual/.. fi done vrootactual=`readlink -f /etc/vservers/.defaults/vdirbase` setattr --barrier $vrootactual $vrootactual/.pkg $vrootactual/.hash > that seems to me a security issue > as no one will do it . So i think i will simply prevent any install on > non enabled kernels if no one has any other advice on this. i don't disagree that the user will be unlikely to set the barrier(s) himself, so why not do it for him and allow it for non-enabled kernels too, but test for the kernel capability at run-time (otherwise either you blindly assume that the user has a vserver-enabled kernel or you require the user to exclusively use/install your vserver-enabled kernels; both are suboptimal and avoidable). corey -- undefined@pobox.com