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

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

[yann.morin]

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@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.

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [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@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@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@gmail.com>
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

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

[Yann E. MORIN]

Norbert, All,

On 2022-11-06 17:21 +0100, Norbert Lange spake thusly:
> Am Di., 18. Okt. 2022 um 21:43 Uhr schrieb <yann.morin@orange.com>:
[--SNIP--]
> > ----------------------------------------------------------------
> > 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
> 
> you did not cc me for
> [PATCH 5/6 v3] system: introduce a choice for /var management

Woops, that is definitely an oversight, as I did plan on having you in
cc of all changes for you to review. Sorry for the mishap.

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

I am not too strongly set on using CUSTOM, so NONE is OKish...

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

I am not sure I can see how that would work...

Were you thinking of something like:

    [Mount]
    EnvironmentFile=-/etc/default/fs.var
    Where=/var
    What=$VAR_DEVICE
    Type=$VAR_TYPE
    Options=$VAR_OPTIONS

But then, would it not be easier to just provide a drop-in to override
those? What would be the advantage for us to provide a template to begin
with, leaving users to provide thei full var.mount?

And that also leaves the question of how that /var would get populated.

> +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.

Actually, "do nothing" is a bit misleading, as users with custom setups
actualyl *do* something, it's just something else that is not listed in
the prompt.

But you are right, that the choice for the init system has a "None"
entry with a _NONE suffixed option, so for consistency, that is probably
good to use _NONE here too.

> but take my
> 
> Acked-by: Norbert Lange <nolange79@gmail.com>

Great! :-)

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

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

[Norbert Lange]

Am So., 6. Nov. 2022 um 17:49 Uhr schrieb Yann E. MORIN
<yann.morin.1998@free.fr>:
>
> Norbert, All,
>
> On 2022-11-06 17:21 +0100, Norbert Lange spake thusly:
> > Am Di., 18. Okt. 2022 um 21:43 Uhr schrieb <yann.morin@orange.com>:
> [--SNIP--]
> > > ----------------------------------------------------------------
> > > 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
> >
> > you did not cc me for
> > [PATCH 5/6 v3] system: introduce a choice for /var management
>
> Woops, that is definitely an oversight, as I did plan on having you in
> cc of all changes for you to review. Sorry for the mishap.
>
> > I would choose the world NONE instead of CUSTOM,
> > as that is what buildroot does with /var.
>
> I am not too strongly set on using CUSTOM, so NONE is OKish...
>
> > Later we could offer CUSTOM by for ex. only providing a var.mount
> > file, that expects a user-specific mount or similar.
>
> I am not sure I can see how that would work...
>
> Were you thinking of something like:
>
>     [Mount]
>     EnvironmentFile=-/etc/default/fs.var
>     Where=/var
>     What=$VAR_DEVICE
>     Type=$VAR_TYPE
>     Options=$VAR_OPTIONS
>
> But then, would it not be easier to just provide a drop-in to override
> those? What would be the advantage for us to provide a template to begin
> with, leaving users to provide thei full var.mount?
>
> And that also leaves the question of how that /var would get populated.

I am still experimenting with this (see comment on Patch 6).

Idea:
buildroot would provide the read-only var in /run/.br/bnd/var
and var.mount would be the same overlay mount,
but the user is expected to provide a mount for upper + workdir,
as systemd unit, fstab or initramfs or whatever.

>
> > +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.
>
> Actually, "do nothing" is a bit misleading, as users with custom setups
> actualyl *do* something, it's just something else that is not listed in
> the prompt.

*Buildroot* does nothing. the user might do nothing, as the base systemd
services do work (with the fakeroot systemd-tmpfiles call), or
provide *his* completely own solution.

>
> But you are right, that the choice for the init system has a "None"
> entry with a _NONE suffixed option, so for consistency, that is probably
> good to use _NONE here too.
>
> > but take my
> >
> > Acked-by: Norbert Lange <nolange79@gmail.com>
>
> Great! :-)
>
> Regards,
> Yann E. MORIN.
>
> --
> .-----------------.--------------------.------------------.--------------------.
> |  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
> | +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
> | +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
> | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
> '------------------------------^-------^------------------^--------------------'

Regars, Norbert
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

[Buildroot] [PATCH 1/6 v3] package/skeleton-systemd: move /var factory tmpfiles out of /etc

[yann.morin]

When the rootfs is not remounted read-write (thus assuming a read-only
rootfs like squashfs), we create a tmpfiles.d factory for /var.

However, we register those in /etc/tmpfiles.d/, but /etc could also be
a tmpfs (for full state-less systems, or easy factory-reset, see [0]).

So, we move our var factory to /usr/lib/tmpfiles.d/, which is also the
location where systemd itself places its own tmpfiles, and where we
already put all our other tmpfiles (see audit, avahi, cryptsetup, dhcp,
lighttpd, nfs-utils, quagga, samba4, swupdate) and our handling of
systemd's catalog files too. We also rename the file to a better name,
so that it is obvious it is generated by us (systemd already installs a
var.conf of its own, so we want to avoid name clashing).

Last little detail: there is no need or reason to create .../tmpfiles.d/
at install time; it is only needed in the rootfs-pre-cmd hook, so we
only create it just before we need it.

