On Thu, Aug 25, 2011 at 04:24:00PM +1000, Steve Kieu wrote: > 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. an what happens when you do not give those ccapabilities? > Start vserver, stop and run vserver name delete > got error like I described. could you upload the entire log for that and keep the resulting filesystem for further investigation? > Repeat with mkfs.ext4 - still the same let's stick with ext3 for now, that's easier to debug :) TIA, Herbert > 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