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

yann.morin at orange.com yann.morin at orange.com
Tue Oct 18 19:43:06 UTC 2022


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.




More information about the buildroot mailing list