[Buildroot] [PATCH 0/6 v3] systemd: sort out the conflict between var factory and tmpfiles

[Norbert Lange]

Am Di., 18. Okt. 2022 um 21:43 Uhr schrieb <yann.morin at orange.com>:
>
> Hello All!
>
> This six-patch series touches on the delicate intricacies of the systemd
> package and how we integrate it in Buildroot, especially with regard to
> read-only filesystems.
>
> The underlying issue is that systemd wants a writable /var filesystem
> (it will store a bunch of things at runtime in there). A lot of packages
> also expect a writable /var.
>
> The solution we implemented in Buildroot is to generate a factory for
> /var, and register that as tmpfiles, at build time, and mount a tmpfs on
> the then-empty /var at runtime, so that systemd-tmpfiles populates /var
> on boot. Having a tmpfs means /var is repopulated from a clean state at
> each boot, and people who want a persistent /var have to provide their
> own mechanism to mount their actual filesystem instead.
>
> However, for some people, this does not seem to work as expected, so we
> introduced a call to systemd-tmpfiles at build time, to pre-populate the
> rootfs from all the tmpfiles, of which our var factory, at build time,
> entirely leaving them the reponsibility to make /var read-write.
>
> These two mechanisms clash with each others; they do not prevent a
> system from booting, but they cause files to be duplicated between the
> factory and the pre-populated /var.
>
> To solve the issue, this series introduces new options, so the user can
> elect to use either, none, or both mechanisms, as they see fit.
>
> The first two patches make it easier to change the location where /var
> is nounted from, by making it a systemd mount unit, rather than use the
> legacy fstab, and move the factory to /usr/share as it is a system
> factory (/etc is for the administartor to provide overrides).
>
> Then we move together the two mechanisms under the auspices of a common
> package, to make it easier to later make them conditional.
>
> Then we introduce those two new options, that drive each mechanism. We
> make sure the behaviour so far is kept, for those who have setups that
> are functional as is.
>
> Eventually, we add a new way to provide a writable /var, which uses a
> pre-populated /var on which an tmpfs is overlayed with an overlayfs.
> This new feature still uses a tmpfs as the writable part, and like for
> the factory case, leaves to the user the responsiility to provide for a
> persitent filesystem should they need one.
>
> This series would not have been entirely possible without the input from
> Norbert, who provided the basis for the overlayfs-based solution.
> Thanks!
>
> Changes v2 -> v3:
>   - introduce the overlayfs-based proposal from Norbert
>   - some rewording
>   - some typo fixes (yah, Yann being Yann being me...)
>
> Changes v1 -> v2:
>   - split Yann at work initial patch into the first two patch
>   - move the systemd-tmpfile handling to the skeleton
>   - introduce options to enable/disable factory or systemd-tmpfiles
>
>
> Regards,
> Yann E. MORIN.
>
>
> The following changes since commit 5b5d3befef9c92a7485c1c68989d95749882ee2a
>
>   package/python-django: security bump to version 4.0.8 (2022-10-17 22:37:25 +0200)
>
>
> are available as patches in this mail series,
>
> for you to apply patches up to b3efa290e26b85b54ab27728bf190316cf2ab1ee
>
>   system: add option to use an overlayfs on /var on a r/o root w/ systemd (2022-10-18 21:37:43 +0200)
>
>
> ----------------------------------------------------------------
> Yann E. MORIN (6):
>       package/skeleton-systemd: move /var factory tmpfiles out of /etc
>       package/skeleton-systemd: systemd-ify mounting /var tmpfs with ro rootfs
>       package/skeleton-systemd: host the tmpfiles preparation script
>       system: add options for /var factory and tmpfiles pre-seed
>       system: introduce a choice for /var management
>       system: add option to use an overlayfs on /var on a r/o root w/ systemd
>
>  package/skeleton-init-systemd/factory/var.mount    | 18 ++++++
>  .../fakeroot_tmpfiles.sh                           |  0
>  .../overlayfs/rootfs-bindmount-var.service         | 21 +++++++
>  package/skeleton-init-systemd/overlayfs/var.mount  | 15 +++++
>  .../skeleton-init-systemd/skeleton-init-systemd.mk | 36 ++++++++++--
>  package/systemd/systemd.mk                         |  6 --
>  system/Config.in                                   | 67 +++++++++++++++++++++-
>  7 files changed, 150 insertions(+), 13 deletions(-)
>  create mode 100644 package/skeleton-init-systemd/factory/var.mount
>  rename package/{systemd => skeleton-init-systemd}/fakeroot_tmpfiles.sh (100%)
>  create mode 100644 package/skeleton-init-systemd/overlayfs/rootfs-bindmount-var.service
>  create mode 100644 package/skeleton-init-systemd/overlayfs/var.mount
>
> --
>                                         ____________
> .-----------------.--------------------:       _    :------------------.
> |  Yann E. MORIN  | Real-Time Embedded |    __/ )   | /"\ ASCII RIBBON |
> |                 | Software  Designer |  _/ - /'   | \ / CAMPAIGN     |
> | +33 638.411.245 '--------------------: (_    `--, |  X  AGAINST      |
> | yann.morin (at) orange.com           |_="    ,--' | / \ HTML MAIL    |
> '--------------------------------------:______/_____:------------------'
>
>
> _________________________________________________________________________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
>

Hello Yann,

you did not cc me for
[PATCH 5/6 v3] system: introduce a choice for /var management

I would choose the world NONE instead of CUSTOM,
as that is what buildroot does with /var.

Later we could offer CUSTOM by for ex. only providing a var.mount
file, that expects a user-specific mount or similar.

+config BR2_INIT_SYSTEMD_VAR_NONE
+ bool "do nothing"
+ help
+  Choose this if you have custom dispositions (like a
+  post-build, fakeroot script, systemd units, or initramfs)
+  that prepare /var to be writable on a read-only rootfs.


but take my

Acked-by: Norbert Lange <nolange79 at gmail.com>