* Tong Sun wrote in grml's BTS on 20100610 / 00:39:

> > But AFAIK grml-chroot isn't yet reliable enough to be able to deal
> > with several instances of grml-chroot at the same time. So this
> > would be an option as soon as grml-chroot provides a stable
> > mechanism/feature for that.

> Having thinking it over again, I now think the best approach is to create a
> function file in  grml-scripts package, say,

> /usr/share/grml-scripts/functions/grml-chroot

> and move all chroot related common functions from grml-chroot and
> grml-debootstrap in there (even we have two set of duplicated
> functionality), then make grml-debootstrap depends on grml-scripts.

> So the integration can happen gradually. Because the integration involves
> only a single file, it is much easy to manage and track.

> How is that?

I don't see the benefit for now. The chroot stuff isn't rocket
science and adding additional depends just increases risk of
breaking stuff.

If grml-chroot can be used without any possible problems I'm fine
with providing grml-chroot as separate package and using that for
grml-debootstrap, but for now I don't think it's worth all the
effort.

Gebi, ACK from your side?

regards,
-mika-

On Wed, Jun 9, 2010 at 6:51 AM, Michael Prokop <bts@bts.grml.org> wrote:

>
> > I believe that the chroot part in grml-debootstrap and grml-chroot share
> a good
> > portion of common ground in preparing chroot, and restoring it. So would
> it a
> > good idea to split out chroot part of grml-debootstrap into grml-chroot,
> so that
> > we have a single code base to maintain/enhance?
>
> Nice idea!
>
> But AFAIK grml-chroot isn't yet reliable enough to be able to deal
> with several instances of grml-chroot at the same time. So this
> would be an option as soon as grml-chroot provides a stable
> mechanism/feature for that.
>

Having thinking it over again, I now think the best approach is to create a
function file in  grml-scripts package, say,

/usr/share/grml-scripts/functions/grml-chroot

and move all chroot related common functions from grml-chroot and
grml-debootstrap in there (even we have two set of duplicated
functionality), then make grml-debootstrap depends on grml-scripts.

So the integration can happen gradually. Because the integration involves
only a single file, it is much easy to manage and track.

How is that?

* Tong Sun wrote in grml's BTS on 20100606 / 05:08:

> I believe that the chroot part in grml-debootstrap and grml-chroot share a good
> portion of common ground in preparing chroot, and restoring it. So would it a
> good idea to split out chroot part of grml-debootstrap into grml-chroot, so that
> we have a single code base to maintain/enhance? 

Nice idea!

But AFAIK grml-chroot isn't yet reliable enough to be able to deal
with several instances of grml-chroot at the same time. So this
would be an option as soon as grml-chroot provides a stable
mechanism/feature for that.

Gebi - IIRC same for you, am I right?

regards,
-mika-

Hi, 

I believe that the chroot part in grml-debootstrap and grml-chroot share a good
portion of common ground in preparing chroot, and restoring it. So would it a
good idea to split out chroot part of grml-debootstrap into grml-chroot, so that
we have a single code base to maintain/enhance? 

If OK, I'd like to take the first stab,

. do the porting/testing
. add parameter handling to grml-chroot so that 

  grml-chroot --grml-debootstrap os_root

will do the jobs originally in grml-debootstrap.

OK? If so, I'd also like to add another parameter --force-unload to do the
following conditionally:

diff --git a/usr_sbin/grml-chroot b/usr_sbin/grml-chroot
index eb9cefc..bce9c50 100755
--- a/usr_sbin/grml-chroot
+++ b/usr_sbin/grml-chroot
@@ -56,7 +56,7 @@ function mountit
 function umount_all
 {
    for i in $MOUNTED_; do
-        umount "${DEST_}/$i"
+        umount "${DEST_}/$i" || umount -l "${DEST_}/$i"
    done
 }