[0] http://0pointer.de/blog/projects/stateless.html

Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
Cc: Norbert Lange <nolange79@gmail.com>
Cc: Romain Naour <romain.naour@smile.fr>
Cc: Jérémy Rosen <jeremy.rosen@smile.fr>
[yann.morin.1998@free.fr:
  - split original patch in two
  - this one only moves out of /etc and into /usr/lib
  - adapt commit log accordingly
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
---
 package/skeleton-init-systemd/skeleton-init-systemd.mk | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/package/skeleton-init-systemd/skeleton-init-systemd.mk b/package/skeleton-init-systemd/skeleton-init-systemd.mk
index 795a171809..7b66732ef4 100644
--- a/package/skeleton-init-systemd/skeleton-init-systemd.mk
+++ b/package/skeleton-init-systemd/skeleton-init-systemd.mk
@@ -29,7 +29,6 @@ else
 # a real (but empty) directory, and the "factory files" will be copied
 # back there by the tmpfiles.d mechanism.
 define SKELETON_INIT_SYSTEMD_ROOT_RO_OR_RW
-	mkdir -p $(TARGET_DIR)/etc/systemd/tmpfiles.d
 	echo "/dev/root / auto ro 0 1" >$(TARGET_DIR)/etc/fstab
 	echo "tmpfs /var tmpfs mode=1777 0 0" >>$(TARGET_DIR)/etc/fstab
 endef
@@ -38,6 +37,7 @@ define SKELETON_INIT_SYSTEMD_PRE_ROOTFS_VAR
 	rm -rf $(TARGET_DIR)/usr/share/factory/var
 	mv $(TARGET_DIR)/var $(TARGET_DIR)/usr/share/factory/var
 	mkdir -p $(TARGET_DIR)/var
+	mkdir -p $(TARGET_DIR)/usr/lib/tmpfiles.d
 	for i in $(TARGET_DIR)/usr/share/factory/var/* \
 		 $(TARGET_DIR)/usr/share/factory/var/lib/* \
 		 $(TARGET_DIR)/usr/share/factory/var/lib/systemd/*; do \
@@ -51,7 +51,7 @@ define SKELETON_INIT_SYSTEMD_PRE_ROOTFS_VAR
 			printf "C! %s - - - -\n" "$${j}" \
 			|| exit 1; \
 		fi; \
-	done >$(TARGET_DIR)/etc/tmpfiles.d/var-factory.conf
+	done >$(TARGET_DIR)/usr/lib/tmpfiles.d/buildroot-factory.conf
 endef
 SKELETON_INIT_SYSTEMD_ROOTFS_PRE_CMD_HOOKS += SKELETON_INIT_SYSTEMD_PRE_ROOTFS_VAR
 
-- 
2.25.1


_________________________________________________________________________________________________________________________

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.

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 1/6 v3] package/skeleton-systemd: move /var factory tmpfiles out of /etc

[Norbert Lange]

Am Di., 18. Okt. 2022 um 21:43 Uhr schrieb <yann.morin@orange.com>:
>
> When the rootfs is not remounted read-write (thus assuming a read-only
> rootfs like squashfs), we create a tmpfiles.d factory for /var.
>
> However, we register those in /etc/tmpfiles.d/, but /etc could also be
> a tmpfs (for full state-less systems, or easy factory-reset, see [0]).
>
> So, we move our var factory to /usr/lib/tmpfiles.d/, which is also the
> location where systemd itself places its own tmpfiles, and where we
> already put all our other tmpfiles (see audit, avahi, cryptsetup, dhcp,
> lighttpd, nfs-utils, quagga, samba4, swupdate) and our handling of
> systemd's catalog files too. We also rename the file to a better name,
> so that it is obvious it is generated by us (systemd already installs a
> var.conf of its own, so we want to avoid name clashing).
>
> Last little detail: there is no need or reason to create .../tmpfiles.d/
> at install time; it is only needed in the rootfs-pre-cmd hook, so we
> only create it just before we need it.
>
> [0] http://0pointer.de/blog/projects/stateless.html
>
> Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
> Cc: Norbert Lange <nolange79@gmail.com>
> Cc: Romain Naour <romain.naour@smile.fr>
> Cc: Jérémy Rosen <jeremy.rosen@smile.fr>
> [yann.morin.1998@free.fr:
>   - split original patch in two
>   - this one only moves out of /etc and into /usr/lib
>   - adapt commit log accordingly
> ]
> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
> ---
>  package/skeleton-init-systemd/skeleton-init-systemd.mk | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/package/skeleton-init-systemd/skeleton-init-systemd.mk b/package/skeleton-init-systemd/skeleton-init-systemd.mk
> index 795a171809..7b66732ef4 100644
> --- a/package/skeleton-init-systemd/skeleton-init-systemd.mk
> +++ b/package/skeleton-init-systemd/skeleton-init-systemd.mk
> @@ -29,7 +29,6 @@ else
>  # a real (but empty) directory, and the "factory files" will be copied
>  # back there by the tmpfiles.d mechanism.
>  define SKELETON_INIT_SYSTEMD_ROOT_RO_OR_RW
> -       mkdir -p $(TARGET_DIR)/etc/systemd/tmpfiles.d
>         echo "/dev/root / auto ro 0 1" >$(TARGET_DIR)/etc/fstab
>         echo "tmpfs /var tmpfs mode=1777 0 0" >>$(TARGET_DIR)/etc/fstab
>  endef
> @@ -38,6 +37,7 @@ define SKELETON_INIT_SYSTEMD_PRE_ROOTFS_VAR
>         rm -rf $(TARGET_DIR)/usr/share/factory/var
>         mv $(TARGET_DIR)/var $(TARGET_DIR)/usr/share/factory/var
>         mkdir -p $(TARGET_DIR)/var
> +       mkdir -p $(TARGET_DIR)/usr/lib/tmpfiles.d
>         for i in $(TARGET_DIR)/usr/share/factory/var/* \
>                  $(TARGET_DIR)/usr/share/factory/var/lib/* \
>                  $(TARGET_DIR)/usr/share/factory/var/lib/systemd/*; do \
> @@ -51,7 +51,7 @@ define SKELETON_INIT_SYSTEMD_PRE_ROOTFS_VAR
>                         printf "C! %s - - - -\n" "$${j}" \
>                         || exit 1; \
>                 fi; \

From tmpfiles.d docs: "C ... Recursively copy a file or directory, if
the destination files or directories do not
  exist yet or the destination directory is empty. Note that this
command will not descend into subdirectories
  if the destination directory already exists and is not empty.
Instead, the entire copy operation is skipped."

So all the drama could be just replaced with "C! /var - - - -\n" imho.

(non standard permissions/owner are probably gone either way)

> -       done >$(TARGET_DIR)/etc/tmpfiles.d/var-factory.conf
> +       done >$(TARGET_DIR)/usr/lib/tmpfiles.d/buildroot-factory.conf

How about naming this something like 00-buildroot-var.conf, so hopefully any
*.conf that might expect something in /var existing is executed later.

>  endef
>  SKELETON_INIT_SYSTEMD_ROOTFS_PRE_CMD_HOOKS += SKELETON_INIT_SYSTEMD_PRE_ROOTFS_VAR
>
> --
> 2.25.1
>
>
> _________________________________________________________________________________________________________________________
>
> 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.
>

Regardless, the changes are an improvement, buildroot is the "distro"
and its special sauce
should reside inside /usr as much as possible.
Id highly recommend atleast changing the name to
00-buildroot-var.conf, other than that:

Acked-by: Norbert Lange <nolange79@gmail.com>
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 1/6 v3] package/skeleton-systemd: move /var factory tmpfiles out of /etc

[Yann E. MORIN]

Norbert, All,

On 2022-11-06 16:40 +0100, Norbert Lange spake thusly:
> Am Di., 18. Okt. 2022 um 21:43 Uhr schrieb <yann.morin@orange.com>:
[--SNIP--]
> > diff --git a/package/skeleton-init-systemd/skeleton-init-systemd.mk b/package/skeleton-init-systemd/skeleton-init-systemd.mk
> > index 795a171809..7b66732ef4 100644
> > --- a/package/skeleton-init-systemd/skeleton-init-systemd.mk
> > +++ b/package/skeleton-init-systemd/skeleton-init-systemd.mk
> > @@ -29,7 +29,6 @@ else
> >  # a real (but empty) directory, and the "factory files" will be copied
> >  # back there by the tmpfiles.d mechanism.
> >  define SKELETON_INIT_SYSTEMD_ROOT_RO_OR_RW
> > -       mkdir -p $(TARGET_DIR)/etc/systemd/tmpfiles.d
> >         echo "/dev/root / auto ro 0 1" >$(TARGET_DIR)/etc/fstab
> >         echo "tmpfs /var tmpfs mode=1777 0 0" >>$(TARGET_DIR)/etc/fstab
> >  endef
> > @@ -38,6 +37,7 @@ define SKELETON_INIT_SYSTEMD_PRE_ROOTFS_VAR
> >         rm -rf $(TARGET_DIR)/usr/share/factory/var
> >         mv $(TARGET_DIR)/var $(TARGET_DIR)/usr/share/factory/var
> >         mkdir -p $(TARGET_DIR)/var
> > +       mkdir -p $(TARGET_DIR)/usr/lib/tmpfiles.d
> >         for i in $(TARGET_DIR)/usr/share/factory/var/* \
> >                  $(TARGET_DIR)/usr/share/factory/var/lib/* \
> >                  $(TARGET_DIR)/usr/share/factory/var/lib/systemd/*; do \
> > @@ -51,7 +51,7 @@ define SKELETON_INIT_SYSTEMD_PRE_ROOTFS_VAR
> >                         printf "C! %s - - - -\n" "$${j}" \
> >                         || exit 1; \
> >                 fi; \
> 
> From tmpfiles.d docs: "C ... Recursively copy a file or directory, if
> the destination files or directories do not
>   exist yet or the destination directory is empty. Note that this
> command will not descend into subdirectories
>   if the destination directory already exists and is not empty.
> Instead, the entire copy operation is skipped."
> 
> So all the drama could be just replaced with "C! /var - - - -\n" imho.
> 
> (non standard permissions/owner are probably gone either way)

I do remember that I had to explicitly register individual entries
rather than the directory alone, as that did not work. That was 5+
years ago (commit 26085bbbd500), and I did not write it down in the
commit log...

However, it looks like we hit this issue, as hinted in commit
7e811708f31c (package/skeleton-init-systemd: work around for /var/lib
not populating), which states:

    It turns out /var/lib will exist, because some part of systemd creates
    /var/lib/systemd/catalog on boot before tmpfiles runs.

So, we do have a chicken-n-eggs issue, that registering /var as a whole
does not work.

I'll try to investigate further, and see if that's still the case.

> > -       done >$(TARGET_DIR)/etc/tmpfiles.d/var-factory.conf
> > +       done >$(TARGET_DIR)/usr/lib/tmpfiles.d/buildroot-factory.conf
> 
> How about naming this something like 00-buildroot-var.conf, so hopefully any
> *.conf that might expect something in /var existing is executed later.

I am totally OK for 00-buildroot-var.conf.

[--SNIP--]
> Regardless, the changes are an improvement, buildroot is the "distro"
> and its special sauce
> should reside inside /usr as much as possible.

Yes, that was my reasoning as well.

> Id highly recommend atleast changing the name to
> 00-buildroot-var.conf, other than that:

Agreed.

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

Thanks!

Regards,
Yann E. MORIN.

> _______________________________________________
> buildroot mailing list
> buildroot@buildroot.org
> https://lists.buildroot.org/mailman/listinfo/buildroot

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 1/6 v3] package/skeleton-systemd: move /var factory tmpfiles out of /etc

[Norbert Lange]

Am So., 6. Nov. 2022 um 16:58 Uhr schrieb Yann E. MORIN
<yann.morin.1998@free.fr>:
>
> Norbert, All,
>
> On 2022-11-06 16:40 +0100, Norbert Lange spake thusly:
> > Am Di., 18. Okt. 2022 um 21:43 Uhr schrieb <yann.morin@orange.com>:
> [--SNIP--]
> > > diff --git a/package/skeleton-init-systemd/skeleton-init-systemd.mk b/package/skeleton-init-systemd/skeleton-init-systemd.mk
> > > index 795a171809..7b66732ef4 100644
> > > --- a/package/skeleton-init-systemd/skeleton-init-systemd.mk
> > > +++ b/package/skeleton-init-systemd/skeleton-init-systemd.mk
> > > @@ -29,7 +29,6 @@ else
> > >  # a real (but empty) directory, and the "factory files" will be copied
> > >  # back there by the tmpfiles.d mechanism.
> > >  define SKELETON_INIT_SYSTEMD_ROOT_RO_OR_RW
> > > -       mkdir -p $(TARGET_DIR)/etc/systemd/tmpfiles.d
> > >         echo "/dev/root / auto ro 0 1" >$(TARGET_DIR)/etc/fstab
> > >         echo "tmpfs /var tmpfs mode=1777 0 0" >>$(TARGET_DIR)/etc/fstab
> > >  endef
> > > @@ -38,6 +37,7 @@ define SKELETON_INIT_SYSTEMD_PRE_ROOTFS_VAR
> > >         rm -rf $(TARGET_DIR)/usr/share/factory/var
> > >         mv $(TARGET_DIR)/var $(TARGET_DIR)/usr/share/factory/var
> > >         mkdir -p $(TARGET_DIR)/var
> > > +       mkdir -p $(TARGET_DIR)/usr/lib/tmpfiles.d
> > >         for i in $(TARGET_DIR)/usr/share/factory/var/* \
> > >                  $(TARGET_DIR)/usr/share/factory/var/lib/* \
> > >                  $(TARGET_DIR)/usr/share/factory/var/lib/systemd/*; do \
> > > @@ -51,7 +51,7 @@ define SKELETON_INIT_SYSTEMD_PRE_ROOTFS_VAR
> > >                         printf "C! %s - - - -\n" "$${j}" \
> > >                         || exit 1; \
> > >                 fi; \
> >
> > From tmpfiles.d docs: "C ... Recursively copy a file or directory, if
> > the destination files or directories do not
> >   exist yet or the destination directory is empty. Note that this
> > command will not descend into subdirectories
> >   if the destination directory already exists and is not empty.
> > Instead, the entire copy operation is skipped."
> >
> > So all the drama could be just replaced with "C! /var - - - -\n" imho.
> >
> > (non standard permissions/owner are probably gone either way)
>
> I do remember that I had to explicitly register individual entries
> rather than the directory alone, as that did not work. That was 5+
> years ago (commit 26085bbbd500), and I did not write it down in the
> commit log...
>
> However, it looks like we hit this issue, as hinted in commit
> 7e811708f31c (package/skeleton-init-systemd: work around for /var/lib
> not populating), which states:
>
>     It turns out /var/lib will exist, because some part of systemd creates
>     /var/lib/systemd/catalog on boot before tmpfiles runs.
>
> So, we do have a chicken-n-eggs issue, that registering /var as a whole
> does not work.

I guess thats the logging service, systemd-tmpfiles-setup.service already
requires some stuff running and other stuff is able to run and freely access
/var aswell.

The clean way would be to be done with "migrating" /var before local-fs.target
is reached.

Regards, Norbert
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 1/6 v3] package/skeleton-systemd: move /var factory tmpfiles out of /etc

[Yann E. MORIN]

Yann, All,

On 2022-10-18 21:43 +0200, yann.morin@orange.com spake thusly:
> When the rootfs is not remounted read-write (thus assuming a read-only
> rootfs like squashfs), we create a tmpfiles.d factory for /var.
> 
> However, we register those in /etc/tmpfiles.d/, but /etc could also be
> a tmpfs (for full state-less systems, or easy factory-reset, see [0]).
> 
> So, we move our var factory to /usr/lib/tmpfiles.d/, which is also the
> location where systemd itself places its own tmpfiles, and where we
> already put all our other tmpfiles (see audit, avahi, cryptsetup, dhcp,
> lighttpd, nfs-utils, quagga, samba4, swupdate) and our handling of
> systemd's catalog files too. We also rename the file to a better name,
> so that it is obvious it is generated by us (systemd already installs a
> var.conf of its own, so we want to avoid name clashing).
> 
> Last little detail: there is no need or reason to create .../tmpfiles.d/
> at install time; it is only needed in the rootfs-pre-cmd hook, so we
> only create it just before we need it.
> 
> [0] http://0pointer.de/blog/projects/stateless.html
> 
> Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
> Cc: Norbert Lange <nolange79@gmail.com>
> Cc: Romain Naour <romain.naour@smile.fr>
> Cc: Jérémy Rosen <jeremy.rosen@smile.fr>
> [yann.morin.1998@free.fr:
>   - split original patch in two
>   - this one only moves out of /etc and into /usr/lib
>   - adapt commit log accordingly
> ]
> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>

Applied to master with the renaming suggested by Norbert, thanks.

Regards,
Yann E. MORIN.

> ---
>  package/skeleton-init-systemd/skeleton-init-systemd.mk | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/package/skeleton-init-systemd/skeleton-init-systemd.mk b/package/skeleton-init-systemd/skeleton-init-systemd.mk
> index 795a171809..7b66732ef4 100644
> --- a/package/skeleton-init-systemd/skeleton-init-systemd.mk
> +++ b/package/skeleton-init-systemd/skeleton-init-systemd.mk
> @@ -29,7 +29,6 @@ else
>  # a real (but empty) directory, and the "factory files" will be copied
>  # back there by the tmpfiles.d mechanism.
>  define SKELETON_INIT_SYSTEMD_ROOT_RO_OR_RW
> -	mkdir -p $(TARGET_DIR)/etc/systemd/tmpfiles.d
>  	echo "/dev/root / auto ro 0 1" >$(TARGET_DIR)/etc/fstab
>  	echo "tmpfs /var tmpfs mode=1777 0 0" >>$(TARGET_DIR)/etc/fstab
>  endef
> @@ -38,6 +37,7 @@ define SKELETON_INIT_SYSTEMD_PRE_ROOTFS_VAR
>  	rm -rf $(TARGET_DIR)/usr/share/factory/var
>  	mv $(TARGET_DIR)/var $(TARGET_DIR)/usr/share/factory/var
>  	mkdir -p $(TARGET_DIR)/var
> +	mkdir -p $(TARGET_DIR)/usr/lib/tmpfiles.d
>  	for i in $(TARGET_DIR)/usr/share/factory/var/* \
>  		 $(TARGET_DIR)/usr/share/factory/var/lib/* \
>  		 $(TARGET_DIR)/usr/share/factory/var/lib/systemd/*; do \
> @@ -51,7 +51,7 @@ define SKELETON_INIT_SYSTEMD_PRE_ROOTFS_VAR
>  			printf "C! %s - - - -\n" "$${j}" \
>  			|| exit 1; \
>  		fi; \
> -	done >$(TARGET_DIR)/etc/tmpfiles.d/var-factory.conf
> +	done >$(TARGET_DIR)/usr/lib/tmpfiles.d/buildroot-factory.conf
>  endef
>  SKELETON_INIT_SYSTEMD_ROOTFS_PRE_CMD_HOOKS += SKELETON_INIT_SYSTEMD_PRE_ROOTFS_VAR
>  
> -- 
> 2.25.1
> 
> 
> _________________________________________________________________________________________________________________________
> 
> 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.
> 
> _______________________________________________
> buildroot mailing list
> buildroot@buildroot.org
> https://lists.buildroot.org/mailman/listinfo/buildroot

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

[Buildroot] [PATCH 2/6 v3] package/skeleton-systemd: systemd-ify mounting /var tmpfs with ro rootfs

[yann.morin]

To mount our /var tmpfs when the rootfs is mounted read-only (really,
not remounted reqd-write), we use an entry in fstab.

However, /etc could also be a tmpfs (for full state-less systems, or
easy factory-reset, see [0]). It also prevents easily ordeting other
systemd units until after /var is mounted 5not impossible, but less
easy).

So, we register /var as a systemd mount unit, so that we can also have
the /var factory populated and functional even when /etc is empty. The
var.mount unit is heavily modelled after systemd's own tmp.mount one, so
we carry the same license for that file (in case that may apply). We add
an explicit reverse dependency to systemd-tmpfiles-setup.service, to
ensure /var is mounted before we try to populate it.

This has two side effects:
  - as hinted previously, it simplifies writing other systemd units to
    order them after /var is mounted
  - replace it with their own, which mounts an actual filesystem

[0] http://0pointer.de/blog/projects/stateless.html

Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
Cc: Norbert Lange <nolange79@gmail.com>
Cc: Romain Naour <romain.naour@smile.fr>
Cc: Jérémy Rosen <jeremy.rosen@smile.fr>
[yann.morin.1998@free.fr:
  - split original patch in two
  - this one only handles converting /var mounting into a systemd unit
  - adapt commit log accordingly
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
---
 .../skeleton-init-systemd.mk                   |  3 ++-
 package/skeleton-init-systemd/var.mount        | 18 ++++++++++++++++++
 2 files changed, 20 insertions(+), 1 deletion(-)
 create mode 100644 package/skeleton-init-systemd/var.mount

diff --git a/package/skeleton-init-systemd/skeleton-init-systemd.mk b/package/skeleton-init-systemd/skeleton-init-systemd.mk
index 7b66732ef4..970951d553 100644
--- a/package/skeleton-init-systemd/skeleton-init-systemd.mk
+++ b/package/skeleton-init-systemd/skeleton-init-systemd.mk
@@ -30,7 +30,6 @@ else
 # back there by the tmpfiles.d mechanism.
 define SKELETON_INIT_SYSTEMD_ROOT_RO_OR_RW
 	echo "/dev/root / auto ro 0 1" >$(TARGET_DIR)/etc/fstab
-	echo "tmpfs /var tmpfs mode=1777 0 0" >>$(TARGET_DIR)/etc/fstab
 endef
 
 define SKELETON_INIT_SYSTEMD_PRE_ROOTFS_VAR
@@ -52,6 +51,8 @@ define SKELETON_INIT_SYSTEMD_PRE_ROOTFS_VAR
 			|| exit 1; \
 		fi; \
 	done >$(TARGET_DIR)/usr/lib/tmpfiles.d/buildroot-factory.conf
+	$(INSTALL) -D -m 0644 $(SKELETON_INIT_SYSTEMD_PKGDIR)/var.mount \
+		$(TARGET_DIR)/usr/lib/systemd/system/var.mount
 endef
 SKELETON_INIT_SYSTEMD_ROOTFS_PRE_CMD_HOOKS += SKELETON_INIT_SYSTEMD_PRE_ROOTFS_VAR
 
diff --git a/package/skeleton-init-systemd/var.mount b/package/skeleton-init-systemd/var.mount
new file mode 100644
index 0000000000..6b165dff6d
--- /dev/null
+++ b/package/skeleton-init-systemd/var.mount
@@ -0,0 +1,18 @@
+# SPDX-License-Identifier: LGPL-2.1-or-later
+# Modelled after systemd's tmp.mount
+
+[Unit]
+Description=Buildroot /var tmpfs
+DefaultDependencies=no
+Conflicts=umount.target
+Before=basic.target local-fs.target umount.target systemd-tmpfiles-setup.service
+After=swap.target
+
+[Mount]
+What=tmpfs
+Where=/var
+Type=tmpfs
+Options=mode=1777,strictatime,nosuid,nodev,size=50%%,nr_inodes=1m
+
+[Install]
+WantedBy=basic.target
-- 
2.25.1


_________________________________________________________________________________________________________________________

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.

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 2/6 v3] package/skeleton-systemd: systemd-ify mounting /var tmpfs with ro rootfs

[Norbert Lange]

Am Di., 18. Okt. 2022 um 21:43 Uhr schrieb <yann.morin@orange.com>:
>
> To mount our /var tmpfs when the rootfs is mounted read-only (really,
> not remounted reqd-write), we use an entry in fstab.
>
> However, /etc could also be a tmpfs (for full state-less systems, or
> easy factory-reset, see [0]). It also prevents easily ordeting other
> systemd units until after /var is mounted 5not impossible, but less
> easy).
>
> So, we register /var as a systemd mount unit, so that we can also have
> the /var factory populated and functional even when /etc is empty. The
> var.mount unit is heavily modelled after systemd's own tmp.mount one, so
> we carry the same license for that file (in case that may apply). We add
> an explicit reverse dependency to systemd-tmpfiles-setup.service, to
> ensure /var is mounted before we try to populate it.
>
> This has two side effects:
>   - as hinted previously, it simplifies writing other systemd units to
>     order them after /var is mounted
>   - replace it with their own, which mounts an actual filesystem
>
> [0] http://0pointer.de/blog/projects/stateless.html
>
> Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
> Cc: Norbert Lange <nolange79@gmail.com>
> Cc: Romain Naour <romain.naour@smile.fr>
> Cc: Jérémy Rosen <jeremy.rosen@smile.fr>
> [yann.morin.1998@free.fr:
>   - split original patch in two
>   - this one only handles converting /var mounting into a systemd unit
>   - adapt commit log accordingly
> ]
> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
> ---
>  .../skeleton-init-systemd.mk                   |  3 ++-
>  package/skeleton-init-systemd/var.mount        | 18 ++++++++++++++++++
>  2 files changed, 20 insertions(+), 1 deletion(-)
>  create mode 100644 package/skeleton-init-systemd/var.mount
>
> diff --git a/package/skeleton-init-systemd/skeleton-init-systemd.mk b/package/skeleton-init-systemd/skeleton-init-systemd.mk
> index 7b66732ef4..970951d553 100644
> --- a/package/skeleton-init-systemd/skeleton-init-systemd.mk
> +++ b/package/skeleton-init-systemd/skeleton-init-systemd.mk
> @@ -30,7 +30,6 @@ else
>  # back there by the tmpfiles.d mechanism.
>  define SKELETON_INIT_SYSTEMD_ROOT_RO_OR_RW
>         echo "/dev/root / auto ro 0 1" >$(TARGET_DIR)/etc/fstab
> -       echo "tmpfs /var tmpfs mode=1777 0 0" >>$(TARGET_DIR)/etc/fstab
>  endef
>
>  define SKELETON_INIT_SYSTEMD_PRE_ROOTFS_VAR
> @@ -52,6 +51,8 @@ define SKELETON_INIT_SYSTEMD_PRE_ROOTFS_VAR
>                         || exit 1; \
>                 fi; \
>         done >$(TARGET_DIR)/usr/lib/tmpfiles.d/buildroot-factory.conf
> +       $(INSTALL) -D -m 0644 $(SKELETON_INIT_SYSTEMD_PKGDIR)/var.mount \
> +               $(TARGET_DIR)/usr/lib/systemd/system/var.mount
>  endef
>  SKELETON_INIT_SYSTEMD_ROOTFS_PRE_CMD_HOOKS += SKELETON_INIT_SYSTEMD_PRE_ROOTFS_VAR
>
> diff --git a/package/skeleton-init-systemd/var.mount b/package/skeleton-init-systemd/var.mount
> new file mode 100644
> index 0000000000..6b165dff6d
> --- /dev/null
> +++ b/package/skeleton-init-systemd/var.mount
> @@ -0,0 +1,18 @@
> +# SPDX-License-Identifier: LGPL-2.1-or-later
> +# Modelled after systemd's tmp.mount
> +
> +[Unit]
> +Description=Buildroot /var tmpfs
> +DefaultDependencies=no
> +Conflicts=umount.target
> +Before=basic.target local-fs.target umount.target systemd-tmpfiles-setup.service

Change it to
Before=local-fs.target umount.target

All other dependencies are implicit

> +After=swap.target
> +
> +[Mount]
> +What=tmpfs
> +Where=/var
> +Type=tmpfs
> +Options=mode=1777,strictatime,nosuid,nodev,size=50%%,nr_inodes=1m
> +
> +[Install]
> +WantedBy=basic.target

Drop the install section.

While testing some other overlay solutions I found out that
a /var mount cant be reasonably disabled.
What happens is that basic.target will pull in var.mount,
the only option to disable it would be masking var.mount


> --
> 2.25.1
>
>
> _________________________________________________________________________________________________________________________
>
> 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.
>

Guess i cant ack it conditionally, so far:

Reviewed-by: Norbert Lange <nolange79@gmail.com>
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 2/6 v3] package/skeleton-systemd: systemd-ify mounting /var tmpfs with ro rootfs

[Yann E. MORIN]

Norbert, All,

Thanks for the feedback!

On 2022-11-06 16:56 +0100, Norbert Lange spake thusly:
> Am Di., 18. Okt. 2022 um 21:43 Uhr schrieb <yann.morin@orange.com>:
[--SNIP--]
> > diff --git a/package/skeleton-init-systemd/var.mount b/package/skeleton-init-systemd/var.mount
> > new file mode 100644
> > index 0000000000..6b165dff6d
> > --- /dev/null
> > +++ b/package/skeleton-init-systemd/var.mount
> > @@ -0,0 +1,18 @@
> > +# SPDX-License-Identifier: LGPL-2.1-or-later
> > +# Modelled after systemd's tmp.mount
> > +
> > +[Unit]
> > +Description=Buildroot /var tmpfs
> > +DefaultDependencies=no
> > +Conflicts=umount.target
> > +Before=basic.target local-fs.target umount.target systemd-tmpfiles-setup.service
> 
> Change it to
> Before=local-fs.target umount.target
> 
> All other dependencies are implicit

I looked at bootup(7) (thanks for the pointer!), and it seems that
tmpfiles is on a different synchronisation path (elided for brevity):

            (various low-level  (various mounts and
             services: udevd,    fsck services...)
             tmpfiles, random            |
    .    .   seed, sysctl, ...)          v           .
    .    .      |                 local-fs.target    .
    |    |      |                        |           |
    \____|______|_______________   ______|___________/
                                \ /
                                 v
                          sysinit.target

So, if we want tmpfiles to populate /var, we need to mount /var before
tmpfiles are run, so we need it in the Before section.

I suspect that this should also consistent with the other unit about the
overlayfs; we probably want the same Before for both, no?

> > +After=swap.target
> > +
> > +[Mount]
> > +What=tmpfs
> > +Where=/var
> > +Type=tmpfs
> > +Options=mode=1777,strictatime,nosuid,nodev,size=50%%,nr_inodes=1m
> > +
> > +[Install]
> > +WantedBy=basic.target
> 
> Drop the install section.

Then, how do we ensure the unit is enabled and active?

I guess however that this should be consistent between this unit and the
one about the overlayfs.

> While testing some other overlay solutions I found out that
> a /var mount cant be reasonably disabled.

Do you meant that the following preset:

    disable var.mount

would not be enough to prevent our unit from being acted on?

Also, see below...

> What happens is that basic.target will pull in var.mount,

Ah, so it is implicit that basic.target pulls in mount units? Or is
var.mount somehow special?

Also, why "basic.target", when bootup(7) shows that the first sync point
by which filesystems are supposed to be mounted, is sysinit.target?

> the only option to disable it would be masking var.mount

In this case, people who would mask var.mount would rather need to
override it to mount an actual device arther than a tmpfs, no?

Also, since mount units must be named after their mount point, users who
want to mount their own device would have to provide a unit named
var.mount, so they can't disable it.

Finally, usetrs who have custom dispositions (like an initramfs that
mounts /var) can just remove the unit with a post-build script.

> Guess i cant ack it conditionally, so far:
> 
> Reviewed-by: Norbert Lange <nolange79@gmail.com>

Thanks! I'll add it when I respin with your suggestions.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 2/6 v3] package/skeleton-systemd: systemd-ify mounting /var tmpfs with ro rootfs

[Norbert Lange]

Am So., 6. Nov. 2022 um 17:26 Uhr schrieb Yann E. MORIN
<yann.morin.1998@free.fr>:
>
> Norbert, All,
>
> Thanks for the feedback!
>
> On 2022-11-06 16:56 +0100, Norbert Lange spake thusly:
> > Am Di., 18. Okt. 2022 um 21:43 Uhr schrieb <yann.morin@orange.com>:
> [--SNIP--]
> > > diff --git a/package/skeleton-init-systemd/var.mount b/package/skeleton-init-systemd/var.mount
> > > new file mode 100644
> > > index 0000000000..6b165dff6d
> > > --- /dev/null
> > > +++ b/package/skeleton-init-systemd/var.mount
> > > @@ -0,0 +1,18 @@
> > > +# SPDX-License-Identifier: LGPL-2.1-or-later
> > > +# Modelled after systemd's tmp.mount
> > > +
> > > +[Unit]
> > > +Description=Buildroot /var tmpfs
> > > +DefaultDependencies=no
> > > +Conflicts=umount.target
> > > +Before=basic.target local-fs.target umount.target systemd-tmpfiles-setup.service
> >
> > Change it to
> > Before=local-fs.target umount.target
> >
> > All other dependencies are implicit
>
> I looked at bootup(7) (thanks for the pointer!), and it seems that
> tmpfiles is on a different synchronisation path (elided for brevity):
>
>             (various low-level  (various mounts and
>              services: udevd,    fsck services...)
>              tmpfiles, random            |
>     .    .   seed, sysctl, ...)          v           .
>     .    .      |                 local-fs.target    .
>     |    |      |                        |           |
>     \____|______|_______________   ______|___________/
>                                 \ /
>                                  v
>                           sysinit.target
>
> So, if we want tmpfiles to populate /var, we need to mount /var before
> tmpfiles are run, so we need it in the Before section.

you should keep the dependency lists as short as possible

var.mount is ordered before local-fs.target which is ordered before
systemd-tmpfiles-setup.service.
(that makes it transitive, not implicit, by bad)

(its also sorted before basic.target, see below)

>
> I suspect that this should also consistent with the other unit about the
> overlayfs; we probably want the same Before for both, no?
>
> > > +After=swap.target
> > > +
> > > +[Mount]
> > > +What=tmpfs
> > > +Where=/var
> > > +Type=tmpfs
> > > +Options=mode=1777,strictatime,nosuid,nodev,size=50%%,nr_inodes=1m
> > > +
> > > +[Install]
> > > +WantedBy=basic.target
> >
> > Drop the install section.
>
> Then, how do we ensure the unit is enabled and active?
>
> I guess however that this should be consistent between this unit and the
> one about the overlayfs.
>
> > While testing some other overlay solutions I found out that
> > a /var mount cant be reasonably disabled.
>
> Do you meant that the following preset:
>
>     disable var.mount
>
> would not be enough to prevent our unit from being acted on?

Yes

>
> Also, see below...
>
> > What happens is that basic.target will pull in var.mount,
>
> Ah, so it is implicit that basic.target pulls in mount units? Or is
> var.mount somehow special?

basic.target is special, enabled and orders var.mount before itself with:

RequiresMountsFor=/var /var/tmp

>
> Also, why "basic.target", when bootup(7) shows that the first sync point
> by which filesystems are supposed to be mounted, is sysinit.target?

there is order and there is enablement. basic.target enables var.mount,
but if enabled earlier services might be ordered around var.mount.

>
> > the only option to disable it would be masking var.mount
>
> In this case, people who would mask var.mount would rather need to
> override it to mount an actual device arther than a tmpfs, no?

Depends on what they want to do with it, hope they know.
(there are valid reasons for it)

>
> Also, since mount units must be named after their mount point, users who
> want to mount their own device would have to provide a unit named
> var.mount, so they can't disable it.

yes, or add an override. But are we still here in the
"buildroot should care about that" category?

As you might know, I do that kinda stuff within an initramfs.

>
> Finally, usetrs who have custom dispositions (like an initramfs that
> mounts /var) can just remove the unit with a post-build script.

then why enable it in buildroot in the first place?

>
> > Guess i cant ack it conditionally, so far:
> >
> > Reviewed-by: Norbert Lange <nolange79@gmail.com>
>
> Thanks! I'll add it when I respin with your suggestions.
>
> Regards,
> Yann E. MORIN.
>
> --
> .-----------------.--------------------.------------------.--------------------.
> |  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
> | +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
> | +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
> | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
> '------------------------------^-------^------------------^--------------------'

Regards, Norbert
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 2/6 v3] package/skeleton-systemd: systemd-ify mounting /var tmpfs with ro rootfs

[Yann E. MORIN]

Yann, All,

On 2022-10-18 21:43 +0200, yann.morin@orange.com spake thusly:
> To mount our /var tmpfs when the rootfs is mounted read-only (really,
> not remounted reqd-write), we use an entry in fstab.
> 
> However, /etc could also be a tmpfs (for full state-less systems, or
> easy factory-reset, see [0]). It also prevents easily ordeting other
> systemd units until after /var is mounted 5not impossible, but less
> easy).
> 
> So, we register /var as a systemd mount unit, so that we can also have
> the /var factory populated and functional even when /etc is empty. The
> var.mount unit is heavily modelled after systemd's own tmp.mount one, so
> we carry the same license for that file (in case that may apply). We add
> an explicit reverse dependency to systemd-tmpfiles-setup.service, to
> ensure /var is mounted before we try to populate it.
> 
> This has two side effects:
>   - as hinted previously, it simplifies writing other systemd units to
>     order them after /var is mounted
>   - replace it with their own, which mounts an actual filesystem
> 
> [0] http://0pointer.de/blog/projects/stateless.html
> 
> Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
> Cc: Norbert Lange <nolange79@gmail.com>
> Cc: Romain Naour <romain.naour@smile.fr>
> Cc: Jérémy Rosen <jeremy.rosen@smile.fr>
> [yann.morin.1998@free.fr:
>   - split original patch in two
>   - this one only handles converting /var mounting into a systemd unit
>   - adapt commit log accordingly
> ]
> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>

Applied to master with the tweaks suggested by Norbert, thanks.

Regards,
Yann E. MORIN.

> ---
>  .../skeleton-init-systemd.mk                   |  3 ++-
>  package/skeleton-init-systemd/var.mount        | 18 ++++++++++++++++++
>  2 files changed, 20 insertions(+), 1 deletion(-)
>  create mode 100644 package/skeleton-init-systemd/var.mount
> 
> diff --git a/package/skeleton-init-systemd/skeleton-init-systemd.mk b/package/skeleton-init-systemd/skeleton-init-systemd.mk
> index 7b66732ef4..970951d553 100644
> --- a/package/skeleton-init-systemd/skeleton-init-systemd.mk
> +++ b/package/skeleton-init-systemd/skeleton-init-systemd.mk
> @@ -30,7 +30,6 @@ else
>  # back there by the tmpfiles.d mechanism.
>  define SKELETON_INIT_SYSTEMD_ROOT_RO_OR_RW
>  	echo "/dev/root / auto ro 0 1" >$(TARGET_DIR)/etc/fstab
> -	echo "tmpfs /var tmpfs mode=1777 0 0" >>$(TARGET_DIR)/etc/fstab
>  endef
>  
>  define SKELETON_INIT_SYSTEMD_PRE_ROOTFS_VAR
> @@ -52,6 +51,8 @@ define SKELETON_INIT_SYSTEMD_PRE_ROOTFS_VAR
>  			|| exit 1; \
>  		fi; \
>  	done >$(TARGET_DIR)/usr/lib/tmpfiles.d/buildroot-factory.conf
> +	$(INSTALL) -D -m 0644 $(SKELETON_INIT_SYSTEMD_PKGDIR)/var.mount \
> +		$(TARGET_DIR)/usr/lib/systemd/system/var.mount
>  endef
>  SKELETON_INIT_SYSTEMD_ROOTFS_PRE_CMD_HOOKS += SKELETON_INIT_SYSTEMD_PRE_ROOTFS_VAR
>  
> diff --git a/package/skeleton-init-systemd/var.mount b/package/skeleton-init-systemd/var.mount
> new file mode 100644
> index 0000000000..6b165dff6d
> --- /dev/null
> +++ b/package/skeleton-init-systemd/var.mount
> @@ -0,0 +1,18 @@
> +# SPDX-License-Identifier: LGPL-2.1-or-later
> +# Modelled after systemd's tmp.mount
> +
> +[Unit]
> +Description=Buildroot /var tmpfs
> +DefaultDependencies=no
> +Conflicts=umount.target
> +Before=basic.target local-fs.target umount.target systemd-tmpfiles-setup.service
> +After=swap.target
> +
> +[Mount]
> +What=tmpfs
> +Where=/var
> +Type=tmpfs
> +Options=mode=1777,strictatime,nosuid,nodev,size=50%%,nr_inodes=1m
> +
> +[Install]
> +WantedBy=basic.target
> -- 
> 2.25.1
> 
> 
> _________________________________________________________________________________________________________________________
> 
> 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.
> 
> _______________________________________________
> buildroot mailing list
> buildroot@buildroot.org
> https://lists.buildroot.org/mailman/listinfo/buildroot

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

[Buildroot] [PATCH 3/6 v3] package/skeleton-systemd: host the tmpfiles preparation script

[yann.morin]

From: "Yann E. MORIN" <yann.morin.1998@free.fr>

Commit 0d9b84b7a83f (package/systemd: invoke systemd-tmpfilesd on final
image) forcefully introduced a call to systemd-tmpfiles as a per-rootfs
hook, on the premise that would help with read-only rootfs.

However, that did not account for the then-pre-existing handling of /var
as a factory when the user opted not to remount / read-write (by not
setting BR2_TARGET_GENERIC_REMOUNT_ROOTFS_RW).

This means that, for users who want to use a factory for /var, the
generated filesystem contains the factory files twice: once as stored in
the factory, and once as populated by systemd-tmpefilesd.

In the hope to reconcile the two solutions, we move the handling of
calling systemd-tmpfilesd to the skeleton-init-systemd package, where we
already handle the /var factory. Having the two in the same package will
make it easier, in the future, to provide the user with a choice whether
to use one of the other.

Note that it is very important to keep the order of the hooks as they
are.

Indeed, skeleton-init-systemd sorts before systemd, so its hooks were
registered before systemd's hooks; now that we move the CREATE_TMPFILES
hook, we must ensure it is called after the PRE_ROOTFS_VAR one, so that
the behaviour of acting on the var factory remains.

As a final note: we chose the move this way, rather than move the var
factory into the systemd package, because it is more related to the
system integration on the Buildroot side, rather than the integration
of the systemd package in Buildroot.

Similarly, the other four rootfs hooks, SYSTEMD_LOCALE_PURGE_CATALOGS,
SYSTEMD_UPDATE_CATALOGS, SYSTEMD_RM_CATALOG_UPDATE_SERVICE, and
specially SYSTEMD_PRESET_ALL, should also be moved out of the systemd
package, because they too are more related to the Buildroot system,
rather than to the systemd package itself; but the frontier is very
porous is either way, for such a package as special as systemd.

Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Norbert Lange <nolange79@gmail.com>
Cc: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Cc: Romain Naour <romain.naour@smile.fr>
Cc: Jérémy Rosen <jeremy.rosen@smile.fr>
Cc: Yann E. MORIN <yann.morin@orange.com>
---
 .../{systemd => skeleton-init-systemd}/fakeroot_tmpfiles.sh | 0
 package/skeleton-init-systemd/skeleton-init-systemd.mk      | 6 ++++++
 package/systemd/systemd.mk                                  | 6 ------
 3 files changed, 6 insertions(+), 6 deletions(-)
 rename package/{systemd => skeleton-init-systemd}/fakeroot_tmpfiles.sh (100%)

diff --git a/package/systemd/fakeroot_tmpfiles.sh b/package/skeleton-init-systemd/fakeroot_tmpfiles.sh
similarity index 100%
rename from package/systemd/fakeroot_tmpfiles.sh
rename to package/skeleton-init-systemd/fakeroot_tmpfiles.sh
diff --git a/package/skeleton-init-systemd/skeleton-init-systemd.mk b/package/skeleton-init-systemd/skeleton-init-systemd.mk
index 970951d553..89a28d1780 100644
--- a/package/skeleton-init-systemd/skeleton-init-systemd.mk
+++ b/package/skeleton-init-systemd/skeleton-init-systemd.mk
@@ -58,6 +58,12 @@ SKELETON_INIT_SYSTEMD_ROOTFS_PRE_CMD_HOOKS += SKELETON_INIT_SYSTEMD_PRE_ROOTFS_V
 
 endif
 
+define SKELETON_INIT_SYSTEMD_CREATE_TMPFILES_HOOK
+	HOST_SYSTEMD_TMPFILES=$(HOST_DIR)/bin/systemd-tmpfiles \
+		$(SKELETON_INIT_SYSTEMD_PKGDIR)/fakeroot_tmpfiles.sh $(TARGET_DIR)
+endef
+SKELETON_INIT_SYSTEMD_ROOTFS_PRE_CMD_HOOKS += SKELETON_INIT_SYSTEMD_CREATE_TMPFILES_HOOK
+
 define SKELETON_INIT_SYSTEMD_INSTALL_TARGET_CMDS
 	mkdir -p $(TARGET_DIR)/home
 	mkdir -p $(TARGET_DIR)/srv
diff --git a/package/systemd/systemd.mk b/package/systemd/systemd.mk
index 1d7452de19..e4a8114221 100644
--- a/package/systemd/systemd.mk
+++ b/package/systemd/systemd.mk
@@ -739,12 +739,6 @@ define SYSTEMD_RM_CATALOG_UPDATE_SERVICE
 endef
 SYSTEMD_ROOTFS_PRE_CMD_HOOKS += SYSTEMD_RM_CATALOG_UPDATE_SERVICE
 
-define SYSTEMD_CREATE_TMPFILES_HOOK
-	HOST_SYSTEMD_TMPFILES=$(HOST_DIR)/bin/systemd-tmpfiles \
-		$(SYSTEMD_PKGDIR)/fakeroot_tmpfiles.sh $(TARGET_DIR)
-endef
-SYSTEMD_ROOTFS_PRE_CMD_HOOKS += SYSTEMD_CREATE_TMPFILES_HOOK
-
 define SYSTEMD_PRESET_ALL
 	$(HOST_DIR)/bin/systemctl --root=$(TARGET_DIR) preset-all
 endef
-- 
2.25.1


_________________________________________________________________________________________________________________________

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.

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 3/6 v3] package/skeleton-systemd: host the tmpfiles preparation script

[Norbert Lange]

Am Di., 18. Okt. 2022 um 21:43 Uhr schrieb <yann.morin@orange.com>:
>
> From: "Yann E. MORIN" <yann.morin.1998@free.fr>
>
> Commit 0d9b84b7a83f (package/systemd: invoke systemd-tmpfilesd on final
> image) forcefully introduced a call to systemd-tmpfiles as a per-rootfs
> hook, on the premise that would help with read-only rootfs.

It helps also with a read-only root, but the basic premise is to do as
much work as possible up-front.

>
> However, that did not account for the then-pre-existing handling of /var
> as a factory when the user opted not to remount / read-write (by not
> setting BR2_TARGET_GENERIC_REMOUNT_ROOTFS_RW).
>
> This means that, for users who want to use a factory for /var, the
> generated filesystem contains the factory files twice: once as stored in
> the factory, and once as populated by systemd-tmpefilesd.

To be pragmatic: a systemd conform package would ship
its own tmpfiles.conf or other mechanism to deal with an empty /var.

>
> In the hope to reconcile the two solutions, we move the handling of
> calling systemd-tmpfilesd to the skeleton-init-systemd package, where we
> already handle the /var factory. Having the two in the same package will
> make it easier, in the future, to provide the user with a choice whether
> to use one of the other.
>
> Note that it is very important to keep the order of the hooks as they
> are.
>
> Indeed, skeleton-init-systemd sorts before systemd, so its hooks were
> registered before systemd's hooks; now that we move the CREATE_TMPFILES
> hook, we must ensure it is called after the PRE_ROOTFS_VAR one, so that
> the behaviour of acting on the var factory remains.
>
> As a final note: we chose the move this way, rather than move the var
> factory into the systemd package, because it is more related to the
> system integration on the Buildroot side, rather than the integration
> of the systemd package in Buildroot.
>
> Similarly, the other four rootfs hooks, SYSTEMD_LOCALE_PURGE_CATALOGS,
> SYSTEMD_UPDATE_CATALOGS, SYSTEMD_RM_CATALOG_UPDATE_SERVICE, and
> specially SYSTEMD_PRESET_ALL, should also be moved out of the systemd
> package, because they too are more related to the Buildroot system,
> rather than to the systemd package itself; but the frontier is very
> porous is either way, for such a package as special as systemd.

I think that might make several things more ugly, atleast as long
as the config options are in the systemd package.

>
> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
> Cc: Norbert Lange <nolange79@gmail.com>
> Cc: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
> Cc: Romain Naour <romain.naour@smile.fr>
> Cc: Jérémy Rosen <jeremy.rosen@smile.fr>
> Cc: Yann E. MORIN <yann.morin@orange.com>
> ---
>  .../{systemd => skeleton-init-systemd}/fakeroot_tmpfiles.sh | 0
>  package/skeleton-init-systemd/skeleton-init-systemd.mk      | 6 ++++++
>  package/systemd/systemd.mk                                  | 6 ------
>  3 files changed, 6 insertions(+), 6 deletions(-)
>  rename package/{systemd => skeleton-init-systemd}/fakeroot_tmpfiles.sh (100%)
>
> diff --git a/package/systemd/fakeroot_tmpfiles.sh b/package/skeleton-init-systemd/fakeroot_tmpfiles.sh
> similarity index 100%
> rename from package/systemd/fakeroot_tmpfiles.sh
> rename to package/skeleton-init-systemd/fakeroot_tmpfiles.sh
> diff --git a/package/skeleton-init-systemd/skeleton-init-systemd.mk b/package/skeleton-init-systemd/skeleton-init-systemd.mk
> index 970951d553..89a28d1780 100644
> --- a/package/skeleton-init-systemd/skeleton-init-systemd.mk
> +++ b/package/skeleton-init-systemd/skeleton-init-systemd.mk
> @@ -58,6 +58,12 @@ SKELETON_INIT_SYSTEMD_ROOTFS_PRE_CMD_HOOKS += SKELETON_INIT_SYSTEMD_PRE_ROOTFS_V
>
>  endif
>
> +define SKELETON_INIT_SYSTEMD_CREATE_TMPFILES_HOOK
> +       HOST_SYSTEMD_TMPFILES=$(HOST_DIR)/bin/systemd-tmpfiles \
> +               $(SKELETON_INIT_SYSTEMD_PKGDIR)/fakeroot_tmpfiles.sh $(TARGET_DIR)
> +endef
> +SKELETON_INIT_SYSTEMD_ROOTFS_PRE_CMD_HOOKS += SKELETON_INIT_SYSTEMD_CREATE_TMPFILES_HOOK
> +
>  define SKELETON_INIT_SYSTEMD_INSTALL_TARGET_CMDS
>         mkdir -p $(TARGET_DIR)/home
>         mkdir -p $(TARGET_DIR)/srv
> diff --git a/package/systemd/systemd.mk b/package/systemd/systemd.mk
> index 1d7452de19..e4a8114221 100644
> --- a/package/systemd/systemd.mk
> +++ b/package/systemd/systemd.mk
> @@ -739,12 +739,6 @@ define SYSTEMD_RM_CATALOG_UPDATE_SERVICE
>  endef
>  SYSTEMD_ROOTFS_PRE_CMD_HOOKS += SYSTEMD_RM_CATALOG_UPDATE_SERVICE
>
> -define SYSTEMD_CREATE_TMPFILES_HOOK
> -       HOST_SYSTEMD_TMPFILES=$(HOST_DIR)/bin/systemd-tmpfiles \
> -               $(SYSTEMD_PKGDIR)/fakeroot_tmpfiles.sh $(TARGET_DIR)
> -endef
> -SYSTEMD_ROOTFS_PRE_CMD_HOOKS += SYSTEMD_CREATE_TMPFILES_HOOK
> -
>  define SYSTEMD_PRESET_ALL
>         $(HOST_DIR)/bin/systemctl --root=$(TARGET_DIR) preset-all
>  endef
> --
> 2.25.1
>
>
> _________________________________________________________________________________________________________________________
>
> 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.
>

Acked-by: Norbert Lange <nolange79@gmail.com>
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 3/6 v3] package/skeleton-systemd: host the tmpfiles preparation script

[Yann E. MORIN]

Yann, All,

On 2022-10-18 21:43 +0200, yann.morin@orange.com spake thusly:
> From: "Yann E. MORIN" <yann.morin.1998@free.fr>
> 
> Commit 0d9b84b7a83f (package/systemd: invoke systemd-tmpfilesd on final
> image) forcefully introduced a call to systemd-tmpfiles as a per-rootfs
> hook, on the premise that would help with read-only rootfs.
> 
> However, that did not account for the then-pre-existing handling of /var
> as a factory when the user opted not to remount / read-write (by not
> setting BR2_TARGET_GENERIC_REMOUNT_ROOTFS_RW).
> 
> This means that, for users who want to use a factory for /var, the
> generated filesystem contains the factory files twice: once as stored in
> the factory, and once as populated by systemd-tmpefilesd.
> 
> In the hope to reconcile the two solutions, we move the handling of
> calling systemd-tmpfilesd to the skeleton-init-systemd package, where we
> already handle the /var factory. Having the two in the same package will
> make it easier, in the future, to provide the user with a choice whether
> to use one of the other.
> 
> Note that it is very important to keep the order of the hooks as they
> are.
> 
> Indeed, skeleton-init-systemd sorts before systemd, so its hooks were
> registered before systemd's hooks; now that we move the CREATE_TMPFILES
> hook, we must ensure it is called after the PRE_ROOTFS_VAR one, so that
> the behaviour of acting on the var factory remains.
> 
> As a final note: we chose the move this way, rather than move the var
> factory into the systemd package, because it is more related to the
> system integration on the Buildroot side, rather than the integration
> of the systemd package in Buildroot.
> 
> Similarly, the other four rootfs hooks, SYSTEMD_LOCALE_PURGE_CATALOGS,
> SYSTEMD_UPDATE_CATALOGS, SYSTEMD_RM_CATALOG_UPDATE_SERVICE, and
> specially SYSTEMD_PRESET_ALL, should also be moved out of the systemd
> package, because they too are more related to the Buildroot system,
> rather than to the systemd package itself; but the frontier is very
> porous is either way, for such a package as special as systemd.
> 
> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
> Cc: Norbert Lange <nolange79@gmail.com>
> Cc: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
> Cc: Romain Naour <romain.naour@smile.fr>
> Cc: Jérémy Rosen <jeremy.rosen@smile.fr>
> Cc: Yann E. MORIN <yann.morin@orange.com>

Applied to master, thanks.

Regards,
Yann E. MORIN.

> ---
>  .../{systemd => skeleton-init-systemd}/fakeroot_tmpfiles.sh | 0
>  package/skeleton-init-systemd/skeleton-init-systemd.mk      | 6 ++++++
>  package/systemd/systemd.mk                                  | 6 ------
>  3 files changed, 6 insertions(+), 6 deletions(-)
>  rename package/{systemd => skeleton-init-systemd}/fakeroot_tmpfiles.sh (100%)
> 
> diff --git a/package/systemd/fakeroot_tmpfiles.sh b/package/skeleton-init-systemd/fakeroot_tmpfiles.sh
> similarity index 100%
> rename from package/systemd/fakeroot_tmpfiles.sh
> rename to package/skeleton-init-systemd/fakeroot_tmpfiles.sh
> diff --git a/package/skeleton-init-systemd/skeleton-init-systemd.mk b/package/skeleton-init-systemd/skeleton-init-systemd.mk
> index 970951d553..89a28d1780 100644
> --- a/package/skeleton-init-systemd/skeleton-init-systemd.mk
> +++ b/package/skeleton-init-systemd/skeleton-init-systemd.mk
> @@ -58,6 +58,12 @@ SKELETON_INIT_SYSTEMD_ROOTFS_PRE_CMD_HOOKS += SKELETON_INIT_SYSTEMD_PRE_ROOTFS_V
>  
>  endif
>  
> +define SKELETON_INIT_SYSTEMD_CREATE_TMPFILES_HOOK
> +	HOST_SYSTEMD_TMPFILES=$(HOST_DIR)/bin/systemd-tmpfiles \
> +		$(SKELETON_INIT_SYSTEMD_PKGDIR)/fakeroot_tmpfiles.sh $(TARGET_DIR)
> +endef
> +SKELETON_INIT_SYSTEMD_ROOTFS_PRE_CMD_HOOKS += SKELETON_INIT_SYSTEMD_CREATE_TMPFILES_HOOK
> +
>  define SKELETON_INIT_SYSTEMD_INSTALL_TARGET_CMDS
>  	mkdir -p $(TARGET_DIR)/home
>  	mkdir -p $(TARGET_DIR)/srv
> diff --git a/package/systemd/systemd.mk b/package/systemd/systemd.mk
> index 1d7452de19..e4a8114221 100644
> --- a/package/systemd/systemd.mk
> +++ b/package/systemd/systemd.mk
> @@ -739,12 +739,6 @@ define SYSTEMD_RM_CATALOG_UPDATE_SERVICE
>  endef
>  SYSTEMD_ROOTFS_PRE_CMD_HOOKS += SYSTEMD_RM_CATALOG_UPDATE_SERVICE
>  
> -define SYSTEMD_CREATE_TMPFILES_HOOK
> -	HOST_SYSTEMD_TMPFILES=$(HOST_DIR)/bin/systemd-tmpfiles \
> -		$(SYSTEMD_PKGDIR)/fakeroot_tmpfiles.sh $(TARGET_DIR)
> -endef
> -SYSTEMD_ROOTFS_PRE_CMD_HOOKS += SYSTEMD_CREATE_TMPFILES_HOOK
> -
>  define SYSTEMD_PRESET_ALL
>  	$(HOST_DIR)/bin/systemctl --root=$(TARGET_DIR) preset-all
>  endef
> -- 
> 2.25.1
> 
> 
> _________________________________________________________________________________________________________________________
> 
> 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.
> 
> _______________________________________________
> buildroot mailing list
> buildroot@buildroot.org
> https://lists.buildroot.org/mailman/listinfo/buildroot

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

[Buildroot] [PATCH 4/6 v3] system: add options for /var factory and tmpfiles pre-seed

[yann.morin]

From: "Yann E. MORIN" <yann.morin.1998@free.fr>

Currently, when one does not enable remounting the rootfs read-write,
i.e. keep it read-only, for example because the filesystem is actualyl
read-only by design, like squashfs, then two things happen:

  - we create a factory from the content of /var at build time, register
    tmpfiles entries for it, and mount a tmpfs on /var at runtime, so
    that systemd-tmpfiles does populate /var from the factory; this is
    only done when the rootfs is not remounted r/w;

  - we trigger systemd-tmpfiles at build time, which uses the tmpfiles
    db, of which our /var entries, to pre-populate the filesystem; this
    is always done, whether the rootfs is remounted r/w or not.

Note that Buildroot mounts a tmpfs on /var, and leaves to the integrator
to care for providing an actual filesystem, as there are too many
variants and is very specific to each use-case.

These two mechanisms are conflicting, semantically, bit also
technically: the files from the factory will be duplicated, but that
may help in some situations when the actual /var filesystem is not
mountable.

In some cases, it might be preferable to have none, either, or both
mechanisms enabled; it highly depends on the ultimate integration scheme
chosen for a device.

For example, some people will be very happy with a /var that is actually
on a tmpfs and that it gets reseeded form scratch at every boot, while
others may want to ensure that their system continue to work even when
they can't mount something that makes /var writable.

YMMV, as they used to say back in the day...

So, we introduce two new options, in the system sub-menu, each to drive
each mechanism. We default those options to y, to keep the previous
behaviour by default, except the var factory is only available when the
rootfs is not remounted r/w, as it were so far.

We still hint in the help text that there might be some conflict between
the two mechanisms, bt since it has been that way for some time, it does
not look too broken for most people.

Since that introduces more options related to systemd being chosen as an
init system, we gather those two options and the existing one inside a
if-endif block, rather than adding more 'depends on' on each options.

Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Norbert Lange <nolange79@gmail.com>
Cc: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Cc: Romain Naour <romain.naour@smile.fr>
Cc: Jérémy Rosen <jeremy.rosen@smile.fr>
Cc: Yann E. MORIN <yann.morin@orange.com>
---
 .../skeleton-init-systemd.mk                  |  7 +++-
 system/Config.in                              | 42 ++++++++++++++++++-
 2 files changed, 46 insertions(+), 3 deletions(-)

diff --git a/package/skeleton-init-systemd/skeleton-init-systemd.mk b/package/skeleton-init-systemd/skeleton-init-systemd.mk
index 89a28d1780..69991265a5 100644
--- a/package/skeleton-init-systemd/skeleton-init-systemd.mk
+++ b/package/skeleton-init-systemd/skeleton-init-systemd.mk
@@ -32,6 +32,7 @@ define SKELETON_INIT_SYSTEMD_ROOT_RO_OR_RW
 	echo "/dev/root / auto ro 0 1" >$(TARGET_DIR)/etc/fstab
 endef
 
+ifeq ($(BR2_INIT_SYSTEMD_VAR_FACTORY),y)
 define SKELETON_INIT_SYSTEMD_PRE_ROOTFS_VAR
 	rm -rf $(TARGET_DIR)/usr/share/factory/var
 	mv $(TARGET_DIR)/var $(TARGET_DIR)/usr/share/factory/var
@@ -55,14 +56,16 @@ define SKELETON_INIT_SYSTEMD_PRE_ROOTFS_VAR
 		$(TARGET_DIR)/usr/lib/systemd/system/var.mount
 endef
 SKELETON_INIT_SYSTEMD_ROOTFS_PRE_CMD_HOOKS += SKELETON_INIT_SYSTEMD_PRE_ROOTFS_VAR
+endif  # BR2_INIT_SYSTEMD_VAR_FACTORY
+endif  # BR2_TARGET_GENERIC_REMOUNT_ROOTFS_RW
 
-endif
-
+ifeq ($(BR2_INIT_SYSTEMD_POPULATE_TMPFILES),y)
 define SKELETON_INIT_SYSTEMD_CREATE_TMPFILES_HOOK
 	HOST_SYSTEMD_TMPFILES=$(HOST_DIR)/bin/systemd-tmpfiles \
 		$(SKELETON_INIT_SYSTEMD_PKGDIR)/fakeroot_tmpfiles.sh $(TARGET_DIR)
 endef
 SKELETON_INIT_SYSTEMD_ROOTFS_PRE_CMD_HOOKS += SKELETON_INIT_SYSTEMD_CREATE_TMPFILES_HOOK
+endif  # BR2_INIT_SYSTEMD_POPULATE_TMPFILES
 
 define SKELETON_INIT_SYSTEMD_INSTALL_TARGET_CMDS
 	mkdir -p $(TARGET_DIR)/home
diff --git a/system/Config.in b/system/Config.in
index 888c24ce81..806a747315 100644
--- a/system/Config.in
+++ b/system/Config.in
@@ -154,10 +154,48 @@ source "$BR2_BASE_DIR/.br2-external.in.init"
 
 endchoice
 
+if BR2_INIT_SYSTEMD
+
+config BR2_INIT_SYSTEMD_VAR_FACTORY
+	bool "build a factory to populate a tmpfs on /var"
+	default y  # legacy
+	depends on !BR2_TARGET_GENERIC_REMOUNT_ROOTFS_RW
+	help
+	  Build a factory of the content of /var as installed by
+	  packages, mount a tmpfs on /var at runtime, so that
+	  systemd-tmpfiles can populate it from the factory.
+
+	  This may help on a read-only rootfs.
+
+	  It probably does not play very well with triggering a call
+	  to systemd-tmpfiles at build time (below).
+
+	  Note: Buildroot mounts a tmpfs on /var to at least make the
+	  system bootable out of the box; mounting a filesystem from
+	  actual storage is left to the integration, as it is too
+	  specific and may need preparatory work like partitionning a
+	  device and/or formatting a filesystem first, so that falls
+	  out of the scope of Buildroot.
+
+	  To use persistent storage, provide a systemd dropin for the
+	  var.mount unit, that overrides the What and Type, and possibly
+	  the Options and After, fields.
+
+config BR2_INIT_SYSTEMD_POPULATE_TMPFILES
+	bool "trigger systemd-tmpfiles during build"
+	default y  # legacy
+	help
+	  Act on the systemd-tmpfiles.d database at build time, when
+	  assembling the root filesystems.
+
+	  This may help on a read-only filesystem.
+
+	  It probably does not play very well with the /var factory
+	  (above).
+
 config BR2_PACKAGE_SYSTEMD_DEFAULT_TARGET
 	string "The default unit systemd starts at bootup"
 	default "multi-user.target"
-	depends on BR2_INIT_SYSTEMD
 	help
 	  Specify the name of the unit configuration file to be started
 	  at bootup by systemd. Should end in ".target".
@@ -165,6 +203,8 @@ config BR2_PACKAGE_SYSTEMD_DEFAULT_TARGET
 
 	  https://www.freedesktop.org/software/systemd/man/systemd.special.html#default.target
 
+endif # BR2_INIT_SYSTEMD
+
 choice
 	prompt "/dev management" if !BR2_INIT_SYSTEMD
 	default BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_DEVTMPFS
-- 
2.25.1


_________________________________________________________________________________________________________________________

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.

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 4/6 v3] system: add options for /var factory and tmpfiles pre-seed

[Yann E. MORIN]

Yann, All,

On 2022-10-18 21:43 +0200, yann.morin@orange.com spake thusly:
> From: "Yann E. MORIN" <yann.morin.1998@free.fr>
> 
> Currently, when one does not enable remounting the rootfs read-write,
> i.e. keep it read-only, for example because the filesystem is actualyl
> read-only by design, like squashfs, then two things happen:
> 
>   - we create a factory from the content of /var at build time, register
>     tmpfiles entries for it, and mount a tmpfs on /var at runtime, so
>     that systemd-tmpfiles does populate /var from the factory; this is
>     only done when the rootfs is not remounted r/w;
> 
>   - we trigger systemd-tmpfiles at build time, which uses the tmpfiles
>     db, of which our /var entries, to pre-populate the filesystem; this
>     is always done, whether the rootfs is remounted r/w or not.
> 
> Note that Buildroot mounts a tmpfs on /var, and leaves to the integrator
> to care for providing an actual filesystem, as there are too many
> variants and is very specific to each use-case.
> 
> These two mechanisms are conflicting, semantically, bit also
> technically: the files from the factory will be duplicated, but that
> may help in some situations when the actual /var filesystem is not
> mountable.
> 
> In some cases, it might be preferable to have none, either, or both
> mechanisms enabled; it highly depends on the ultimate integration scheme
> chosen for a device.
> 
> For example, some people will be very happy with a /var that is actually
> on a tmpfs and that it gets reseeded form scratch at every boot, while
> others may want to ensure that their system continue to work even when
> they can't mount something that makes /var writable.
> 
> YMMV, as they used to say back in the day...
> 
> So, we introduce two new options, in the system sub-menu, each to drive
> each mechanism. We default those options to y, to keep the previous
> behaviour by default, except the var factory is only available when the
> rootfs is not remounted r/w, as it were so far.
> 
> We still hint in the help text that there might be some conflict between
> the two mechanisms, bt since it has been that way for some time, it does
> not look too broken for most people.
> 
> Since that introduces more options related to systemd being chosen as an
> init system, we gather those two options and the existing one inside a
> if-endif block, rather than adding more 'depends on' on each options.
> 
> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
> Cc: Norbert Lange <nolange79@gmail.com>
> Cc: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
> Cc: Romain Naour <romain.naour@smile.fr>
> Cc: Jérémy Rosen <jeremy.rosen@smile.fr>
> Cc: Yann E. MORIN <yann.morin@orange.com>

Applied to master, after fixing my many usual typoes, thanks.

Regards,
Yann E. MORIN.

> ---
>  .../skeleton-init-systemd.mk                  |  7 +++-
>  system/Config.in                              | 42 ++++++++++++++++++-
>  2 files changed, 46 insertions(+), 3 deletions(-)
> 
> diff --git a/package/skeleton-init-systemd/skeleton-init-systemd.mk b/package/skeleton-init-systemd/skeleton-init-systemd.mk
> index 89a28d1780..69991265a5 100644
> --- a/package/skeleton-init-systemd/skeleton-init-systemd.mk
> +++ b/package/skeleton-init-systemd/skeleton-init-systemd.mk
> @@ -32,6 +32,7 @@ define SKELETON_INIT_SYSTEMD_ROOT_RO_OR_RW
>  	echo "/dev/root / auto ro 0 1" >$(TARGET_DIR)/etc/fstab
>  endef
>  
> +ifeq ($(BR2_INIT_SYSTEMD_VAR_FACTORY),y)
>  define SKELETON_INIT_SYSTEMD_PRE_ROOTFS_VAR
>  	rm -rf $(TARGET_DIR)/usr/share/factory/var
>  	mv $(TARGET_DIR)/var $(TARGET_DIR)/usr/share/factory/var
> @@ -55,14 +56,16 @@ define SKELETON_INIT_SYSTEMD_PRE_ROOTFS_VAR
>  		$(TARGET_DIR)/usr/lib/systemd/system/var.mount
>  endef
>  SKELETON_INIT_SYSTEMD_ROOTFS_PRE_CMD_HOOKS += SKELETON_INIT_SYSTEMD_PRE_ROOTFS_VAR
> +endif  # BR2_INIT_SYSTEMD_VAR_FACTORY
> +endif  # BR2_TARGET_GENERIC_REMOUNT_ROOTFS_RW
>  
> -endif
> -
> +ifeq ($(BR2_INIT_SYSTEMD_POPULATE_TMPFILES),y)
>  define SKELETON_INIT_SYSTEMD_CREATE_TMPFILES_HOOK
>  	HOST_SYSTEMD_TMPFILES=$(HOST_DIR)/bin/systemd-tmpfiles \
>  		$(SKELETON_INIT_SYSTEMD_PKGDIR)/fakeroot_tmpfiles.sh $(TARGET_DIR)
>  endef
>  SKELETON_INIT_SYSTEMD_ROOTFS_PRE_CMD_HOOKS += SKELETON_INIT_SYSTEMD_CREATE_TMPFILES_HOOK
> +endif  # BR2_INIT_SYSTEMD_POPULATE_TMPFILES
>  
>  define SKELETON_INIT_SYSTEMD_INSTALL_TARGET_CMDS
>  	mkdir -p $(TARGET_DIR)/home
> diff --git a/system/Config.in b/system/Config.in
> index 888c24ce81..806a747315 100644
> --- a/system/Config.in
> +++ b/system/Config.in
> @@ -154,10 +154,48 @@ source "$BR2_BASE_DIR/.br2-external.in.init"
>  
>  endchoice
>  
> +if BR2_INIT_SYSTEMD
> +
> +config BR2_INIT_SYSTEMD_VAR_FACTORY
> +	bool "build a factory to populate a tmpfs on /var"
> +	default y  # legacy
> +	depends on !BR2_TARGET_GENERIC_REMOUNT_ROOTFS_RW
> +	help
> +	  Build a factory of the content of /var as installed by
> +	  packages, mount a tmpfs on /var at runtime, so that
> +	  systemd-tmpfiles can populate it from the factory.
> +
> +	  This may help on a read-only rootfs.
> +
> +	  It probably does not play very well with triggering a call
> +	  to systemd-tmpfiles at build time (below).
> +
> +	  Note: Buildroot mounts a tmpfs on /var to at least make the
> +	  system bootable out of the box; mounting a filesystem from
> +	  actual storage is left to the integration, as it is too
> +	  specific and may need preparatory work like partitionning a
> +	  device and/or formatting a filesystem first, so that falls
> +	  out of the scope of Buildroot.
> +
> +	  To use persistent storage, provide a systemd dropin for the
> +	  var.mount unit, that overrides the What and Type, and possibly
> +	  the Options and After, fields.
> +
> +config BR2_INIT_SYSTEMD_POPULATE_TMPFILES
> +	bool "trigger systemd-tmpfiles during build"
> +	default y  # legacy
> +	help
> +	  Act on the systemd-tmpfiles.d database at build time, when
> +	  assembling the root filesystems.
> +
> +	  This may help on a read-only filesystem.
> +
> +	  It probably does not play very well with the /var factory
> +	  (above).
> +
>  config BR2_PACKAGE_SYSTEMD_DEFAULT_TARGET
>  	string "The default unit systemd starts at bootup"
>  	default "multi-user.target"
> -	depends on BR2_INIT_SYSTEMD
>  	help
>  	  Specify the name of the unit configuration file to be started
>  	  at bootup by systemd. Should end in ".target".
> @@ -165,6 +203,8 @@ config BR2_PACKAGE_SYSTEMD_DEFAULT_TARGET
>  
>  	  https://www.freedesktop.org/software/systemd/man/systemd.special.html#default.target
>  
> +endif # BR2_INIT_SYSTEMD
> +
>  choice
>  	prompt "/dev management" if !BR2_INIT_SYSTEMD
>  	default BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_DEVTMPFS
> -- 
> 2.25.1
> 
> 
> _________________________________________________________________________________________________________________________
> 
> 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.
> 
> _______________________________________________
> buildroot mailing list
> buildroot@buildroot.org
> https://lists.buildroot.org/mailman/listinfo/buildroot

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

[Buildroot] [PATCH 5/6 v3] system: introduce a choice for /var management

[yann.morin]

Currently, we have a single solution to handle the /var content on a
read-only root filesystem, and users can opt out of using it.

We're going to introduce another solution (based on an overlayfs), which
is incompatible with using the factory, so we'll have a choice of three
mutually exclusive options.

Introduce that choice now with just the existing /var factory, and a new
option to opt out of it.

Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
---
 system/Config.in | 21 ++++++++++++++++++---
 1 file changed, 18 insertions(+), 3 deletions(-)

diff --git a/system/Config.in b/system/Config.in
index 806a747315..074fda509c 100644
--- a/system/Config.in
+++ b/system/Config.in
@@ -156,10 +156,16 @@ endchoice
 
 if BR2_INIT_SYSTEMD
 
-config BR2_INIT_SYSTEMD_VAR_FACTORY
-	bool "build a factory to populate a tmpfs on /var"
-	default y  # legacy
+choice
+	bool "/var management"
+	default BR2_INIT_SYSTEMD_VAR_FACTORY  # legacy
 	depends on !BR2_TARGET_GENERIC_REMOUNT_ROOTFS_RW
+	help
+	  Select how Buildroot provides a read-write /var when the
+	  rootfs is not remounted read-write.
+
+config BR2_INIT_SYSTEMD_VAR_FACTORY
+	bool "build a factory to populate a tmpfs"
 	help
 	  Build a factory of the content of /var as installed by
 	  packages, mount a tmpfs on /var at runtime, so that
@@ -181,6 +187,15 @@ config BR2_INIT_SYSTEMD_VAR_FACTORY
 	  var.mount unit, that overrides the What and Type, and possibly
 	  the Options and After, fields.
 
+config BR2_INIT_SYSTEMD_VAR_CUSTOM
+	bool "something else"
+	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.
+
+endchoice
+
 config BR2_INIT_SYSTEMD_POPULATE_TMPFILES
 	bool "trigger systemd-tmpfiles during build"
 	default y  # legacy
-- 
2.25.1


_________________________________________________________________________________________________________________________

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.

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

[Buildroot] [PATCH 6/6 v3] system: add option to use an overlayfs on /var on a r/o root w/ systemd

[yann.morin]

While the /var factory seems to be working in most cases, there have
been suggestions that it may be slightly and subtely borken in some
(rare? edge?) cases, especially about symlinks.

An other solution is to pre-populate /var at build time, by way of
calling systemd-tmpfiles, and mounting an overlayfs on-top of it at
runtime.

This is slightly accrobatic, though, and requires a few hoops:
  - first, we create a tmpfs
  - there, we create three directories:
    - the first to bind-mount /var as it is, i.e. read-only
    - the second as the read-write upper for the overlayfs
    - the third as the "working area" for the overlays

This is done with two systemd units:
  - rootfs-bindmount-var.service: prepares up to bind-mounting /var into
    the tmpfs
  - var.mount: a mount unit which actually mounts the overlayfs.

Users who want to provide an actual storage to keep /var across reboots,
will have to provide their own mount units and make it RequiredBy and
BoundBy our var.mount unit.

Systemd units courtesy Norbert, with slight tweaks and cleanups.

Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
Cc: Norbert Lange <nolange79@gmail.com>
Cc: Romain Naour <romain.naour@smile.fr>
Cc: Jérémy Rosen <jeremy.rosen@smile.fr>
---
 .../{ => factory}/var.mount                   |  0
 .../overlayfs/rootfs-bindmount-var.service    | 21 ++++++++++++++++
 .../skeleton-init-systemd/overlayfs/var.mount | 15 ++++++++++++
 .../skeleton-init-systemd.mk                  | 20 +++++++++++++---
 system/Config.in                              | 24 +++++++++++++------
 5 files changed, 70 insertions(+), 10 deletions(-)
 rename package/skeleton-init-systemd/{ => factory}/var.mount (100%)
 create mode 100644 package/skeleton-init-systemd/overlayfs/rootfs-bindmount-var.service
 create mode 100644 package/skeleton-init-systemd/overlayfs/var.mount

diff --git a/package/skeleton-init-systemd/var.mount b/package/skeleton-init-systemd/factory/var.mount
similarity index 100%
rename from package/skeleton-init-systemd/var.mount
rename to package/skeleton-init-systemd/factory/var.mount
diff --git a/package/skeleton-init-systemd/overlayfs/rootfs-bindmount-var.service b/package/skeleton-init-systemd/overlayfs/rootfs-bindmount-var.service
new file mode 100644
index 0000000000..e412a56c49
--- /dev/null
+++ b/package/skeleton-init-systemd/overlayfs/rootfs-bindmount-var.service
@@ -0,0 +1,21 @@
+[Unit]
+Description=Bind-mount variable storage (/var)
+Documentation=man:file-hierarchy(7)
+ConditionPathIsSymbolicLink=!/var
+# ConditionPathIsReadWrite=!/var
+DefaultDependencies=no
+Conflicts=umount.target
+Before=local-fs.target umount.target
+After=local-fs-pre.target
+
+[Service]
+Type=oneshot
+RemainAfterExit=yes
+ExecStartPre=-/bin/mkdir /run/varoverlay
+ExecStartPre=/bin/mount --make-private -n -t tmpfs tmpfs_root_ovl /run/varoverlay
+ExecStartPre=/bin/mkdir /run/varoverlay/lower /run/varoverlay/upper /run/varoverlay/work
+ExecStart=/bin/mount --make-private -n --bind /var /run/varoverlay/lower
+
+ExecStop=/bin/umount -n /run/varoverlay/lower
+ExecStopPost=/bin/umount -n /run/varoverlay
+ExecStopPost=/bin/rmdir /run/varoverlay
diff --git a/package/skeleton-init-systemd/overlayfs/var.mount b/package/skeleton-init-systemd/overlayfs/var.mount
new file mode 100644
index 0000000000..fab223c27b
--- /dev/null
+++ b/package/skeleton-init-systemd/overlayfs/var.mount
@@ -0,0 +1,15 @@
+[Unit]
+Description=variable storage (/var)
+Documentation=man:file-hierarchy(7)
+ConditionPathIsSymbolicLink=!/var
+After=rootfs-bindmount-var.service
+BindsTo=rootfs-bindmount-var.service
+
+[Mount]
+What=overlay_var
+Where=/var
+Type=overlay
+Options=lowerdir=/run/varoverlay/lower,upperdir=/run/varoverlay/upper,workdir=/run/varoverlay/work,redirect_dir=on,index=on,xino=on
+
+[Install]
+WantedBy=local-fs.target
diff --git a/package/skeleton-init-systemd/skeleton-init-systemd.mk b/package/skeleton-init-systemd/skeleton-init-systemd.mk
index 69991265a5..07a4180db0 100644
--- a/package/skeleton-init-systemd/skeleton-init-systemd.mk
+++ b/package/skeleton-init-systemd/skeleton-init-systemd.mk
@@ -33,7 +33,7 @@ define SKELETON_INIT_SYSTEMD_ROOT_RO_OR_RW
 endef
 
 ifeq ($(BR2_INIT_SYSTEMD_VAR_FACTORY),y)
-define SKELETON_INIT_SYSTEMD_PRE_ROOTFS_VAR
+define SKELETON_INIT_SYSTEMD_PRE_ROOTFS_VAR_FACTORY
 	rm -rf $(TARGET_DIR)/usr/share/factory/var
 	mv $(TARGET_DIR)/var $(TARGET_DIR)/usr/share/factory/var
 	mkdir -p $(TARGET_DIR)/var
@@ -52,11 +52,25 @@ define SKELETON_INIT_SYSTEMD_PRE_ROOTFS_VAR
 			|| exit 1; \
 		fi; \
 	done >$(TARGET_DIR)/usr/lib/tmpfiles.d/buildroot-factory.conf
-	$(INSTALL) -D -m 0644 $(SKELETON_INIT_SYSTEMD_PKGDIR)/var.mount \
+	$(INSTALL) -D -m 0644 $(SKELETON_INIT_SYSTEMD_PKGDIR)/factory/var.mount \
 		$(TARGET_DIR)/usr/lib/systemd/system/var.mount
 endef
-SKELETON_INIT_SYSTEMD_ROOTFS_PRE_CMD_HOOKS += SKELETON_INIT_SYSTEMD_PRE_ROOTFS_VAR
+SKELETON_INIT_SYSTEMD_ROOTFS_PRE_CMD_HOOKS += SKELETON_INIT_SYSTEMD_PRE_ROOTFS_VAR_FACTORY
 endif  # BR2_INIT_SYSTEMD_VAR_FACTORY
+
+ifeq ($(BR2_INIT_SYSTEMD_VAR_OVERLAYFS),y)
+define SKELETON_INIT_SYSTEMD_LINUX_CONFIG_FIXUPS
+	$(call KCONFIG_ENABLE_OPT,CONFIG_OVERLAY_FS)
+endef
+define SKELETON_INIT_SYSTEMD_PRE_ROOTFS_VAR_OVERLAYFS
+	$(INSTALL) -D -m 0644 $(SKELETON_INIT_SYSTEMD_PKGDIR)/overlayfs/var.mount \
+		$(TARGET_DIR)/usr/lib/systemd/system/var.mount
+	$(INSTALL) -D -m 0644 $(SKELETON_INIT_SYSTEMD_PKGDIR)/overlayfs/rootfs-bindmount-var.service \
+		$(TARGET_DIR)/usr/lib/systemd/system/rootfs-bindmount-var.service
+endef
+SKELETON_INIT_SYSTEMD_ROOTFS_PRE_CMD_HOOKS += SKELETON_INIT_SYSTEMD_PRE_ROOTFS_VAR_OVERLAYFS
+endif  # BR2_INIT_SYSTEMD_VAR_OVERLAYFS
+
 endif  # BR2_TARGET_GENERIC_REMOUNT_ROOTFS_RW
 
 ifeq ($(BR2_INIT_SYSTEMD_POPULATE_TMPFILES),y)
diff --git a/system/Config.in b/system/Config.in
index 074fda509c..0c064b8211 100644
--- a/system/Config.in
+++ b/system/Config.in
@@ -164,6 +164,14 @@ choice
 	  Select how Buildroot provides a read-write /var when the
 	  rootfs is not remounted read-write.
 
+	  Note: Buildroot uses a tmpfs, either as a mount point or as
+	  the upper of an overlayfs, so as to at least make the system
+	  bootable out of the box; mounting a filesystem from actual
+	  storage is left to the integration, as it is too specific and
+	  may need preparatory work like partitionning a device and/or
+	  formatting a filesystem first, which falls out of the scope
+	  of Buildroot.
+
 config BR2_INIT_SYSTEMD_VAR_FACTORY
 	bool "build a factory to populate a tmpfs"
 	help
@@ -176,17 +184,19 @@ config BR2_INIT_SYSTEMD_VAR_FACTORY
 	  It probably does not play very well with triggering a call
 	  to systemd-tmpfiles at build time (below).
 
-	  Note: Buildroot mounts a tmpfs on /var to at least make the
-	  system bootable out of the box; mounting a filesystem from
-	  actual storage is left to the integration, as it is too
-	  specific and may need preparatory work like partitionning a
-	  device and/or formatting a filesystem first, so that falls
-	  out of the scope of Buildroot.
-
 	  To use persistent storage, provide a systemd dropin for the
 	  var.mount unit, that overrides the What and Type, and possibly
 	  the Options and After, fields.
 
+config BR2_INIT_SYSTEMD_VAR_OVERLAYFS
+	bool "mount an overlayfs backed by a tmpfs"
+	help
+	  Mount an overlayfs on /var, with the upper as a tmpfs.
+
+	  To use a persistent storage, provide your own systemd unit(s)
+	  that eventually mount that persistent storage on
+	  /run/varoverlay/upper/
+
 config BR2_INIT_SYSTEMD_VAR_CUSTOM
 	bool "something else"
 	help
-- 
2.25.1


_________________________________________________________________________________________________________________________

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.

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 6/6 v3] system: add option to use an overlayfs on /var on a r/o root w/ systemd

[Norbert Lange]

Am Di., 18. Okt. 2022 um 21:43 Uhr schrieb <yann.morin@orange.com>:
>
> While the /var factory seems to be working in most cases, there have
> been suggestions that it may be slightly and subtely borken in some
> (rare? edge?) cases, especially about symlinks.

Had to dig up an old post of mine (not the only one touching on that),
some issues are:

-   it kills previous files in /usr/share/factory/var
-   it doesn't handle symlinks (just think of /var already containing
a symlink into that factory),
    especially relative ones.
-   it has sideeffects with tmpfile .confs that are ordered before and
touch /var
-   it has sideeffects with other PRE_CMD_HOOKS touching /var

(Post is from mid 2020, so forgive me if my memory is fuzzy,
but I had already practical problems with atleast the last 2 of those).

To me this is just not a robust solution

>
> An other solution is to pre-populate /var at build time, by way of
> calling systemd-tmpfiles, and mounting an overlayfs on-top of it at
> runtime.
>
> This is slightly accrobatic, though, and requires a few hoops:
>   - first, we create a tmpfs
>   - there, we create three directories:
>     - the first to bind-mount /var as it is, i.e. read-only
>     - the second as the read-write upper for the overlayfs
>     - the third as the "working area" for the overlays

..and we depend on overlayfs

>
> This is done with two systemd units:
>   - rootfs-bindmount-var.service: prepares up to bind-mounting /var into
>     the tmpfs
>   - var.mount: a mount unit which actually mounts the overlayfs.
>
> Users who want to provide an actual storage to keep /var across reboots,
> will have to provide their own mount units and make it RequiredBy and
> BoundBy our var.mount unit.
>
> Systemd units courtesy Norbert, with slight tweaks and cleanups.

Yeah, Im not fine with the tweaks to drop the symlink
/usr/lib/systemd/system/var.mount -> ../var.mount
(and the added intstall section)

First in the same local-fs "target" you could mount /etc,
making this a complicated hidden issue, I don't know
when systemd reloads, I believe only after that target.

Second, this should be enabled by default, and
in a way even when /etc is borked/not ready.

If a user really wants to disable the mount, he can mask it.

>
> Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
> Cc: Norbert Lange <nolange79@gmail.com>
> Cc: Romain Naour <romain.naour@smile.fr>
> Cc: Jérémy Rosen <jeremy.rosen@smile.fr>
> ---
>  .../{ => factory}/var.mount                   |  0
>  .../overlayfs/rootfs-bindmount-var.service    | 21 ++++++++++++++++
>  .../skeleton-init-systemd/overlayfs/var.mount | 15 ++++++++++++
>  .../skeleton-init-systemd.mk                  | 20 +++++++++++++---
>  system/Config.in                              | 24 +++++++++++++------
>  5 files changed, 70 insertions(+), 10 deletions(-)
>  rename package/skeleton-init-systemd/{ => factory}/var.mount (100%)
>  create mode 100644 package/skeleton-init-systemd/overlayfs/rootfs-bindmount-var.service
>  create mode 100644 package/skeleton-init-systemd/overlayfs/var.mount
>
> diff --git a/package/skeleton-init-systemd/var.mount b/package/skeleton-init-systemd/factory/var.mount
> similarity index 100%
> rename from package/skeleton-init-systemd/var.mount
> rename to package/skeleton-init-systemd/factory/var.mount
> diff --git a/package/skeleton-init-systemd/overlayfs/rootfs-bindmount-var.service b/package/skeleton-init-systemd/overlayfs/rootfs-bindmount-var.service
> new file mode 100644
> index 0000000000..e412a56c49
> --- /dev/null
> +++ b/package/skeleton-init-systemd/overlayfs/rootfs-bindmount-var.service
> @@ -0,0 +1,21 @@
> +[Unit]
> +Description=Bind-mount variable storage (/var)
> +Documentation=man:file-hierarchy(7)
> +ConditionPathIsSymbolicLink=!/var
> +# ConditionPathIsReadWrite=!/var
> +DefaultDependencies=no
> +Conflicts=umount.target
> +Before=local-fs.target umount.target
> +After=local-fs-pre.target

A am actually considering changing that to:

Before=local-fs-pre.target umount.target
# After=local-fs-pre.target

It does not depend an anything, so no technical reason to order
it after anything. And it is technically a preparation for the
actual local-fs.target.

> +
> +[Service]
> +Type=oneshot
> +RemainAfterExit=yes
> +ExecStartPre=-/bin/mkdir /run/varoverlay
> +ExecStartPre=/bin/mount --make-private -n -t tmpfs tmpfs_root_ovl /run/varoverlay
> +ExecStartPre=/bin/mkdir /run/varoverlay/lower /run/varoverlay/upper /run/varoverlay/work
> +ExecStart=/bin/mount --make-private -n --bind /var /run/varoverlay/lower
> +
> +ExecStop=/bin/umount -n /run/varoverlay/lower
> +ExecStopPost=/bin/umount -n /run/varoverlay
> +ExecStopPost=/bin/rmdir /run/varoverlay
> diff --git a/package/skeleton-init-systemd/overlayfs/var.mount b/package/skeleton-init-systemd/overlayfs/var.mount
> new file mode 100644
> index 0000000000..fab223c27b
> --- /dev/null
> +++ b/package/skeleton-init-systemd/overlayfs/var.mount
> @@ -0,0 +1,15 @@
> +[Unit]
> +Description=variable storage (/var)
> +Documentation=man:file-hierarchy(7)
> +ConditionPathIsSymbolicLink=!/var
> +After=rootfs-bindmount-var.service
> +BindsTo=rootfs-bindmount-var.service
> +
> +[Mount]
> +What=overlay_var
> +Where=/var
> +Type=overlay
> +Options=lowerdir=/run/varoverlay/lower,upperdir=/run/varoverlay/upper,workdir=/run/varoverlay/work,redirect_dir=on,index=on,xino=on
> +
> +[Install]
> +WantedBy=local-fs.target

See above.

> diff --git a/package/skeleton-init-systemd/skeleton-init-systemd.mk b/package/skeleton-init-systemd/skeleton-init-systemd.mk
> index 69991265a5..07a4180db0 100644
> --- a/package/skeleton-init-systemd/skeleton-init-systemd.mk
> +++ b/package/skeleton-init-systemd/skeleton-init-systemd.mk
> @@ -33,7 +33,7 @@ define SKELETON_INIT_SYSTEMD_ROOT_RO_OR_RW
>  endef
>
>  ifeq ($(BR2_INIT_SYSTEMD_VAR_FACTORY),y)
> -define SKELETON_INIT_SYSTEMD_PRE_ROOTFS_VAR
> +define SKELETON_INIT_SYSTEMD_PRE_ROOTFS_VAR_FACTORY
>         rm -rf $(TARGET_DIR)/usr/share/factory/var
>         mv $(TARGET_DIR)/var $(TARGET_DIR)/usr/share/factory/var
>         mkdir -p $(TARGET_DIR)/var
> @@ -52,11 +52,25 @@ define SKELETON_INIT_SYSTEMD_PRE_ROOTFS_VAR
>                         || exit 1; \
>                 fi; \
>         done >$(TARGET_DIR)/usr/lib/tmpfiles.d/buildroot-factory.conf
> -       $(INSTALL) -D -m 0644 $(SKELETON_INIT_SYSTEMD_PKGDIR)/var.mount \
> +       $(INSTALL) -D -m 0644 $(SKELETON_INIT_SYSTEMD_PKGDIR)/factory/var.mount \
>                 $(TARGET_DIR)/usr/lib/systemd/system/var.mount
>  endef
> -SKELETON_INIT_SYSTEMD_ROOTFS_PRE_CMD_HOOKS += SKELETON_INIT_SYSTEMD_PRE_ROOTFS_VAR
> +SKELETON_INIT_SYSTEMD_ROOTFS_PRE_CMD_HOOKS += SKELETON_INIT_SYSTEMD_PRE_ROOTFS_VAR_FACTORY
>  endif  # BR2_INIT_SYSTEMD_VAR_FACTORY
> +
> +ifeq ($(BR2_INIT_SYSTEMD_VAR_OVERLAYFS),y)
> +define SKELETON_INIT_SYSTEMD_LINUX_CONFIG_FIXUPS
> +       $(call KCONFIG_ENABLE_OPT,CONFIG_OVERLAY_FS)
> +endef
> +define SKELETON_INIT_SYSTEMD_PRE_ROOTFS_VAR_OVERLAYFS
> +       $(INSTALL) -D -m 0644 $(SKELETON_INIT_SYSTEMD_PKGDIR)/overlayfs/var.mount \
> +               $(TARGET_DIR)/usr/lib/systemd/system/var.mount
> +       $(INSTALL) -D -m 0644 $(SKELETON_INIT_SYSTEMD_PKGDIR)/overlayfs/rootfs-bindmount-var.service \
> +               $(TARGET_DIR)/usr/lib/systemd/system/rootfs-bindmount-var.service
> +endef
> +SKELETON_INIT_SYSTEMD_ROOTFS_PRE_CMD_HOOKS += SKELETON_INIT_SYSTEMD_PRE_ROOTFS_VAR_OVERLAYFS
> +endif  # BR2_INIT_SYSTEMD_VAR_OVERLAYFS
> +
>  endif  # BR2_TARGET_GENERIC_REMOUNT_ROOTFS_RW
>
>  ifeq ($(BR2_INIT_SYSTEMD_POPULATE_TMPFILES),y)
> diff --git a/system/Config.in b/system/Config.in
> index 074fda509c..0c064b8211 100644
> --- a/system/Config.in
> +++ b/system/Config.in
> @@ -164,6 +164,14 @@ choice
>           Select how Buildroot provides a read-write /var when the
>           rootfs is not remounted read-write.
>
> +         Note: Buildroot uses a tmpfs, either as a mount point or as
> +         the upper of an overlayfs, so as to at least make the system
> +         bootable out of the box; mounting a filesystem from actual
> +         storage is left to the integration, as it is too specific and
> +         may need preparatory work like partitionning a device and/or
> +         formatting a filesystem first, which falls out of the scope
> +         of Buildroot.
> +
>  config BR2_INIT_SYSTEMD_VAR_FACTORY
>         bool "build a factory to populate a tmpfs"
>         help
> @@ -176,17 +184,19 @@ config BR2_INIT_SYSTEMD_VAR_FACTORY
>           It probably does not play very well with triggering a call
>           to systemd-tmpfiles at build time (below).
>
> -         Note: Buildroot mounts a tmpfs on /var to at least make the
> -         system bootable out of the box; mounting a filesystem from
> -         actual storage is left to the integration, as it is too
> -         specific and may need preparatory work like partitionning a
> -         device and/or formatting a filesystem first, so that falls
> -         out of the scope of Buildroot.
> -
>           To use persistent storage, provide a systemd dropin for the
>           var.mount unit, that overrides the What and Type, and possibly
>           the Options and After, fields.
>
> +config BR2_INIT_SYSTEMD_VAR_OVERLAYFS
> +       bool "mount an overlayfs backed by a tmpfs"
> +       help
> +         Mount an overlayfs on /var, with the upper as a tmpfs.
> +
> +         To use a persistent storage, provide your own systemd unit(s)
> +         that eventually mount that persistent storage on
> +         /run/varoverlay/upper/

perhaps pull in or depend on overlayfs here

> +
>  config BR2_INIT_SYSTEMD_VAR_CUSTOM
>         bool "something else"
>         help
> --
> 2.25.1
>
>
> _________________________________________________________________________________________________________________________
>
> 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.
>

Generally the unit and directory names could be more logical,
and for allowing the user to specify a custom mount
by reading an EnvironmentFile in the rootfs-bindmount-var unit.

Regards, Norbert

[1] http://lists.busybox.net/pipermail/buildroot/2020-July/287016.html

PS.
Planning to add some more comments next week, should find dome time here,
huge commit msgs to get through.
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 6/6 v3] system: add option to use an overlayfs on /var on a r/o root w/ systemd

[yann.morin]

Norbert, All,

Thank you for your feedback! :-)

On 2022-10-23 23:47 +0200, Norbert Lange spake thusly:
> Am Di., 18. Okt. 2022 um 21:43 Uhr schrieb <yann.morin@orange.com>:
> > While the /var factory seems to be working in most cases, there have
> > been suggestions that it may be slightly and subtely borken in some
> > (rare? edge?) cases, especially about symlinks.
> 
> Had to dig up an old post of mine (not the only one touching on that),
> some issues are:
> 
> -   it kills previous files in /usr/share/factory/var
> -   it doesn't handle symlinks (just think of /var already containing
> a symlink into that factory),
>     especially relative ones.
> -   it has sideeffects with tmpfile .confs that are ordered before and
> touch /var
> -   it has sideeffects with other PRE_CMD_HOOKS touching /var
> 
> (Post is from mid 2020, so forgive me if my memory is fuzzy,
> but I had already practical problems with atleast the last 2 of those).

Forgive me if my memory is fuzzy, but I don't recall seeing any patch to
fix those issues with the factory... ;-)

> To me this is just not a robust solution

Yet, there are some people for whom the factory does work just fine
(first-hand experience here, and besides your comments, we have had
noone reporting actual issues in the 5+ years we've implemented the
factory, AFAICR). So, we do not want to break the situation for them.

Once the overlayfs scheme has been in place for some time and it got
exercised, we can consider switching the default, and eventualy we can
get rid of the factory if it proves to be unfixable (again, without
concrete examples that do break it, we can devise a fix).

If we can't yet agree on how to integrate the overlayfs based scheme, we
need a way to sort out the conflict between the factory and running
tmpfiles at build time, which is what patches 1-4 are for, since they do
not change the current behaviour, but clarifies the current situation.

So, those are the patches where we should concentrate for now.

Patches 5-6 introduce the new overlayfs scheme as an alternative to the
factory, a new feature, so they can go in later...

And yes, I did test the overlayfs scheme in our use-case here, and yes
it does work as advertised, so yes, this is a good feature!

> > An other solution is to pre-populate /var at build time, by way of
> > calling systemd-tmpfiles, and mounting an overlayfs on-top of it at
> > runtime.
> >
> > This is slightly accrobatic, though, and requires a few hoops:
> >   - first, we create a tmpfs
> >   - there, we create three directories:
> >     - the first to bind-mount /var as it is, i.e. read-only
> >     - the second as the read-write upper for the overlayfs
> >     - the third as the "working area" for the overlays
> ..and we depend on overlayfs

I just had to enable overlayfs in the kernel, and it worked without any
other package.

FTR, I have added new runtime tests to validate both the factory and
the overlayfs scenarii. I will post them in the coming days when I've
cleaned them up (have to run locally, as my gtilab free minutes are
exhausted):

    https://gitlab.com/ymorin/buildroot/-/tree/systemdify-var

[--SNIP--]
> > Systemd units courtesy Norbert, with slight tweaks and cleanups.
> 
> Yeah, Im not fine with the tweaks to drop the symlink
> /usr/lib/systemd/system/var.mount -> ../var.mount
> (and the added intstall section)
> 
> First in the same local-fs "target" you could mount /etc,
> making this a complicated hidden issue, I don't know
> when systemd reloads, I believe only after that target.
> 
> Second, this should be enabled by default, and
> in a way even when /etc is borked/not ready.

So, currently, Buildroot does not work (does nothing to officialy work)
seemlessly with an empty /etc, because we explicitly run "systemctl
preset-all" at the end of the build (as a prefs_cmd), and that fills in
/etc/systemd/system/.

As you said, supporting an empty /etc will require *way* more explicit
support in Buildroot

> If a user really wants to disable the mount, he can mask it.

That is true if using either the symlink or the install section, no?
I.e. they'd just provide a preset that reads:

    disable rootfs-bindount-var.service
    disable var.mount

> > Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
> > Cc: Norbert Lange <nolange79@gmail.com>
> > Cc: Romain Naour <romain.naour@smile.fr>
> > Cc: Jérémy Rosen <jeremy.rosen@smile.fr>
[--SNIP--]
> > --- /dev/null
> > +++ b/package/skeleton-init-systemd/overlayfs/rootfs-bindmount-var.service
> > @@ -0,0 +1,21 @@
> > +[Unit]
> > +Description=Bind-mount variable storage (/var)
> > +Documentation=man:file-hierarchy(7)
> > +ConditionPathIsSymbolicLink=!/var
> > +# ConditionPathIsReadWrite=!/var
> > +DefaultDependencies=no
> > +Conflicts=umount.target
> > +Before=local-fs.target umount.target
> > +After=local-fs-pre.target
> 
> A am actually considering changing that to:
> 
> Before=local-fs-pre.target umount.target
> # After=local-fs-pre.target

No reason to keep comment in units.

> It does not depend an anything,

It does depend on /run being mounted.

> so no technical reason to order
> it after anything. And it is technically a preparation for the
> actual local-fs.target.

This.

We do not have a vision of the grand scheme of how systemd organises
stuff, what each .target means and how they depend on each others. Maybe
my search skills are getting rusted as time passes, but I could never
find such a design doc, and it lacks sorely. Manpages are only so good
as to explain each details, but they do not provide a global overview...

[--SNIP--]
> > +config BR2_INIT_SYSTEMD_VAR_OVERLAYFS
> > +       bool "mount an overlayfs backed by a tmpfs"
> > +       help
> > +         Mount an overlayfs on /var, with the upper as a tmpfs.
> > +
> > +         To use a persistent storage, provide your own systemd unit(s)
> > +         that eventually mount that persistent storage on
> > +         /run/varoverlay/upper/
> perhaps pull in or depend on overlayfs here

I did not need anything beside enabling overlayfs in the kernel (see the
runtime tests branch I pointed to above).

> Generally the unit and directory names could be more logical,

Yes, I agree that we should have a kind of naming scheme for this. But I
have no good idea...

What I was thinking, though, is that we maybe should make dotted
directories, i.e. /run/.varoverlay/{lower,upper,work}

> and for allowing the user to specify a custom mount
> by reading an EnvironmentFile in the rootfs-bindmount-var unit.

It was my understanding that users could provide their own unit(s),
something that would ultimately end up with a mount unit like:

    # cat run_varoverlay_upper.mount
    [Unit]
    After=rootfs-bindmount-var.service
    BindsTo=rootfs-bindmount-var.service

    [Mount]
    What=/dev/something
    Where=/run/varoverlay/upper
    Type=ext4-or-whatever

    [Install]
    BoundBy=var.mount
    WantedBy=var.mount

That way, they do not have to override any of our units; they would just
intersperse their unit in the existing dependency graph, between the
rootfs-bindmount-var.service and the var.mount.

And the content of the filesystem on /dev/something would only get the
content of /var, not the {lower,upper,work} directories, which could be
a bit confusing.

> Planning to add some more comments next week, should find dome time here,
> huge commit msgs to get through.

Commit messages are important, because they do provide all the rationale
and reasoning behind a change. They will be there forever, and in the
future, we can refer to them to understand why the code eneded up like
it is, and with new insight then, we can understand where our reasoning
was flawed, or if it was correct, how the environment around has
changed.

I consider a good commit log more important than the actual change.

Regards,
Yann E. MORIN.

-- 
                                        ____________
.-----------------.--------------------:       _    :------------------.
|  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.

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 6/6 v3] system: add option to use an overlayfs on /var on a r/o root w/ systemd

[Norbert Lange]

Am Di., 25. Okt. 2022 um 10:08 Uhr schrieb <yann.morin@orange.com>:
>
> Norbert, All,
>
> Thank you for your feedback! :-)
>
> On 2022-10-23 23:47 +0200, Norbert Lange spake thusly:
> > Am Di., 18. Okt. 2022 um 21:43 Uhr schrieb <yann.morin@orange.com>:
> > > While the /var factory seems to be working in most cases, there have
> > > been suggestions that it may be slightly and subtely borken in some
> > > (rare? edge?) cases, especially about symlinks.
> >
> > Had to dig up an old post of mine (not the only one touching on that),
> > some issues are:
> >
> > -   it kills previous files in /usr/share/factory/var
> > -   it doesn't handle symlinks (just think of /var already containing
> > a symlink into that factory),
> >     especially relative ones.
> > -   it has sideeffects with tmpfile .confs that are ordered before and
> > touch /var
> > -   it has sideeffects with other PRE_CMD_HOOKS touching /var
> >
> > (Post is from mid 2020, so forgive me if my memory is fuzzy,
> > but I had already practical problems with atleast the last 2 of those).
>
> Forgive me if my memory is fuzzy, but I don't recall seeing any patch to
> fix those issues with the factory... ;-)

I am not sure a complete fix for the factory would be a computable problem,
know the implementation then you can "break it".
there are way simpler solutions for "make a copy of that stuff".

>
> > To me this is just not a robust solution
>
> Yet, there are some people for whom the factory does work just fine
> (first-hand experience here, and besides your comments, we have had
> noone reporting actual issues in the 5+ years we've implemented the
> factory, AFAICR). So, we do not want to break the situation for them.
>
> Once the overlayfs scheme has been in place for some time and it got
> exercised, we can consider switching the default, and eventualy we can
> get rid of the factory if it proves to be unfixable (again, without
> concrete examples that do break it, we can devise a fix).

Thats a sunken cost fallacy ;)

>
> If we can't yet agree on how to integrate the overlayfs based scheme, we
> need a way to sort out the conflict between the factory and running
> tmpfiles at build time, which is what patches 1-4 are for, since they do
> not change the current behaviour, but clarifies the current situation.
>
> So, those are the patches where we should concentrate for now.
>
> Patches 5-6 introduce the new overlayfs scheme as an alternative to the
> factory, a new feature, so they can go in later...
>
> And yes, I did test the overlayfs scheme in our use-case here, and yes
> it does work as advertised, so yes, this is a good feature!

Glad to hear, I am going to clean it up a bit

>
> > > An other solution is to pre-populate /var at build time, by way of
> > > calling systemd-tmpfiles, and mounting an overlayfs on-top of it at
> > > runtime.
> > >
> > > This is slightly accrobatic, though, and requires a few hoops:
> > >   - first, we create a tmpfs
> > >   - there, we create three directories:
> > >     - the first to bind-mount /var as it is, i.e. read-only
> > >     - the second as the read-write upper for the overlayfs
> > >     - the third as the "working area" for the overlays
> > ..and we depend on overlayfs
>
> I just had to enable overlayfs in the kernel, and it worked without any
> other package.

I meant its no option if the kernel does not provide the overlayfs,
which would be an argument against it.

>
> FTR, I have added new runtime tests to validate both the factory and
> the overlayfs scenarii. I will post them in the coming days when I've
> cleaned them up (have to run locally, as my gtilab free minutes are
> exhausted):
>
>     https://gitlab.com/ymorin/buildroot/-/tree/systemdify-var
>
> [--SNIP--]
> > > Systemd units courtesy Norbert, with slight tweaks and cleanups.
> >
> > Yeah, Im not fine with the tweaks to drop the symlink
> > /usr/lib/systemd/system/var.mount -> ../var.mount
> > (and the added intstall section)
> >
> > First in the same local-fs "target" you could mount /etc,
> > making this a complicated hidden issue, I don't know
> > when systemd reloads, I believe only after that target.
> >
> > Second, this should be enabled by default, and
> > in a way even when /etc is borked/not ready.
>
> So, currently, Buildroot does not work (does nothing to officialy work)
> seemlessly with an empty /etc, because we explicitly run "systemctl
> preset-all" at the end of the build (as a prefs_cmd), and that fills in
> /etc/systemd/system/.
>
> As you said, supporting an empty /etc will require *way* more explicit
> support in Buildroot

It helps if there arent any additional blocks in the way, systemd
envisions your rootfs "master" to live under /usr.
Key services should be statically linked (like for ex. the dbus.socket).

> > If a user really wants to disable the mount, he can mask it.
>
> That is true if using either the symlink or the install section, no?
> I.e. they'd just provide a preset that reads:
>
>     disable rootfs-bindount-var.service
>     disable var.mount

Yeah, it should be a "hard" default. And not affected by the usuall
en/disable/preset
operations.
the mask/unmask operations are the "hard" stuff.

Lets turn it around: what arguments can you muster
for using the install functionality?

>
> > > Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
> > > Cc: Norbert Lange <nolange79@gmail.com>
> > > Cc: Romain Naour <romain.naour@smile.fr>
> > > Cc: Jérémy Rosen <jeremy.rosen@smile.fr>
> [--SNIP--]
> > > --- /dev/null
> > > +++ b/package/skeleton-init-systemd/overlayfs/rootfs-bindmount-var.service
> > > @@ -0,0 +1,21 @@
> > > +[Unit]
> > > +Description=Bind-mount variable storage (/var)
> > > +Documentation=man:file-hierarchy(7)
> > > +ConditionPathIsSymbolicLink=!/var
> > > +# ConditionPathIsReadWrite=!/var
> > > +DefaultDependencies=no
> > > +Conflicts=umount.target
> > > +Before=local-fs.target umount.target
> > > +After=local-fs-pre.target
> >
> > A am actually considering changing that to:
> >
> > Before=local-fs-pre.target umount.target
> > # After=local-fs-pre.target
>
> No reason to keep comment in units.

For displaying the change, expect a series from me later.

>
> > It does not depend an anything,
>
> It does depend on /run being mounted.

Which is a *given invariant* with systemd, one
of the first things that happen.

>
> > so no technical reason to order
> > it after anything. And it is technically a preparation for the
> > actual local-fs.target.
>
> This.
>
> We do not have a vision of the grand scheme of how systemd organises
> stuff, what each .target means and how they depend on each others. Maybe
> my search skills are getting rusted as time passes, but I could never
> find such a design doc, and it lacks sorely. Manpages are only so good
> as to explain each details, but they do not provide a global overview...

Like that? :
https://www.freedesktop.org/software/systemd/man/bootup.html

>
> [--SNIP--]
> > > +config BR2_INIT_SYSTEMD_VAR_OVERLAYFS
> > > +       bool "mount an overlayfs backed by a tmpfs"
> > > +       help
> > > +         Mount an overlayfs on /var, with the upper as a tmpfs.
> > > +
> > > +         To use a persistent storage, provide your own systemd unit(s)
> > > +         that eventually mount that persistent storage on
> > > +         /run/varoverlay/upper/
> > perhaps pull in or depend on overlayfs here
>
> I did not need anything beside enabling overlayfs in the kernel (see the
> runtime tests branch I pointed to above).
>
> > Generally the unit and directory names could be more logical,
>
> Yes, I agree that we should have a kind of naming scheme for this. But I
> have no good idea...
>
> What I was thinking, though, is that we maybe should make dotted
> directories, i.e. /run/.varoverlay/{lower,upper,work}

id namespace it like /run/.buildroot/overlay_var_{lower,upper,work}.

>
> > and for allowing the user to specify a custom mount
> > by reading an EnvironmentFile in the rootfs-bindmount-var unit.
>
> It was my understanding that users could provide their own unit(s),
> something that would ultimately end up with a mount unit like:
>
>     # cat run_varoverlay_upper.mount
>     [Unit]
>     After=rootfs-bindmount-var.service
>     BindsTo=rootfs-bindmount-var.service
>
>     [Mount]
>     What=/dev/something
>     Where=/run/varoverlay/upper
>     Type=ext4-or-whatever
>
>     [Install]
>     BoundBy=var.mount
>     WantedBy=var.mount
>
> That way, they do not have to override any of our units; they would just
> intersperse their unit in the existing dependency graph, between the
> rootfs-bindmount-var.service and the var.mount.
>
> And the content of the filesystem on /dev/something would only get the
> content of /var, not the {lower,upper,work} directories, which could be
> a bit confusing.

Yeah, I havent thought about a customizing. Not sure if it wouldnt be better
to provide a simple one and a customizable one.

ie. the simple one doesnt have to wait for udev, loaded kernel modules
for blockdevices
or network connections to do its job.

>
> > Planning to add some more comments next week, should find dome time here,
> > huge commit msgs to get through.
>
> Commit messages are important, because they do provide all the rationale
> and reasoning behind a change. They will be there forever, and in the
> future, we can refer to them to understand why the code eneded up like
> it is, and with new insight then, we can understand where our reasoning
> was flawed, or if it was correct, how the environment around has
> changed.
>
> I consider a good commit log more important than the actual change.

Wasnt meant as complaint.

Regards, Norbert
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 6/6 v3] system: add option to use an overlayfs on /var on a r/o root w/ systemd

[Norbert Lange]

Am Di., 25. Okt. 2022 um 14:12 Uhr schrieb Norbert Lange <nolange79@gmail.com>:
>
> Am Di., 25. Okt. 2022 um 10:08 Uhr schrieb <yann.morin@orange.com>:
> >
> > Norbert, All,
> >
> > Thank you for your feedback! :-)
> >
> > On 2022-10-23 23:47 +0200, Norbert Lange spake thusly:
> > > Am Di., 18. Okt. 2022 um 21:43 Uhr schrieb <yann.morin@orange.com>:
> > > > While the /var factory seems to be working in most cases, there have
> > > > been suggestions that it may be slightly and subtely borken in some
> > > > (rare? edge?) cases, especially about symlinks.
> > >
> > > Had to dig up an old post of mine (not the only one touching on that),
> > > some issues are:
> > >
> > > -   it kills previous files in /usr/share/factory/var
> > > -   it doesn't handle symlinks (just think of /var already containing
> > > a symlink into that factory),
> > >     especially relative ones.
> > > -   it has sideeffects with tmpfile .confs that are ordered before and
> > > touch /var
> > > -   it has sideeffects with other PRE_CMD_HOOKS touching /var
> > >
> > > (Post is from mid 2020, so forgive me if my memory is fuzzy,
> > > but I had already practical problems with atleast the last 2 of those).
> >
> > Forgive me if my memory is fuzzy, but I don't recall seeing any patch to
> > fix those issues with the factory... ;-)
>
> I am not sure a complete fix for the factory would be a computable problem,
> know the implementation then you can "break it".
> there are way simpler solutions for "make a copy of that stuff".
>
> >
> > > To me this is just not a robust solution
> >
> > Yet, there are some people for whom the factory does work just fine
> > (first-hand experience here, and besides your comments, we have had
> > noone reporting actual issues in the 5+ years we've implemented the
> > factory, AFAICR). So, we do not want to break the situation for them.
> >
> > Once the overlayfs scheme has been in place for some time and it got
> > exercised, we can consider switching the default, and eventualy we can
> > get rid of the factory if it proves to be unfixable (again, without
> > concrete examples that do break it, we can devise a fix).
>
> Thats a sunken cost fallacy ;)
>
> >
> > If we can't yet agree on how to integrate the overlayfs based scheme, we
> > need a way to sort out the conflict between the factory and running
> > tmpfiles at build time, which is what patches 1-4 are for, since they do
> > not change the current behaviour, but clarifies the current situation.
> >
> > So, those are the patches where we should concentrate for now.
> >
> > Patches 5-6 introduce the new overlayfs scheme as an alternative to the
> > factory, a new feature, so they can go in later...
> >
> > And yes, I did test the overlayfs scheme in our use-case here, and yes
> > it does work as advertised, so yes, this is a good feature!
>
> Glad to hear, I am going to clean it up a bit
>
> >
> > > > An other solution is to pre-populate /var at build time, by way of
> > > > calling systemd-tmpfiles, and mounting an overlayfs on-top of it at
> > > > runtime.
> > > >
> > > > This is slightly accrobatic, though, and requires a few hoops:
> > > >   - first, we create a tmpfs
> > > >   - there, we create three directories:
> > > >     - the first to bind-mount /var as it is, i.e. read-only
> > > >     - the second as the read-write upper for the overlayfs
> > > >     - the third as the "working area" for the overlays
> > > ..and we depend on overlayfs
> >
> > I just had to enable overlayfs in the kernel, and it worked without any
> > other package.
>
> I meant its no option if the kernel does not provide the overlayfs,
> which would be an argument against it.
>
> >
> > FTR, I have added new runtime tests to validate both the factory and
> > the overlayfs scenarii. I will post them in the coming days when I've
> > cleaned them up (have to run locally, as my gtilab free minutes are
> > exhausted):
> >
> >     https://gitlab.com/ymorin/buildroot/-/tree/systemdify-var
> >
> > [--SNIP--]
> > > > Systemd units courtesy Norbert, with slight tweaks and cleanups.
> > >
> > > Yeah, Im not fine with the tweaks to drop the symlink
> > > /usr/lib/systemd/system/var.mount -> ../var.mount
> > > (and the added intstall section)
> > >
> > > First in the same local-fs "target" you could mount /etc,
> > > making this a complicated hidden issue, I don't know
> > > when systemd reloads, I believe only after that target.
> > >
> > > Second, this should be enabled by default, and
> > > in a way even when /etc is borked/not ready.
> >
> > So, currently, Buildroot does not work (does nothing to officialy work)
> > seemlessly with an empty /etc, because we explicitly run "systemctl
> > preset-all" at the end of the build (as a prefs_cmd), and that fills in
> > /etc/systemd/system/.
> >
> > As you said, supporting an empty /etc will require *way* more explicit
> > support in Buildroot
>
> It helps if there arent any additional blocks in the way, systemd
> envisions your rootfs "master" to live under /usr.
> Key services should be statically linked (like for ex. the dbus.socket).
>
> > > If a user really wants to disable the mount, he can mask it.
> >
> > That is true if using either the symlink or the install section, no?
> > I.e. they'd just provide a preset that reads:
> >
> >     disable rootfs-bindount-var.service
> >     disable var.mount
>
> Yeah, it should be a "hard" default. And not affected by the usuall
> en/disable/preset
> operations.
> the mask/unmask operations are the "hard" stuff.
>
> Lets turn it around: what arguments can you muster
> for using the install functionality?
>
> >
> > > > Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
> > > > Cc: Norbert Lange <nolange79@gmail.com>
> > > > Cc: Romain Naour <romain.naour@smile.fr>
> > > > Cc: Jérémy Rosen <jeremy.rosen@smile.fr>
> > [--SNIP--]
> > > > --- /dev/null
> > > > +++ b/package/skeleton-init-systemd/overlayfs/rootfs-bindmount-var.service
> > > > @@ -0,0 +1,21 @@
> > > > +[Unit]
> > > > +Description=Bind-mount variable storage (/var)
> > > > +Documentation=man:file-hierarchy(7)
> > > > +ConditionPathIsSymbolicLink=!/var
> > > > +# ConditionPathIsReadWrite=!/var
> > > > +DefaultDependencies=no
> > > > +Conflicts=umount.target
> > > > +Before=local-fs.target umount.target
> > > > +After=local-fs-pre.target
> > >
> > > A am actually considering changing that to:
> > >
> > > Before=local-fs-pre.target umount.target
> > > # After=local-fs-pre.target
> >
> > No reason to keep comment in units.
>
> For displaying the change, expect a series from me later.
>
> >
> > > It does not depend an anything,
> >
> > It does depend on /run being mounted.
>
> Which is a *given invariant* with systemd, one
> of the first things that happen.
>
> >
> > > so no technical reason to order
> > > it after anything. And it is technically a preparation for the
> > > actual local-fs.target.
> >
> > This.
> >
> > We do not have a vision of the grand scheme of how systemd organises
> > stuff, what each .target means and how they depend on each others. Maybe
> > my search skills are getting rusted as time passes, but I could never
> > find such a design doc, and it lacks sorely. Manpages are only so good
> > as to explain each details, but they do not provide a global overview...
>
> Like that? :
> https://www.freedesktop.org/software/systemd/man/bootup.html
>
> >
> > [--SNIP--]
> > > > +config BR2_INIT_SYSTEMD_VAR_OVERLAYFS
> > > > +       bool "mount an overlayfs backed by a tmpfs"
> > > > +       help
> > > > +         Mount an overlayfs on /var, with the upper as a tmpfs.
> > > > +
> > > > +         To use a persistent storage, provide your own systemd unit(s)
> > > > +         that eventually mount that persistent storage on
> > > > +         /run/varoverlay/upper/
> > > perhaps pull in or depend on overlayfs here
> >
> > I did not need anything beside enabling overlayfs in the kernel (see the
> > runtime tests branch I pointed to above).
> >
> > > Generally the unit and directory names could be more logical,
> >
> > Yes, I agree that we should have a kind of naming scheme for this. But I
> > have no good idea...
> >
> > What I was thinking, though, is that we maybe should make dotted
> > directories, i.e. /run/.varoverlay/{lower,upper,work}
>
> id namespace it like /run/.buildroot/overlay_var_{lower,upper,work}.
>
> >
> > > and for allowing the user to specify a custom mount
> > > by reading an EnvironmentFile in the rootfs-bindmount-var unit.
> >
> > It was my understanding that users could provide their own unit(s),
> > something that would ultimately end up with a mount unit like:
> >
> >     # cat run_varoverlay_upper.mount
> >     [Unit]
> >     After=rootfs-bindmount-var.service
> >     BindsTo=rootfs-bindmount-var.service
> >
> >     [Mount]
> >     What=/dev/something
> >     Where=/run/varoverlay/upper
> >     Type=ext4-or-whatever
> >
> >     [Install]
> >     BoundBy=var.mount
> >     WantedBy=var.mount
> >
> > That way, they do not have to override any of our units; they would just
> > intersperse their unit in the existing dependency graph, between the
> > rootfs-bindmount-var.service and the var.mount.
> >
> > And the content of the filesystem on /dev/something would only get the
> > content of /var, not the {lower,upper,work} directories, which could be
> > a bit confusing.
>
> Yeah, I havent thought about a customizing. Not sure if it wouldnt be better
> to provide a simple one and a customizable one.
>
> ie. the simple one doesnt have to wait for udev, loaded kernel modules
> for blockdevices
> or network connections to do its job.
>
> >
> > > Planning to add some more comments next week, should find dome time here,
> > > huge commit msgs to get through.
> >
> > Commit messages are important, because they do provide all the rationale
> > and reasoning behind a change. They will be there forever, and in the
> > future, we can refer to them to understand why the code eneded up like
> > it is, and with new insight then, we can understand where our reasoning
> > was flawed, or if it was correct, how the environment around has
> > changed.
> >
> > I consider a good commit log more important than the actual change.
>
> Wasnt meant as complaint.
>
> Regards, Norbert

Im still doctoring with this one, please keep this open for now.

The basic idea would be to denote a few buildroot specific directories
that can be used by multiple units.

/run/.br - small filesystem stuff fitting the run mount
/tmp/.br - filesystem stuff to fat for /run

/run/.br/bnd/* - bind mounts for evil trickery, replicating the
original path (eg /var/hugo is bind mounted to /run/.br/bnd/var/hugo)

Some feedback on where to document this? Anyone else required to look at that?

The /var overlay would end up in /tmp/.br/ovl_var - no additional
tmpfs required.

eg. the mount option would be:
lowerdir=/run/.br/bnd/var,upperdir=/tmp/.br/ovl_var/up,workdir=/tmp/.br/ovl_var/wd

Regards, Norbert
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot