Re: Replacing aufs with overlayfs
Hi Debian Kernel Team,
intrigeri (2014-12-11):
> Ben Hutchings wrote (09 Dec 2014 19:55:10 GMT) :
>> Please try the Linux 3.18 packages from experimental (they're not there
>> yet, but should be soon) and check that overlayfs does what you need.
>
> Thanks. I'll test it for Tails' usecases (that use aufs a bit more
> than most other live systems, e.g. our incremental upgrades features
> uses it) once I find the time to.
It took us a while, but I'm happy to report that Tails has finally
migrated away from aufs! So as far as Tails is concerned, we don't
need the aufs "compat" patchset in src:linux anymore :)
In passing, so that I can call "case closed" some of the blockers that
were discussed later on this thread back in 2014-2015:
1. overlayfs stack depth upper limit vs. live-boot SquashFS stacking feature
It turns out that was a misunderstanding: that upper limit applies
to how many overlayfs filesystems can be part of a new overlayfs
mount, rather than to how many read-only lower layers it's
built from.
2. overlayfs vs. AppArmor
It's still true that out-of-the-box, just like aufs, overlayfs does
not play well with AppArmor. That's why apparmor.service turns
itself into a no-op when it detects a Debian or Ubuntu Live system.
To make them work together, one solution is to add a few AppArmor
`alias` rules, and to add the `attach_disconnected` flag to every
profile. For example:
- https://salsa.debian.org/tails-team/tails/-/blob/master/config/chroot_local-includes/etc/apparmor.d/tunables/alias.d/tails
- https://salsa.debian.org/tails-team/tails/-/blob/master/config/chroot_local-hooks/48-tweak-AppArmor-profiles
- https://tails.boum.org/contribute/design/application_isolation/
Cheers!
Reply to: