On Sat, Nov 3, 2012 at 6:01 PM, Roger Leigh <rle...@codelibre.net> wrote:
> On Thu, Nov 01, 2012 at 04:38:09PM +0100, Reinhard Tartler wrote:
> > On Thu, Nov 1, 2012 at 3:34 PM, Reinhard Tartler <siret...@gmail.com>
> wrote:
> >
> > >
> > > Nevertheless, I've also implemented another approach, which uses the
> host
> > > automount binary. I did not test the script extensively, but it seems
> to
> > > work as a proof of concept on both schroot 1.4 and schroot 1.6
> branches.
> > > I'm sure that it could be greatly simplified with some little changes
> to
> > > automount and schroot, but it should be good enough to demonstrate the
> > > idea. Please find that script, 71automount, attached to this email and
> > > share your thoughts about this.
> > >
> > >
> > It seems that 71automount alone is enough to break the --recover-session
> > option, because 10mount fails to umount and mount all filesystems again.
> In
> > order to fix this, I think that in the recover session case, a setup.d
> > script must ensure that automount is properly killed. The attached
> > 01automount files implements this.
> >
> > Roger, please tell me if this approach makes sense to you and what is
> > missing so that these two scripts can be integrated into the schroot
> > package properly.
>
> Hi,
>
> I'm afraid I'm not an autofs expert by any means, so I can't give great
> feedback here. Some questions:
>
> - what creates the new autofs map? And what is it based upon?
>
71automount creates the new autofs map based on the contents of
/etc/auto.master
- does this require any autofs-related stuff installed in the chroot,
> or is it only required on the host?
>
No, the presented script uses everything from the host, so nothing
autofs-related is used nor required in the chroot
> - what is this code actually for? Sorry for being uninformed here, but
> I'm not sure I understand what the use case is for this. An example
> would help.
>
In my scenario, /home is on NFS. Without those scripts, I end up with an
empty home. Also, we additionally export and mount some additional shares
in /proj and /local.
> - does this make rbind work again? Or is this a separate issue?
>
It is a workaround because rbind breaks autofs. If rbind work, this
workaround would be unnecessary.
--
regards,
Reinhard
