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

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(-)

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