Hi, Currently I am running 2.6.32.43-vs2.3.0.36.29.7 on sparc machine. * umount the /var/lib/vservers - run mkfs.ext3 on the LVM voulme, remount it, create vserver with SECURE_MOUNT SECURE_REMOUNT BINARY_MOUNT in ccapabilities. Start vserver, stop and run vserver name delete got error like I described. Repeat with mkfs.ext4 - still the same cheers On Thu, Aug 25, 2011 at 12:02 PM, Herbert Poetzl <herbert@13thfloor.at>wrote: > On Thu, Aug 25, 2011 at 11:06:29AM +1000, Steve Kieu wrote: > > > Hi, > > > Thanks for reply. Last time I test 2.6.39 something with patch > > and the vserver created can not start (ubuntu 10.10 iwth its > > util-vserver 0.30.216-pre2864-2ubuntu1 ) > > well, 0.30.216-pre2864 is from november 2009, so not really > surprising it doesn't work with a recent kernel (read: > don't bother to test with that :) > > > Not sure it is the bug in the tools or the bug in the patch - I > > did not remember exactly what the error message is though > > > This is critical machine so I could > > not test new kernel on it except the 2.6.32.43-vs2.3.0.36.29.7 > > and it seems still has problem on the sparc kernel build. > > not sure why a critical machine needs an old kernel, but > mainline 2.6.32.43 with vs2.3.0.36.29.7 should be fine for > some testing ... > > > I need SYS_ADMIN as last time I tried to use sshfs inside > > guest the three SECURE_MOUNT, REMOUNT and BINARRY mount > > does not work. > > would be interesting to get an strace of the failing sshfs > mount operation without SYS_ADMIN, but for a first start > I'd try to test with a simple guest without all those > capabilities just to see where the problem comes from > > > Anyway remove SYS_ADMIN and add these three mount option > > - problem still happen. > > > I 'may' have some time to test newer kernel out of working > > hours (probably building first and get the save node down for > > an hour - which one you recommened and nshould I also update > > the util-vserver and build it as well? > > > Debian utils vserver is at 0.30.216-pre2864-2+b2 > > (see comment above) > > in any case, if you do some testing, please recreate the > filesystem where the guests reside and create a new guest > to test with, i.e. do not reuse the existing filesystem > and do not restore/rsync/copy the existing guest, because > if the filesystem attributes got messed up, it won't help > to update kernel or tools > > also note that the debian 2.6.26 kernel is/was severely > broken so all filesystems created with that need some > fixing to get it working again ... > > best, > Herbert > > > cheers > > > On Wed, Aug 24, 2011 at 9:32 PM, Herbert Poetzl > > <herbert@13thfloor.at>wrote: > > >> On Wed, Aug 24, 2011 at 12:48:09PM +1000, Steve Kieu wrote: > >> > >>> Hello everyone, > > >>> As an effort to use sshfs inside guest I added like below > > >>> cat /etc/vservers/devel/ccapabilities SECURE_MOUNT > >>> SECURE_REMOUNT BINARY_MOUNT > > >>> cat /etc/vservers/devel/bcapabilities SYS_ADMIN > > >> why would you give/require SYS_ADMIN? (this basically allows > >> the guest to mess with the host) > > >>> I have not test the sshfs if it works yet, but when starting > >>> the vserver, stop it and try to delete it, I got a whole > >>> binch of error: > > >>> /bin/rm: cannot remove > >>> `/var/lib/vservers/test/var/cache/man/ko/cat1': > >>> Read-only file system /bin/rm: cannot remove > >>> `/var/lib/vservers/test/var/cache/man/ko/cat5': > >>> Read-only file system /bin/rm: cannot remove > >>> `/var/lib/vservers/test/var/cache/man/index.db': Read-only > >>> file system > > >>> The file in /etc/vservers/test is removed cleanly. > > >>> I can only remove the file if I restart the physical host > >>> which is bad. > > >>> Remove SYS_ADMIN - problem is still > > >>> Change the file system mounted at /var/lib/vservers from ext4 > >>> to ext3, still > > >>> Remove the mount option tag - still > > >>> so I am not sure if it is known bug and there is any patch, > >>> any work around for this? > > >>> This is debian 6 system running on sparc machine using > >>> standard debian vserver kernel > > >>> # uname -a Linux XXX 2.6.32-5-vserver-sparc64 #1 SMP Tue Jun > >>> 14 13:58:11 UTC 2011 sparc64 GNU/Linux > > >> please try with a recent kernel, e.g. 2.6.38.8 or even better > >> with a 3.0.x kernel (and the appropriate Linux- VServer patch) > > >> could be a sparc/64 related issue, to me it looks like certain > >> filesystem flags (xattrs) get messed up, but there is no point > >> in testing with a debian kernel > > >> TIA, Herbert > > >>> Many thanks in advance, > > >>> -- Steve Kieu > > > -- Steve Kieu > -- Steve Kieu
On Thu, Aug 25, 2011 at 11:06:29AM +1000, Steve Kieu wrote:well, 0.30.216-pre2864 is from november 2009, so not really
> Hi,
> Thanks for reply. Last time I test 2.6.39 something with patch
> and the vserver created can not start (ubuntu 10.10 iwth its
> util-vserver 0.30.216-pre2864-2ubuntu1 )
surprising it doesn't work with a recent kernel (read:
don't bother to test with that :)
not sure why a critical machine needs an old kernel, but
> Not sure it is the bug in the tools or the bug in the patch - I
> did not remember exactly what the error message is though
> This is critical machine so I could
> not test new kernel on it except the 2.6.32.43-vs2.3.0.36.29.7
> and it seems still has problem on the sparc kernel build.
mainline 2.6.32.43 with vs2.3.0.36.29.7 should be fine for
some testing ...
would be interesting to get an strace of the failing sshfs
> I need SYS ADMIN as last time I tried to use sshfs inside
> guest the three SECURE MOUNT, REMOUNT and BINARRY mount
> does not work.
mount operation without SYS ADMIN, but for a first start
I'd try to test with a simple guest without all those
capabilities just to see where the problem comes from
(see comment above)
> Anyway remove SYS ADMIN and add these three mount option
> - problem still happen.
> I 'may' have some time to test newer kernel out of working
> hours (probably building first and get the save node down for
> an hour - which one you recommened and nshould I also update
> the util-vserver and build it as well?
> Debian utils vserver is at 0.30.216-pre2864-2+b2
in any case, if you do some testing, please recreate the
filesystem where the guests reside and create a new guest
to test with, i.e. do not reuse the existing filesystem
and do not restore/rsync/copy the existing guest, because
if the filesystem attributes got messed up, it won't help
to update kernel or tools
also note that the debian 2.6.26 kernel is/was severely
broken so all filesystems created with that need some
fixing to get it working again ...
best,
Herbert
> cheers
> On Wed, Aug 24, 2011 at 9:32 PM, Herbert Poetzl
> <herbert@13thfloor.at>wrote:
>> On Wed, Aug 24, 2011 at 12:48:09PM +1000, Steve Kieu wrote:
>>
>>> Hello everyone,
>>> As an effort to use sshfs inside guest I added like below
>>> cat /etc/vservers/devel/ccapabilities SECURE MOUNT
>>> SECURE REMOUNT BINARY MOUNT
>>> cat /etc/vservers/devel/bcapabilities SYS ADMIN
>> why would you give/require SYS ADMIN? (this basically allows
>> the guest to mess with the host)
>>> I have not test the sshfs if it works yet, but when starting
>>> the vserver, stop it and try to delete it, I got a whole
>>> binch of error:
>>> /bin/rm: cannot remove
>>> `/var/lib/vservers/test/var/cache/man/ko/cat1':
>>> Read-only file system /bin/rm: cannot remove
>>> `/var/lib/vservers/test/var/cache/man/ko/cat5':
>>> Read-only file system /bin/rm: cannot remove
>>> `/var/lib/vservers/test/var/cache/man/index.db': Read-only
>>> file system
>>> The file in /etc/vservers/test is removed cleanly.
>>> I can only remove the file if I restart the physical host
>>> which is bad.
>>> Remove SYS ADMIN - problem is still
>>> Change the file system mounted at /var/lib/vservers from ext4
>>> to ext3, still
>>> Remove the mount option tag - still
>>> so I am not sure if it is known bug and there is any patch,
>>> any work around for this?
>>> This is debian 6 system running on sparc machine using
>>> standard debian vserver kernel
>>> # uname -a Linux XXX 2.6.32-5-vserver-sparc64 #1 SMP Tue Jun
>>> 14 13:58:11 UTC 2011 sparc64 GNU/Linux
>> please try with a recent kernel, e.g. 2.6.38.8 or even better
>> with a 3.0.x kernel (and the appropriate Linux- VServer patch)
>> could be a sparc/64 related issue, to me it looks like certain
>> filesystem flags (xattrs) get messed up, but there is no point
>> in testing with a debian kernel
>> TIA, Herbert
>>> Many thanks in advance,
>>> -- Steve Kieu
> -- Steve Kieu