Hi! On Tue, 2024-06-25 at 09:32:21 -0700, Russ Allbery wrote: > Simon McVittie <s...@debian.org> writes: > > Persisting a container root filesystem between multiple operations comes > > with some serious correctness issues if there are "hooks" that can modify > > it destructively on each operation: see <https://bugs.debian.org/499014> > > and <https://bugs.debian.org/994836>. As a result of that, I think the > > only model that should be used in new systems is to have some concept of > > a session (like schroot type=file, but unlike schroot type=directory) > > so that those "hooks" only run once, on session creation, preventing > > them from arbitrarily reverting/overwriting changes that are subsequently > > made by packages installed into the chroot/container (for example dbus' > > creation of the messagebus uid/gid in #499014, and exim4's creation of > > Debian-exim in #994836). > > I'm not entirely sure that I'm following the nuances of this discussion, > so this may be irrelevant, but I think type=btrfs-snapshot provides the > ideal properties for container file systems. This unfortunately require > file system support and therefore cannot be used unless you've already > embraced a file system with subvolumes, but if you have, you get all of > the speed of a persistent container root file system with none of the > correctness issues, because you get a fresh (and almost instant) clone of > a canonical root file system that is discarded after each build. > > I use that in combination with a cron job to update the source subvolume > daily to ensure that it's fully patched. > > Unfortunately, there's no way that we can rely on this, but it would be > nice to continue to support it for those who are using a supported > underlying file system already.
I manage my chroots with schroot (but not via sbuild, for dog fooding purposes :), and use type=directory and union-type=overlay so that I get a fast and persistent base, independent of the underlying filesystem, with fresh instances per session. (You can access the base via the source:<id> names.) I never liked the type=file stuff, as it's slow to setup and maintain. Regards, Guillem
