On Fri, Aug 26, 2011 at 08:25:10PM +1000, Steve Kieu wrote: > By the way the kernel is: > # uname -a > Linux seaspray.m5.local 2.6.32.43-vs2.3.0.36.29.7 #1 SMP Wed Aug 24 16:06:37 > EST 2011 sparc64 GNU/Linux > vserver util is standard debian. please update to something recent and try again, it might be that the debian util-vserver doesn't even create a proper guest environment TIA, Herbert > On Fri, Aug 26, 2011 at 8:24 PM, Steve Kieu <msh.computing@gmail.com> wrote: >> OK I tried to umount the volue, mkfs.ext3 on it, mount it again with option >> tag removed. crate a test vserver with these MOUNT flags in ccapabilities >> and strat it, stop and delete, got error. I ran strace rm -f a file inside >> the vserver dir and capture its output attached. >> No speacial erroe at dmesg and message at all. The error message when >> running vserver delete is just thousand of lines like this >> remove `/var/lib/vservers/test/sbin/udevadm': Read-only file system >> I found that if I unmount the /var/lib/vservers and then mount it again, >> and I am able to remove the directory. so do not need to reboot the whole >> server to do that >> cheers >> On Thu, Aug 25, 2011 at 10:30 PM, Herbert Poetzl <herbert@13thfloor.at>wrote: >>> On Thu, Aug 25, 2011 at 10:15:24PM +1000, Steve Kieu wrote: >>>>> an what happens when you do not give those ccapabilities? >>>> without these, it behaves normally - delete fine, no problem so >>>> far. It only happens in sparc , not in x86 and x86_64. >>> that would suggest that something inside the guest >>> happens which requires those ccapabilities >>> any idea what that could be on a 'normal' guest >>> start? >>>>> could you upload the entire log for that and keep the >>>>> resulting filesystem for further investigation? >>>> I will try tomorrow with ext3. Have migrated all vs into >>>> another host so it can be free to experiment. >>>> What log are you talking about? dmesg log or kernel.log. >>> the log of your guest start/stop and the errors you >>> get (basically a copy of the shell input/output) >>> but of course, if you get some output in dmesg, >>> please add that as well >>>> Should I strace it when >>>> I do a rm -rf /var/lib/vservers/NAME? >>>> (after vserver NAME delete failed, I tried to manually >>>> rm -rf it and same error. >>> yes, please do so, from the information you provided >>> so far, it sounds like something inside the guest is >>> either modified or mounted (in some strange way) so >>> this information could be quite helpful >>>> I can work around this limitation after all we I hit the brick >>>> wall - will sshfs mount from the host through vserver fstab >>>> which will work fine I guess.It might even be better solution >>>> in terms of security; vserver is still only virtualization for >>>> sparc for now (lxc is still far more unstable in my test). so >>>> it is good if this can be fixed. >>> I'm pretty sure we can identify the issue and if it is >>> actually Linux-VServer related we will fix it :) >>> best, >>> Herbert >>> PS: if you have some time for interactive testing, you >>> could pay a visit to the IRC channel and look for Bertl >>>> Thanks, >>>>> Repeat with mkfs.ext4 - still the same >>>>> let's stick with ext3 for now, that's easier to debug :) >>>> -- Steve Kieu >> -- >> Steve Kieu > -- > Steve Kieu