@@ -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
@@ -154,10 +154,44 @@ 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.
+
+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 +199,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
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 | 38 ++++++++++++++++++- 2 files changed, 42 insertions(+), 3 deletions(-)