On Mon, 2011-07-18 at 07:31 -0500, Serge E. Hallyn wrote:
> Quoting Michael H. Warfield (m...@wittsend.com):
> > Unfortunately, I also still find that if there's a -o remount,ro in the
> > halt/reboot script, it still sets /dev/pts to ro and that still
> > propagates to the host and to the other containers triggering random
>
> Wow.
>
> Did a quick grep; is there any reason why lxc-start doesn't turn on
> MS_SLAVE for the client's root? Something like:
>
> From 7fbc3ec940403605c53b253d8630c3f47fad154c Mon Sep 17 00:00:00 2001
> From: Serge Hallyn <serge.hal...@ubuntu.com>
> Date: Mon, 18 Jul 2011 07:29:57 -0500
> Subject: [PATCH 1/1] (untested) turn container rootfs into MS_SLAVE
>
> Signed-off-by: Serge Hallyn <serge.hal...@ubuntu.com>
> ---
> src/lxc/conf.c | 5 +++++
> 1 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/src/lxc/conf.c b/src/lxc/conf.c
> index 2eb598b..d36fe47 100644
> --- a/src/lxc/conf.c
> +++ b/src/lxc/conf.c
> @@ -732,6 +732,11 @@ static int setup_rootfs(const struct lxc_rootfs *rootfs)
> return -1;
> }
>
> + if (mount(rootfs->path, rootfs->path, "none", MS_SLAVE, 0)) {
> + ERROR("failed to turn child rootfs into slave");
> + return -1;
> + }
> +
> DEBUG("mounted '%s' on '%s'", rootfs->path, rootfs->mount);
>
> return 0;
> --
> 1.7.4.1
Problem...
lxc-start 1311083210.678 ERROR lxc_conf - failed to turn child rootfs
into slave
lxc-start 1311083210.678 ERROR lxc_conf - failed to setup rootfs for
'Alcove'
lxc-start 1311083210.678 ERROR lxc_start - failed to setup the
container
lxc-start 1311083210.679 ERROR lxc_sync - invalid sequence number 1.
expected 2
lxc-start 1311083210.679 ERROR lxc_start - failed to spawn 'Alcove'
This may be do to the way I have my rootfs set up. Mine are bind mounts
from a private area to the common mount point. I've noticed that inside
the containers, I see my root file system show up twice like this (over
on one of my production machines):
[mhw@Berserker ~]$ df
Filesystem 1K-blocks Used Available Use% Mounted on
rootfs 480719056 404550544 51749312 89% /
/dev/sdb1 480719056 404550544 51749312 89% /
/dev/sdc1 480719056 202816 456097040 1% /export
/dev/sda7 693727244 624715768 33772100 95% /srv/shared
none 1030612 0 1030612 0% /dev/shm
[mhw@berserker-base ~]$ cat /srv/lxc/config/Berserker.fstab
/srv/lxc/private/Berserker /srv/lxc/rootfs none bind 0 0
/export /srv/lxc/rootfs/export none bind 0 0
/home/shared /srv/lxc/rootfs/srv/shared none bind 0 0
Maybe not such a good idea (mine)?
Regards,
Mike
> > The kernel should also prohibit, totally, the propagation of remount
>
> The kernel doesn't know about containers, so it's up to userspace :)
>
> -serge
>
--
Michael H. Warfield (AI4NB) | (770) 985-6132 | m...@wittsend.com
/\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it!
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------------ Magic Quadrant for Content-Aware Data Loss Prevention Research study explores the data loss prevention market. Includes in-depth analysis on the changes within the DLP market, and the criteria used to evaluate the strengths and weaknesses of these DLP solutions. http://www.accelacomm.com/jaw/sfnl/114/51385063/
_______________________________________________ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
