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
Received on Fri Aug 26 12:45:11 2011