I would like to switch from pbuilder/cowbuilder to schroot/sbuild but
the lack of easy copy-on-write support in sbuild is blocking this. It
would be nice if sbuild supported that. It would be nice if sbuild
supported both of these mechanisms for copy-on-write:

      * overlayfs: this is planned to be merged into Linux 3.10
      * cowdancer: this is what cowbuilder uses

I would really like to see pbuilder/sbuild unified and this is one step
towards that long-term goal.

I looked at cowdancer in the past, and IIRC it was too fragile to
implement safely--it requires the use of LD_PRELOAD and this can
break things, and it also breaks a number of sbuild use cases
including non-native arch building using binfmt and qemu.  It
makes assumptions about the chroot environment which may not
always be true.

Note that schroot already supports a number of copy-on-write solutions
including:
 - aufs
 - unionfs
 - btrfs snapshots
 - lvm snapshots
And I'll be happy to add overlayfs support once it's available.  If
you have an existing chroot, making it use aufs/unionfs is just a 1-2
line addition to your configuration.  I would suspect that we can
make it use overlayfs using the same infrastructure--it'll just need
teaching about the new filesystem type.

I can revisit the cowdancer support when I have a bit more time;
if things have changed or my understanding is wrong I'm happy to
be corrected.


Regards,
Roger

Hasn't overlayfs support been in schroot since 1.5.2-1 (May 2012)? I don't
think any more support is needed on the sbuild side. Ubuntu seems to be
making active use of overlayfs chroots -- mk-sbuild from ubuntu-dev-tools
0.136 (November 2011) onwards makes them, and they carry no patches to
schroot and no relevant patches to sbuild.

All you need a kernel with overlayfs support. Ubuntu's been carrying the
patchset out of tree for a while.

(I was pretty sure I'd _used_ overlayfs chroots, so I was surprised by the
implication that it doesn't work yet...)


By the way, regarding cowdancer and LD_PRELOAD, I semi-recently learned
about fakeroot-ng, which implements fakeroot using ptrace instead of
LD_PRELOAD and is therefore more reliable. I wonder if the same approach
could be applied to cowdancer. (I've long wanted a "fakeschroot" that
doesn't require elevated privilege in order to build things....)

Yes, you're correct, I'd forgotten it was already added--it's not
a feature I use myself very often.

If such a thing is possible, that would be very interesting.  I
don't think I'll have time to look at it myself in the near
future, but I'd certainly support any work on it.  Removing all
need for root privileges for sbuild would be a great achievement;
I'd certainly be happy to remove the need for root in the build
chroot.


Regards,
Roger

I wasn't aware sbuild had copy-on-write support since the default seems
to be non-cow chroots. The existing cow support methods aren't useful to
me though, I don't have a new enough kernel for overlayfs yet, don't use
btrfs and don't want to use lvm snapshots.

I've been using cowbuilder for years and never had a problem with it. In
practice the LD_PRELOAD thing appears to work fine. A ptrace based
cowdancer sounds good, I wonder where the best place for the code is
though, maybe in schroot itself or just in cowdancer? Probably this
should be discussed with the maintainer.

Roger Leigh <rleigh@codelibre.net> writes:

Might be nice if the "type=" description in schroot.conf referenced the
"filesystem union chroot" options section as applying to "directory"
chroots?  They sound rather unappealing compared to the snapshot options
there.
of any given process.  This would make it tricky to allow using more
than one such tool at a time: for this to work, either the tools would
all need to be in league, or the outer tools would all have to emulate
ptrace() in addition to fulfilling their actual purposes.

I suppose it's a bit of work to make LD_PRELOAD-based tools play nicely
others that override the same symbols, but emulating ptrace() using
ptrace() is not my idea of a good time.

(Also, I can't help but wonder about the performance cost of having TWO
ptrace stops for *every* syscall in *every* inferior process, and it
just gets worse with the ptrace() emulation ...)

Also note that some packages, like gdb for example, have rather good
reason to use ptrace() themselves during the build.  (Say, running the
testsuite.)

Just to be sure.  Are you referring to the examples in the template
schroot.conf that's installed by default?  This is a bit outdated
and doesn't cover everything; if you wish to provide an update for
it that would be appreciated.


Regards,
Roger