NetCube-Systems-Austria/kumquat-buildroot
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

system: add options for /var factory and tmpfiles pre-seed

Browse Source 
Currently, when one does not enable remounting the rootfs read-write,
i.e. keep it read-only, for example because the filesystem is actually
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, but 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, but 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>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
This commit is contained in:
Yann E. MORIN 2022-10-18 21:43:07 +02:00
parent 0245d30e56
commit 3f79611b30
2 changed files with 46 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

7
package/skeleton-init-systemd/skeleton-init-systemd.mk
View File

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

42
system/Config.in
View File

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