* [Buildroot] [PATCH 0/7] Extent options for read-only /var handling
@ 2023-01-15 12:52 Norbert Lange
2023-01-15 12:52 ` [Buildroot] [PATCH 1/7] system: introduce a choice for /var management Norbert Lange
` (6 more replies)
0 siblings, 7 replies; 16+ messages in thread
From: Norbert Lange @ 2023-01-15 12:52 UTC (permalink / raw)
To: buildroot; +Cc: Norbert Lange, Yann E . MORIN
This series is based on the work of Yann to allow variants
for handling /var in respect to a read-only rootfs.
It contains a new version to use an overlayfs,
a version using a systemd-generator,
and a few more patches to improve the situation under a read-only root.
Further it tries to establish some buildroot runtime directories,
namely /run/.br and /tmp/.br.
The /run/.br should used for any runtime directories/files that
are specific tu buildroot. Since /run is expected to only contain
a modest amount of content, /tmp/.br is also available for "fatter"
stuff.
Those patches are tested to solve the /var issue while behaving
nicely within systemd and not requiring special processing or
modification of the rootfs.
The patches further allow systemd and its services to boot without
errors, even if /var is plainly read-only.
Norbert Lange (6):
system: add overlayfs option for ro /var
package/skeleton-init-systemd: force permissions for buildroot runtime
dirs
system: add systemd generator for /var
package/skeleton-init-systemd: fix var.mount options
package/systemd: handle creation of /var/log/journal
package/systemd: create the /boot directory
Yann E. MORIN (1):
system: introduce a choice for /var management
.../skeleton-init-systemd/00-buildroot.conf | 7 +++
.../generator/br-mount-generator | 19 ++++++++
.../overlayfs/br-bindmount-run@.service | 26 ++++++++++
.../overlayfs/br-overlay-prepare@.service | 26 ++++++++++
.../overlayfs/overlay.mount.in | 16 +++++++
.../skeleton-init-systemd.mk | 26 ++++++++++
package/skeleton-init-systemd/var.mount | 2 +-
package/systemd/systemd.mk | 8 ++++
system/Config.in | 48 +++++++++++++++++--
9 files changed, 174 insertions(+), 4 deletions(-)
create mode 100644 package/skeleton-init-systemd/00-buildroot.conf
create mode 100755 package/skeleton-init-systemd/generator/br-mount-generator
create mode 100644 package/skeleton-init-systemd/overlayfs/br-bindmount-run@.service
create mode 100644 package/skeleton-init-systemd/overlayfs/br-overlay-prepare@.service
create mode 100644 package/skeleton-init-systemd/overlayfs/overlay.mount.in
--
2.39.0
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Buildroot] [PATCH 1/7] system: introduce a choice for /var management
2023-01-15 12:52 [Buildroot] [PATCH 0/7] Extent options for read-only /var handling Norbert Lange
@ 2023-01-15 12:52 ` Norbert Lange
2023-01-15 12:52 ` [Buildroot] [PATCH 2/7] system: add overlayfs option for ro /var Norbert Lange
` (5 subsequent siblings)
6 siblings, 0 replies; 16+ messages in thread
From: Norbert Lange @ 2023-01-15 12:52 UTC (permalink / raw)
To: buildroot; +Cc: Norbert Lange, Yann E. MORIN, Yann E . MORIN, Romain Naour
From: "Yann E. MORIN" <yann.morin@orange.com>
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>
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>
Acked-by: Norbert Lange <nolange79@gmail.com>
---
system/Config.in | 22 +++++++++++++++++++---
1 file changed, 19 insertions(+), 3 deletions(-)
diff --git a/system/Config.in b/system/Config.in
index 806a747315..87df031545 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,16 @@ 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_NONE
+ bool "do nothing"
+ help
+ Choose this if you have custom dispositions (like one or more
+ of a post-build script, a fakeroot script, systemd units, an
+ initramfs, or something else) 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.39.0
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
^ permalink raw reply related [flat|nested] 16+ messages in thread
* [Buildroot] [PATCH 2/7] system: add overlayfs option for ro /var
2023-01-15 12:52 [Buildroot] [PATCH 0/7] Extent options for read-only /var handling Norbert Lange
2023-01-15 12:52 ` [Buildroot] [PATCH 1/7] system: introduce a choice for /var management Norbert Lange
@ 2023-01-15 12:52 ` Norbert Lange
2023-10-08 18:37 ` Arnout Vandecappelle via buildroot
2023-01-15 12:52 ` [Buildroot] [PATCH 3/7] package/skeleton-init-systemd: force permissions for buildroot runtime dirs Norbert Lange
` (4 subsequent siblings)
6 siblings, 1 reply; 16+ messages in thread
From: Norbert Lange @ 2023-01-15 12:52 UTC (permalink / raw)
To: buildroot
Cc: Norbert Lange, Jérémy Rosen, Yann E . MORIN, Romain Naour
This commit adds an alternative that has the following characteristics:
- Dont depend on anything being available, except the
API File Systems [1].
As /var is meant to be available before normal and even some early
services are running.
- Be a clean drop-in, that can be trivially added / removed.
- Depend on overlayfs being available in the kernel.
- Units are supposed to be reusable for custom solutions.
Further, a few subdirectories are introduced, which hopefully can serve
as template for similar uses.
Buildroot owns /run/.br, bind mounts end up in /run/.br/bnd,
overlay directories in /run/.br/ovl.
The sequence is rather important, and the systemd mount units serve as
reliable "sequence point" (cant be replicated otherwise).
What we need to do is mount /var in its usable state, and block
units depending on this before we are finished.
This includes:
- Other mounts targeting a subdirectory in /var.
- Units using 'RequiresMountsFor' targeting /var or subdirectories.
Most notable `basic.target` which most units depend upon by default.
- Units that are (transitively) odered after one of the above.
As comparison, the /var factory introduces issues here, as
systemd-tmpfiles-setup.service will require all mounts to be finished
before, as well als journald running.
(That means /var will already be used while and before initialization).
The necessary steps are:
1. Bindmount /var to /run/.br/bnd/var
This is done by using the template br-bindmount-run@.service.
2. Mount an tmpfs and prepare the overlay at /run/.br/ovl/var
This is done by using the template br-overlay-prepare@.service,
the mounting command is separated so that users can further
customize the behaviour.
The choice of using a service seems more flexible, as the
mount units lack several options of the mount command.
As a gut feeling the fileystems mounted under /run should
not be accessible or propagate their mounts,
hence --make-private.
(Or you might not use a mount at all).
3. Finally mount the overlay with a normal mount unit
Dependencies on the template-instances of 1. and 2. will ensure
correct odering before.
By nature off being a systemd mount unit the remaining units
will be automatically order after this unit if necessary.
As example, consider using /dev/sdc1 as upper layer for var,
this can be archived by swapping out just the line executing
the mount itself:
[Service]
ExecStart=
ExecStart=/bin/mount --make-private -n /dev/sdc1 ${OVERLAY_DIR}
[1] - https://www.freedesktop.org/wiki/Software/systemd/APIFileSystems/
Cc: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Romain Naour <romain.naour@smile.fr>
Cc: Jérémy Rosen <jeremy.rosen@smile.fr>
Signed-off-by: Norbert Lange <nolange79@gmail.com>
---
.../overlayfs/br-bindmount-run@.service | 26 +++++++++++++++++++
.../overlayfs/br-overlay-prepare@.service | 26 +++++++++++++++++++
.../overlayfs/overlay.mount.in | 16 ++++++++++++
.../skeleton-init-systemd.mk | 17 ++++++++++++
system/Config.in | 13 ++++++++++
5 files changed, 98 insertions(+)
create mode 100644 package/skeleton-init-systemd/overlayfs/br-bindmount-run@.service
create mode 100644 package/skeleton-init-systemd/overlayfs/br-overlay-prepare@.service
create mode 100644 package/skeleton-init-systemd/overlayfs/overlay.mount.in
diff --git a/package/skeleton-init-systemd/overlayfs/br-bindmount-run@.service b/package/skeleton-init-systemd/overlayfs/br-bindmount-run@.service
new file mode 100644
index 0000000000..ce944efd92
--- /dev/null
+++ b/package/skeleton-init-systemd/overlayfs/br-bindmount-run@.service
@@ -0,0 +1,26 @@
+[Unit]
+Description=Bind-mount rootfs directory (/%I) to /run
+Documentation=man:file-hierarchy(7)
+ConditionPathIsSymbolicLink=!/%I
+DefaultDependencies=no
+Conflicts=umount.target
+Before=umount.target
+
+# Needs to run after rootfs is properly mounted
+# and before regular mounts might interfere.
+After=systemd-remount-fs.service
+Before=local-fs-pre.target
+
+[Service]
+Type=oneshot
+RemainAfterExit=yes
+# dont fail if common dirs already exist
+ExecStartPre=/bin/mkdir -m755 -p /run/.br
+ExecStartPre=/bin/mkdir -m700 -p /run/.br/bnd
+
+ExecStartPre=/bin/mkdir -m700 -p /run/.br/bnd/%I
+ExecStart=/bin/mount --make-private -n --bind -o ro /%I /run/.br/bnd/%I
+
+# lazy unmount, dont block shutdown under any circumstances
+ExecStop=/bin/umount -n -l /run/.br/bnd/%I
+ExecStopPost=-/bin/rmdir /run/.br/bnd/%I
diff --git a/package/skeleton-init-systemd/overlayfs/br-overlay-prepare@.service b/package/skeleton-init-systemd/overlayfs/br-overlay-prepare@.service
new file mode 100644
index 0000000000..86b32900dd
--- /dev/null
+++ b/package/skeleton-init-systemd/overlayfs/br-overlay-prepare@.service
@@ -0,0 +1,26 @@
+[Unit]
+Description=Mount and prepare tmpfs for overlay (/%I)
+Documentation=man:file-hierarchy(7)
+ConditionPathIsSymbolicLink=!/%I
+DefaultDependencies=no
+Conflicts=umount.target
+Before=local-fs.target umount.target
+# prepare for systemd mount units aswell
+RequiresMountsFor=/run/.br/ovl/%I
+
+[Service]
+Environment="OVERLAY_DIR=/run/.br/ovl/%I"
+Type=oneshot
+RemainAfterExit=yes
+# dont fail if common dirs already exist
+ExecStartPre=/bin/mkdir -m755 -p /run/.br
+ExecStartPre=/bin/mkdir -m700 -p /run/.br/ovl
+
+ExecStartPre=/bin/mkdir -m700 -p ${OVERLAY_DIR}
+# Create an override and edit this line for customization
+ExecStart=/bin/mount --make-private -n -t tmpfs tmpfs_br_ovl ${OVERLAY_DIR}
+ExecStartPost=/bin/mkdir -p ${OVERLAY_DIR}/up ${OVERLAY_DIR}/wd
+
+# lazy unmount, dont block shutdown under any circumstances
+ExecStop=/bin/umount -n -l ${OVERLAY_DIR}
+ExecStopPost=/bin/rmdir ${OVERLAY_DIR}
diff --git a/package/skeleton-init-systemd/overlayfs/overlay.mount.in b/package/skeleton-init-systemd/overlayfs/overlay.mount.in
new file mode 100644
index 0000000000..84f4d9ee47
--- /dev/null
+++ b/package/skeleton-init-systemd/overlayfs/overlay.mount.in
@@ -0,0 +1,16 @@
+[Unit]
+Description=Variable storage (/@PATH@)
+Documentation=man:file-hierarchy(7)
+ConditionPathIsSymbolicLink=!/@PATH@
+
+After=br-bindmount-run@@PATH@.service
+Requires=br-bindmount-run@@PATH@.service
+
+After=br-overlay-prepare@@PATH@.service
+BindsTo=br-overlay-prepare@@PATH@.service
+
+[Mount]
+Type=overlay
+What=br_ovl_@PATH@
+Where=/@PATH@
+Options=redirect_dir=on,index=on,xino=on,lowerdir=/run/.br/bnd/@PATH@,upperdir=/run/.br/ovl/@PATH@/up,workdir=/run/.br/ovl/@PATH@/wd
diff --git a/package/skeleton-init-systemd/skeleton-init-systemd.mk b/package/skeleton-init-systemd/skeleton-init-systemd.mk
index fb15552f99..ad529cddf6 100644
--- a/package/skeleton-init-systemd/skeleton-init-systemd.mk
+++ b/package/skeleton-init-systemd/skeleton-init-systemd.mk
@@ -57,6 +57,23 @@ define SKELETON_INIT_SYSTEMD_PRE_ROOTFS_VAR
endef
SKELETON_INIT_SYSTEMD_ROOTFS_PRE_CMD_HOOKS += SKELETON_INIT_SYSTEMD_PRE_ROOTFS_VAR
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_POST_INSTALL_VAR_OVERLAYFS
+ sed 's,@PATH@,var,g' $(SKELETON_INIT_SYSTEMD_PKGDIR)/overlayfs/overlay.mount.in >$(@D)/var.mount
+ $(INSTALL) -D -m 0644 $(@D)/var.mount $(TARGET_DIR)/usr/lib/systemd/system/var.mount
+ $(INSTALL) -D -m 0644 $(SKELETON_INIT_SYSTEMD_PKGDIR)/overlayfs/br-bindmount-run@.service \
+ $(TARGET_DIR)/usr/lib/systemd/system/br-bindmount-run@.service
+ $(INSTALL) -D -m 0644 $(SKELETON_INIT_SYSTEMD_PKGDIR)/overlayfs/br-overlay-prepare@.service \
+ $(TARGET_DIR)/usr/lib/systemd/system/br-overlay-prepare@.service
+ # /var mount gets pulled in automatically by basic.target
+endef
+SKELETON_INIT_SYSTEMD_POST_INSTALL_TARGET_HOOKS += SKELETON_INIT_SYSTEMD_POST_INSTALL_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 87df031545..cdf383d0d4 100644
--- a/system/Config.in
+++ b/system/Config.in
@@ -187,6 +187,19 @@ 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_OVERLAYFS
+ bool "mount an overlayfs backed by a tmpfs"
+ help
+ Mount an overlayfs on /var, with the upper as a tmpfs.
+
+ You can customize the backing storage with an override, for
+ ecample create this file and add the content following:
+ /lib/systemd/system/br-overlay-prepare@var.service.d/mount.conf
+
+ [Service]
+ ExecStart=
+ ExecStart=/bin/mount --make-private -n /dev/sdc1 ${OVERLAY_DIR}
+
config BR2_INIT_SYSTEMD_VAR_NONE
bool "do nothing"
help
--
2.39.0
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
^ permalink raw reply related [flat|nested] 16+ messages in thread
* [Buildroot] [PATCH 3/7] package/skeleton-init-systemd: force permissions for buildroot runtime dirs
2023-01-15 12:52 [Buildroot] [PATCH 0/7] Extent options for read-only /var handling Norbert Lange
2023-01-15 12:52 ` [Buildroot] [PATCH 1/7] system: introduce a choice for /var management Norbert Lange
2023-01-15 12:52 ` [Buildroot] [PATCH 2/7] system: add overlayfs option for ro /var Norbert Lange
@ 2023-01-15 12:52 ` Norbert Lange
2023-10-10 19:32 ` Arnout Vandecappelle via buildroot
2023-01-15 12:52 ` [Buildroot] [PATCH 4/7] system: add systemd generator for /var Norbert Lange
` (3 subsequent siblings)
6 siblings, 1 reply; 16+ messages in thread
From: Norbert Lange @ 2023-01-15 12:52 UTC (permalink / raw)
To: buildroot; +Cc: Norbert Lange, Yann E . MORIN
A previous commit introduced /run/.br and /tmp/.br and a few
subdirectories.
Add a tmpfile to ensure the existance, ownership and permissions.
Signed-off-by: Norbert Lange <nolange79@gmail.com>
---
package/skeleton-init-systemd/00-buildroot.conf | 7 +++++++
package/skeleton-init-systemd/skeleton-init-systemd.mk | 1 +
2 files changed, 8 insertions(+)
create mode 100644 package/skeleton-init-systemd/00-buildroot.conf
diff --git a/package/skeleton-init-systemd/00-buildroot.conf b/package/skeleton-init-systemd/00-buildroot.conf
new file mode 100644
index 0000000000..a4c7bf0576
--- /dev/null
+++ b/package/skeleton-init-systemd/00-buildroot.conf
@@ -0,0 +1,7 @@
+# Create buildroot API directories and fix permissions
+
+d /run/.br 0755 root root -
+d /tmp/.br 0755 root root -
+
+z /run/.br/bnd 0700 root root -
+z /run/.br/ovl 0700 root root -
diff --git a/package/skeleton-init-systemd/skeleton-init-systemd.mk b/package/skeleton-init-systemd/skeleton-init-systemd.mk
index ad529cddf6..f431ec4612 100644
--- a/package/skeleton-init-systemd/skeleton-init-systemd.mk
+++ b/package/skeleton-init-systemd/skeleton-init-systemd.mk
@@ -91,6 +91,7 @@ define SKELETON_INIT_SYSTEMD_INSTALL_TARGET_CMDS
ln -s ../run $(TARGET_DIR)/var/run
# prevent install scripts to create var/lock as directory
ln -s ../run/lock $(TARGET_DIR)/var/lock
+ install -D -m644 $(SKELETON_INIT_SYSTEMD_PKGDIR)/00-buildroot.conf $(TARGET_DIR)/usr/lib/tmpfiles.d/00-buildroot.conf
install -D -m644 $(SKELETON_INIT_SYSTEMD_PKGDIR)/legacy.conf $(TARGET_DIR)/usr/lib/tmpfiles.d/legacy.conf
$(SKELETON_INIT_SYSTEMD_ROOT_RO_OR_RW)
endef
--
2.39.0
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
^ permalink raw reply related [flat|nested] 16+ messages in thread
* [Buildroot] [PATCH 4/7] system: add systemd generator for /var
2023-01-15 12:52 [Buildroot] [PATCH 0/7] Extent options for read-only /var handling Norbert Lange
` (2 preceding siblings ...)
2023-01-15 12:52 ` [Buildroot] [PATCH 3/7] package/skeleton-init-systemd: force permissions for buildroot runtime dirs Norbert Lange
@ 2023-01-15 12:52 ` Norbert Lange
2023-10-10 19:59 ` Arnout Vandecappelle via buildroot
2023-01-15 12:52 ` [Buildroot] [PATCH 5/7] package/skeleton-init-systemd: fix var.mount options Norbert Lange
` (2 subsequent siblings)
6 siblings, 1 reply; 16+ messages in thread
From: Norbert Lange @ 2023-01-15 12:52 UTC (permalink / raw)
To: buildroot
Cc: Norbert Lange, Jérémy Rosen, Yann E . MORIN, Romain Naour
This commit adds an alternative that has the following characteristics:
- Dont depend on anything being available, except the
API File Systems [1].
- Be a clean drop-in, that can be trivially added / removed.
- Runs before systemd loads its configuration.
Could be extended to handle more tricky paths like /etc.
For more explaination, see the commit introducing the overlay method.
The implementation doesnt focus on being expandable but simple,
in the future there could be an attempt to source shell scripts
for configuration.
So that multiple paths can be covered (/etc),
or the mounts and handling specified
(do-nothing, copy-over or overlay original contents).
The intent is to have a direct replacement for the var factory method.
[1] - https://www.freedesktop.org/wiki/Software/systemd/APIFileSystems/
Cc: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Romain Naour <romain.naour@smile.fr>
Cc: Jérémy Rosen <jeremy.rosen@smile.fr>
Signed-off-by: Norbert Lange <nolange79@gmail.com>
---
.../generator/br-mount-generator | 19 +++++++++++++++++++
.../skeleton-init-systemd.mk | 10 +++++++++-
system/Config.in | 13 +++++++++++++
3 files changed, 41 insertions(+), 1 deletion(-)
create mode 100755 package/skeleton-init-systemd/generator/br-mount-generator
diff --git a/package/skeleton-init-systemd/generator/br-mount-generator b/package/skeleton-init-systemd/generator/br-mount-generator
new file mode 100755
index 0000000000..fd10659c1c
--- /dev/null
+++ b/package/skeleton-init-systemd/generator/br-mount-generator
@@ -0,0 +1,19 @@
+#!/bin/sh
+set -e
+# SPDX-License-Identifier: MIT
+# Note: doing heavy stuff here is not recommended, but this way
+# the ordering is guaranteed. Be quick about everything.
+# Know that the generator can be run again later.
+
+[ "${SYSTEMD_IN_INITRD-0}" = 1 ] && exit
+grep '^tmpfs_br_var /var tmpfs' /proc/self/mounts >/dev/null && exit
+
+TMPMOUNT=/run/.br/.tmpvar
+trap "umount -l $TMPMOUNT || :; rmdir $TMPMOUNT || :" 0
+
+mkdir -m755 -p $TMPMOUNT
+mount -n -t tmpfs -o nosuid,nodev,size=50% tmpfs_br_var $TMPMOUNT
+
+cp -r -p /var/. $TMPMOUNT
+# this is a shared mount so --move wont work
+mount -n --bind $TMPMOUNT /var
diff --git a/package/skeleton-init-systemd/skeleton-init-systemd.mk b/package/skeleton-init-systemd/skeleton-init-systemd.mk
index f431ec4612..b9b8492f58 100644
--- a/package/skeleton-init-systemd/skeleton-init-systemd.mk
+++ b/package/skeleton-init-systemd/skeleton-init-systemd.mk
@@ -69,11 +69,19 @@ define SKELETON_INIT_SYSTEMD_POST_INSTALL_VAR_OVERLAYFS
$(TARGET_DIR)/usr/lib/systemd/system/br-bindmount-run@.service
$(INSTALL) -D -m 0644 $(SKELETON_INIT_SYSTEMD_PKGDIR)/overlayfs/br-overlay-prepare@.service \
$(TARGET_DIR)/usr/lib/systemd/system/br-overlay-prepare@.service
- # /var mount gets pulled in automatically by basic.target
+ # var.mount gets pulled in automatically by basic.target
endef
SKELETON_INIT_SYSTEMD_POST_INSTALL_TARGET_HOOKS += SKELETON_INIT_SYSTEMD_POST_INSTALL_VAR_OVERLAYFS
endif # BR2_INIT_SYSTEMD_VAR_OVERLAYFS
+ifeq ($(BR2_INIT_SYSTEMD_VAR_GENERATOR),y)
+define SKELETON_INIT_SYSTEMD_POST_INSTALL_VAR_GENERATOR
+ $(INSTALL) -D -m 0755 $(SKELETON_INIT_SYSTEMD_PKGDIR)/generator/br-mount-generator \
+ $(TARGET_DIR)/usr/lib/systemd/system-generators/br-var-mount-generator
+endef
+SKELETON_INIT_SYSTEMD_POST_INSTALL_TARGET_HOOKS += SKELETON_INIT_SYSTEMD_POST_INSTALL_VAR_GENERATOR
+endif # BR2_INIT_SYSTEMD_VAR_GENERATOR
+
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 cdf383d0d4..14fefbf283 100644
--- a/system/Config.in
+++ b/system/Config.in
@@ -200,6 +200,19 @@ config BR2_INIT_SYSTEMD_VAR_OVERLAYFS
ExecStart=
ExecStart=/bin/mount --make-private -n /dev/sdc1 ${OVERLAY_DIR}
+config BR2_INIT_SYSTEMD_VAR_GENERATOR
+ bool "use a systemd generator to mount and populate a tmpfs"
+ help
+ Mount an tmpfs on /var, with the the original contents copied.
+
+ The logic is contained in a systemd generator, to ensure this
+ is done early and ordered before anything can access /var.
+
+ Unlike the var factory, nothing needs to be prepared and
+ the populating happens before any unit accesses /var.
+
+ Unlike the var factory, it does not need an overlayfs.
+
config BR2_INIT_SYSTEMD_VAR_NONE
bool "do nothing"
help
--
2.39.0
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
^ permalink raw reply related [flat|nested] 16+ messages in thread
* [Buildroot] [PATCH 5/7] package/skeleton-init-systemd: fix var.mount options
2023-01-15 12:52 [Buildroot] [PATCH 0/7] Extent options for read-only /var handling Norbert Lange
` (3 preceding siblings ...)
2023-01-15 12:52 ` [Buildroot] [PATCH 4/7] system: add systemd generator for /var Norbert Lange
@ 2023-01-15 12:52 ` Norbert Lange
2023-10-10 20:01 ` Arnout Vandecappelle via buildroot
2023-01-15 12:52 ` [Buildroot] [PATCH 6/7] package/systemd: handle creation of /var/log/journal Norbert Lange
2023-01-15 12:52 ` [Buildroot] [PATCH 7/7] package/systemd: create the /boot directory Norbert Lange
6 siblings, 1 reply; 16+ messages in thread
From: Norbert Lange @ 2023-01-15 12:52 UTC (permalink / raw)
To: buildroot; +Cc: Norbert Lange, Yann E . MORIN
The mode should reflect the mount directory,
and 755 is the default - so drop the mount option.
Cc: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Norbert Lange <nolange79@gmail.com>
---
package/skeleton-init-systemd/var.mount | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/package/skeleton-init-systemd/var.mount b/package/skeleton-init-systemd/var.mount
index e97accef93..a681ab0c54 100644
--- a/package/skeleton-init-systemd/var.mount
+++ b/package/skeleton-init-systemd/var.mount
@@ -12,4 +12,4 @@ After=swap.target
What=tmpfs
Where=/var
Type=tmpfs
-Options=mode=1777,strictatime,nosuid,nodev,size=50%%,nr_inodes=1m
+Options=nosuid,nodev,size=50%%,nr_inodes=1m
--
2.39.0
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
^ permalink raw reply related [flat|nested] 16+ messages in thread
* [Buildroot] [PATCH 6/7] package/systemd: handle creation of /var/log/journal
2023-01-15 12:52 [Buildroot] [PATCH 0/7] Extent options for read-only /var handling Norbert Lange
` (4 preceding siblings ...)
2023-01-15 12:52 ` [Buildroot] [PATCH 5/7] package/skeleton-init-systemd: fix var.mount options Norbert Lange
@ 2023-01-15 12:52 ` Norbert Lange
2023-10-10 20:33 ` Arnout Vandecappelle via buildroot
2023-01-15 12:52 ` [Buildroot] [PATCH 7/7] package/systemd: create the /boot directory Norbert Lange
6 siblings, 1 reply; 16+ messages in thread
From: Norbert Lange @ 2023-01-15 12:52 UTC (permalink / raw)
To: buildroot; +Cc: Norbert Lange, Yann E . MORIN, Sen Hastings
journald will always have a runtime log in /run/systemd/journal,
and a persistent one in /var/log/journal under certain conditions.
By default it will check for the existence of that directory.
When /var is not backed by mass-storage you typically dont want your
log duplicated and journald should be tuned to account for
having only RAM available.
Buildroot will now create this directory conditionally together with
it's handling of /var under a read-only filesystem.
It is rather easy for users to opt-in by either creating that directory
or editing /etc/systemd/journald.conf.
Signed-off-by: Norbert Lange <nolange79@gmail.com>
---
package/systemd/systemd.mk | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/package/systemd/systemd.mk b/package/systemd/systemd.mk
index b96873b73f..420197005c 100644
--- a/package/systemd/systemd.mk
+++ b/package/systemd/systemd.mk
@@ -61,6 +61,7 @@ SYSTEMD_SELINUX_MODULES = systemd udev xdg
SYSTEMD_PROVIDES = udev
SYSTEMD_CONF_OPTS += \
+ -Dcreate-log-dirs=false \
-Ddefault-hierarchy=unified \
-Didn=true \
-Dima=false \
@@ -100,6 +101,10 @@ ifeq ($(BR2_nios2),y)
SYSTEMD_LDFLAGS = $(TARGET_LDFLAGS) -Wl,--no-fatal-warnings
endif
+ifeq ($(BR2_TARGET_GENERIC_REMOUNT_ROOTFS_RW),y)
+SYSTEMD_JOURNALD_PERMISSIONS = /var/log/journal d 2755 root systemd-journal - - - - -
+endif
+
ifeq ($(BR2_PACKAGE_ACL),y)
SYSTEMD_DEPENDENCIES += acl
SYSTEMD_CONF_OPTS += -Dacl=true
@@ -603,6 +608,7 @@ define SYSTEMD_PERMISSIONS
/var/lib/private d 700 0 0 - - - - -
/var/log/private d 700 0 0 - - - - -
/var/cache/private d 700 0 0 - - - - -
+ $(SYSTEMD_JOURNALD_PERMISSIONS)
$(SYSTEMD_LOGIND_PERMISSIONS)
$(SYSTEMD_MACHINED_PERMISSIONS)
$(SYSTEMD_HOMED_PERMISSIONS)
@@ -782,6 +788,7 @@ HOST_SYSTEMD_CONF_OPTS = \
--libdir=lib \
--sysconfdir=/etc \
--localstatedir=/var \
+ -Dcreate-log-dirs=false \
-Dmode=release \
-Dutmp=false \
-Dhibernate=false \
--
2.39.0
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
^ permalink raw reply related [flat|nested] 16+ messages in thread
* [Buildroot] [PATCH 7/7] package/systemd: create the /boot directory
2023-01-15 12:52 [Buildroot] [PATCH 0/7] Extent options for read-only /var handling Norbert Lange
` (5 preceding siblings ...)
2023-01-15 12:52 ` [Buildroot] [PATCH 6/7] package/systemd: handle creation of /var/log/journal Norbert Lange
@ 2023-01-15 12:52 ` Norbert Lange
2023-10-10 20:36 ` Arnout Vandecappelle via buildroot
6 siblings, 1 reply; 16+ messages in thread
From: Norbert Lange @ 2023-01-15 12:52 UTC (permalink / raw)
To: buildroot; +Cc: Norbert Lange, Yann E . MORIN, Sen Hastings
The gpt-auto-generator can generate the boot.mount unit, and
report an error if this directory cant be created (read-only fs).
Signed-off-by: Norbert Lange <nolange79@gmail.com>
---
package/systemd/systemd.mk | 1 +
1 file changed, 1 insertion(+)
diff --git a/package/systemd/systemd.mk b/package/systemd/systemd.mk
index 420197005c..0074fa8791 100644
--- a/package/systemd/systemd.mk
+++ b/package/systemd/systemd.mk
@@ -603,6 +603,7 @@ define SYSTEMD_INSTALL_IMAGES_CMDS
endef
define SYSTEMD_PERMISSIONS
+ /boot d 700 0 0 - - - - -
/var/spool d 755 0 0 - - - - -
/var/lib d 755 0 0 - - - - -
/var/lib/private d 700 0 0 - - - - -
--
2.39.0
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
^ permalink raw reply related [flat|nested] 16+ messages in thread
* Re: [Buildroot] [PATCH 2/7] system: add overlayfs option for ro /var
2023-01-15 12:52 ` [Buildroot] [PATCH 2/7] system: add overlayfs option for ro /var Norbert Lange
@ 2023-10-08 18:37 ` Arnout Vandecappelle via buildroot
2023-10-09 12:16 ` Norbert Lange
0 siblings, 1 reply; 16+ messages in thread
From: Arnout Vandecappelle via buildroot @ 2023-10-08 18:37 UTC (permalink / raw)
To: Norbert Lange, buildroot
Cc: Romain Naour, Jérémy Rosen, Yann E . MORIN
Hi Norbert,
On 15/01/2023 13:52, Norbert Lange wrote:
> This commit adds an alternative that has the following characteristics:
>
> - Dont depend on anything being available, except the
> API File Systems [1].
>
> As /var is meant to be available before normal and even some early
> services are running.
>
> - Be a clean drop-in, that can be trivially added / removed.
>
> - Depend on overlayfs being available in the kernel.
>
> - Units are supposed to be reusable for custom solutions.
[snip]
>
> Cc: Yann E. MORIN <yann.morin.1998@free.fr>
> Cc: Romain Naour <romain.naour@smile.fr>
> Cc: Jérémy Rosen <jeremy.rosen@smile.fr>
> Signed-off-by: Norbert Lange <nolange79@gmail.com>
In the end, I ended up applying Yann's v4 instead, with a few more
modifications, as reported in that thread. I did take inspiration from this
patch - mostly from the commit message.
For your information, I'll give some feedback on this patch as well.
> ---
> .../overlayfs/br-bindmount-run@.service | 26 +++++++++++++++++++
> .../overlayfs/br-overlay-prepare@.service | 26 +++++++++++++++++++
> .../overlayfs/overlay.mount.in | 16 ++++++++++++
> .../skeleton-init-systemd.mk | 17 ++++++++++++
> system/Config.in | 13 ++++++++++
> 5 files changed, 98 insertions(+)
> create mode 100644 package/skeleton-init-systemd/overlayfs/br-bindmount-run@.service
> create mode 100644 package/skeleton-init-systemd/overlayfs/br-overlay-prepare@.service
> create mode 100644 package/skeleton-init-systemd/overlayfs/overlay.mount.in
>
> diff --git a/package/skeleton-init-systemd/overlayfs/br-bindmount-run@.service b/package/skeleton-init-systemd/overlayfs/br-bindmount-run@.service
> new file mode 100644
> index 0000000000..ce944efd92
> --- /dev/null
> +++ b/package/skeleton-init-systemd/overlayfs/br-bindmount-run@.service
> @@ -0,0 +1,26 @@
> +[Unit]
> +Description=Bind-mount rootfs directory (/%I) to /run
> +Documentation=man:file-hierarchy(7)
> +ConditionPathIsSymbolicLink=!/%I
> +DefaultDependencies=no
> +Conflicts=umount.target
> +Before=umount.target
> +
> +# Needs to run after rootfs is properly mounted
> +# and before regular mounts might interfere.
> +After=systemd-remount-fs.service
> +Before=local-fs-pre.target
> +
> +[Service]
> +Type=oneshot
> +RemainAfterExit=yes
> +# dont fail if common dirs already exist
> +ExecStartPre=/bin/mkdir -m755 -p /run/.br
There's no reason to make it a hidden directory. Also, there is no reason to
abbreviate the directory name so much.
> +ExecStartPre=/bin/mkdir -m700 -p /run/.br/bnd
I don't see why it's useful to have a separate base directory for bind mounts.
When you do a bind mount like this, it's always for a very specific purpose -
not always for an overlay, but in any case, it makes more sense to mount on a
mount point that is more related to the sepecific purpose.
For the overlay case, it's very convenient to have everything that the overlay
builds on next to each other, i.e. lower, upper, work.
> +
> +ExecStartPre=/bin/mkdir -m700 -p /run/.br/bnd/%I
> +ExecStart=/bin/mount --make-private -n --bind -o ro /%I /run/.br/bnd/%I
> +
> +# lazy unmount, dont block shutdown under any circumstances
> +ExecStop=/bin/umount -n -l /run/.br/bnd/%I
> +ExecStopPost=-/bin/rmdir /run/.br/bnd/%I
> diff --git a/package/skeleton-init-systemd/overlayfs/br-overlay-prepare@.service b/package/skeleton-init-systemd/overlayfs/br-overlay-prepare@.service
> new file mode 100644
> index 0000000000..86b32900dd
> --- /dev/null
> +++ b/package/skeleton-init-systemd/overlayfs/br-overlay-prepare@.service
> @@ -0,0 +1,26 @@
> +[Unit]
> +Description=Mount and prepare tmpfs for overlay (/%I)
> +Documentation=man:file-hierarchy(7)
> +ConditionPathIsSymbolicLink=!/%I
> +DefaultDependencies=no
> +Conflicts=umount.target
> +Before=local-fs.target umount.target
> +# prepare for systemd mount units aswell
> +RequiresMountsFor=/run/.br/ovl/%I
> +
> +[Service]
> +Environment="OVERLAY_DIR=/run/.br/ovl/%I"
> +Type=oneshot
> +RemainAfterExit=yes
> +# dont fail if common dirs already exist
> +ExecStartPre=/bin/mkdir -m755 -p /run/.br
> +ExecStartPre=/bin/mkdir -m700 -p /run/.br/ovl
I'm not sure if there's a good reason to make this mode 700 instead of the
default 755. If there is a good reason, I'd accept a patch that modifies the
prepare-var-overlay.service that I ended up applying.
> +ExecStartPre=/bin/mkdir -m700 -p ${OVERLAY_DIR}
> +# Create an override and edit this line for customization
> +ExecStart=/bin/mount --make-private -n -t tmpfs tmpfs_br_ovl ${OVERLAY_DIR}
There is in fact no reason to mount anything here - /run is already a tmpfs
with all the required properties. We can just reuse it.
> +ExecStartPost=/bin/mkdir -p ${OVERLAY_DIR}/up ${OVERLAY_DIR}/wd
> +
> +# lazy unmount, dont block shutdown under any circumstances
> +ExecStop=/bin/umount -n -l ${OVERLAY_DIR}
> +ExecStopPost=/bin/rmdir ${OVERLAY_DIR}
> diff --git a/package/skeleton-init-systemd/overlayfs/overlay.mount.in b/package/skeleton-init-systemd/overlayfs/overlay.mount.in
> new file mode 100644
> index 0000000000..84f4d9ee47
> --- /dev/null
> +++ b/package/skeleton-init-systemd/overlayfs/overlay.mount.in
> @@ -0,0 +1,16 @@
> +[Unit]
> +Description=Variable storage (/@PATH@)
> +Documentation=man:file-hierarchy(7)
> +ConditionPathIsSymbolicLink=!/@PATH@
There's too much @PATH@ here. I actually think we can completely avoid it by
using %p or %P as appropriate everywhere.
I think that that way, we can indeed reuse both the overlay.mount.in and
prepare-var-overlay@.service for other overlays. I unfortunately didn't have
time to implement and test that, so instead I committed it without the %p/%P and
without a template service.
If you end up implementing it as a template, please make sure to also include
a runtime test for it, e.g. with /etc as the overlay. Or even better something
deeper - for the test it could be something silly, like /usr/share.
> +
> +After=br-bindmount-run@@PATH@.service
> +Requires=br-bindmount-run@@PATH@.service
> +
> +After=br-overlay-prepare@@PATH@.service
> +BindsTo=br-overlay-prepare@@PATH@.service
> +
> +[Mount]
> +Type=overlay
> +What=br_ovl_@PATH@
> +Where=/@PATH@
> +Options=redirect_dir=on,index=on,xino=on,lowerdir=/run/.br/bnd/@PATH@,upperdir=/run/.br/ovl/@PATH@/up,workdir=/run/.br/ovl/@PATH@/wd
> diff --git a/package/skeleton-init-systemd/skeleton-init-systemd.mk b/package/skeleton-init-systemd/skeleton-init-systemd.mk
> index fb15552f99..ad529cddf6 100644
> --- a/package/skeleton-init-systemd/skeleton-init-systemd.mk
> +++ b/package/skeleton-init-systemd/skeleton-init-systemd.mk
> @@ -57,6 +57,23 @@ define SKELETON_INIT_SYSTEMD_PRE_ROOTFS_VAR
> endef
> SKELETON_INIT_SYSTEMD_ROOTFS_PRE_CMD_HOOKS += SKELETON_INIT_SYSTEMD_PRE_ROOTFS_VAR
> 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_POST_INSTALL_VAR_OVERLAYFS
> + sed 's,@PATH@,var,g' $(SKELETON_INIT_SYSTEMD_PKGDIR)/overlayfs/overlay.mount.in >$(@D)/var.mount
> + $(INSTALL) -D -m 0644 $(@D)/var.mount $(TARGET_DIR)/usr/lib/systemd/system/var.mount
> + $(INSTALL) -D -m 0644 $(SKELETON_INIT_SYSTEMD_PKGDIR)/overlayfs/br-bindmount-run@.service \
> + $(TARGET_DIR)/usr/lib/systemd/system/br-bindmount-run@.service
> + $(INSTALL) -D -m 0644 $(SKELETON_INIT_SYSTEMD_PKGDIR)/overlayfs/br-overlay-prepare@.service \
> + $(TARGET_DIR)/usr/lib/systemd/system/br-overlay-prepare@.service
If it's templates, they can actually be installed independently of the
BR2_INIT_SYSTEMD_VAR_OVERLAYFS option - maybe you want to use a factory for /var
but an overlay for /etc...
I've marked this patch as Superseded (because I took Yann's v4). The rest of
the series I'll look at later.
Regards,
Arnout
> + # /var mount gets pulled in automatically by basic.target
> +endef
> +SKELETON_INIT_SYSTEMD_POST_INSTALL_TARGET_HOOKS += SKELETON_INIT_SYSTEMD_POST_INSTALL_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 87df031545..cdf383d0d4 100644
> --- a/system/Config.in
> +++ b/system/Config.in
> @@ -187,6 +187,19 @@ 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_OVERLAYFS
> + bool "mount an overlayfs backed by a tmpfs"
> + help
> + Mount an overlayfs on /var, with the upper as a tmpfs.
> +
> + You can customize the backing storage with an override, for
> + ecample create this file and add the content following:
> + /lib/systemd/system/br-overlay-prepare@var.service.d/mount.conf
> +
> + [Service]
> + ExecStart=
> + ExecStart=/bin/mount --make-private -n /dev/sdc1 ${OVERLAY_DIR}
> +
> config BR2_INIT_SYSTEMD_VAR_NONE
> bool "do nothing"
> help
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Buildroot] [PATCH 2/7] system: add overlayfs option for ro /var
2023-10-08 18:37 ` Arnout Vandecappelle via buildroot
@ 2023-10-09 12:16 ` Norbert Lange
0 siblings, 0 replies; 16+ messages in thread
From: Norbert Lange @ 2023-10-09 12:16 UTC (permalink / raw)
To: Arnout Vandecappelle
Cc: Romain Naour, Jérémy Rosen, Yann E . MORIN, buildroot
Am So., 8. Okt. 2023 um 20:37 Uhr schrieb Arnout Vandecappelle <arnout@mind.be>:
>
> Hi Norbert,
>
> On 15/01/2023 13:52, Norbert Lange wrote:
> > This commit adds an alternative that has the following characteristics:
> >
> > - Dont depend on anything being available, except the
> > API File Systems [1].
> >
> > As /var is meant to be available before normal and even some early
> > services are running.
> >
> > - Be a clean drop-in, that can be trivially added / removed.
> >
> > - Depend on overlayfs being available in the kernel.
> >
> > - Units are supposed to be reusable for custom solutions.
>
> [snip]
> >
> > Cc: Yann E. MORIN <yann.morin.1998@free.fr>
> > Cc: Romain Naour <romain.naour@smile.fr>
> > Cc: Jérémy Rosen <jeremy.rosen@smile.fr>
> > Signed-off-by: Norbert Lange <nolange79@gmail.com>
>
> In the end, I ended up applying Yann's v4 instead, with a few more
> modifications, as reported in that thread. I did take inspiration from this
> patch - mostly from the commit message.
>
> For your information, I'll give some feedback on this patch as well.
Happy that there finally is some movement, still its weird that after
a long back-and-forth
a modified version is committed before feedback.
>
> > ---
> > .../overlayfs/br-bindmount-run@.service | 26 +++++++++++++++++++
> > .../overlayfs/br-overlay-prepare@.service | 26 +++++++++++++++++++
> > .../overlayfs/overlay.mount.in | 16 ++++++++++++
> > .../skeleton-init-systemd.mk | 17 ++++++++++++
> > system/Config.in | 13 ++++++++++
> > 5 files changed, 98 insertions(+)
> > create mode 100644 package/skeleton-init-systemd/overlayfs/br-bindmount-run@.service
> > create mode 100644 package/skeleton-init-systemd/overlayfs/br-overlay-prepare@.service
> > create mode 100644 package/skeleton-init-systemd/overlayfs/overlay.mount.in
> >
> > diff --git a/package/skeleton-init-systemd/overlayfs/br-bindmount-run@.service b/package/skeleton-init-systemd/overlayfs/br-bindmount-run@.service
> > new file mode 100644
> > index 0000000000..ce944efd92
> > --- /dev/null
> > +++ b/package/skeleton-init-systemd/overlayfs/br-bindmount-run@.service
> > @@ -0,0 +1,26 @@
> > +[Unit]
> > +Description=Bind-mount rootfs directory (/%I) to /run
> > +Documentation=man:file-hierarchy(7)
> > +ConditionPathIsSymbolicLink=!/%I
> > +DefaultDependencies=no
> > +Conflicts=umount.target
> > +Before=umount.target
> > +
> > +# Needs to run after rootfs is properly mounted
> > +# and before regular mounts might interfere.
> > +After=systemd-remount-fs.service
> > +Before=local-fs-pre.target
> > +
> > +[Service]
> > +Type=oneshot
> > +RemainAfterExit=yes
> > +# dont fail if common dirs already exist
> > +ExecStartPre=/bin/mkdir -m755 -p /run/.br
>
> There's no reason to make it a hidden directory. Also, there is no reason to
> abbreviate the directory name so much.
should be short imho, to avoid running into path-length problems.
its a technical detail, hidden from users
>
> > +ExecStartPre=/bin/mkdir -m700 -p /run/.br/bnd
>
> I don't see why it's useful to have a separate base directory for bind mounts.
> When you do a bind mount like this, it's always for a very specific purpose -
> not always for an overlay, but in any case, it makes more sense to mount on a
> mount point that is more related to the sepecific purpose.
Because /run/.br could be for anything else later, and /run/.br/bnd
should mirror
the filesystem root.
>
> For the overlay case, it's very convenient to have everything that the overlay
> builds on next to each other, i.e. lower, upper, work.
Yeah, there was a reason for not doing that, had to do
with being able to re-use that system of generic mount templates,
ie. /run/.br/bnd would always mirror a part of the fs root, without
changed hierarchies.
ie. you could either use a single mount / to /run/.br/bnd, or say /etc
to /run/.br/bnd/etc and
/var to /run/.br/bnd/var. It would not effect the overlay units.
>
> > +
> > +ExecStartPre=/bin/mkdir -m700 -p /run/.br/bnd/%I
> > +ExecStart=/bin/mount --make-private -n --bind -o ro /%I /run/.br/bnd/%I
> > +
> > +# lazy unmount, dont block shutdown under any circumstances
> > +ExecStop=/bin/umount -n -l /run/.br/bnd/%I
> > +ExecStopPost=-/bin/rmdir /run/.br/bnd/%I
This got left out aswell:
ExecStopPost=-/bin/rmdir /run/.br/bnd/%I
Removing it, would allow new accesses to the filesystem
thats in progress of being lazily unmounted.
> > diff --git a/package/skeleton-init-systemd/overlayfs/br-overlay-prepare@.service b/package/skeleton-init-systemd/overlayfs/br-overlay-prepare@.service
> > new file mode 100644
> > index 0000000000..86b32900dd
> > --- /dev/null
> > +++ b/package/skeleton-init-systemd/overlayfs/br-overlay-prepare@.service
> > @@ -0,0 +1,26 @@
> > +[Unit]
> > +Description=Mount and prepare tmpfs for overlay (/%I)
> > +Documentation=man:file-hierarchy(7)
> > +ConditionPathIsSymbolicLink=!/%I
> > +DefaultDependencies=no
> > +Conflicts=umount.target
> > +Before=local-fs.target umount.target
> > +# prepare for systemd mount units aswell
> > +RequiresMountsFor=/run/.br/ovl/%I
> > +
> > +[Service]
> > +Environment="OVERLAY_DIR=/run/.br/ovl/%I"
> > +Type=oneshot
> > +RemainAfterExit=yes
> > +# dont fail if common dirs already exist
> > +ExecStartPre=/bin/mkdir -m755 -p /run/.br
> > +ExecStartPre=/bin/mkdir -m700 -p /run/.br/ovl
>
> I'm not sure if there's a good reason to make this mode 700 instead of the
> default 755. If there is a good reason, I'd accept a patch that modifies the
> prepare-var-overlay.service that I ended up applying.
No one should access this directories directly, its being defensive
>
> > +ExecStartPre=/bin/mkdir -m700 -p ${OVERLAY_DIR}
> > +# Create an override and edit this line for customization
> > +ExecStart=/bin/mount --make-private -n -t tmpfs tmpfs_br_ovl ${OVERLAY_DIR}
>
> There is in fact no reason to mount anything here - /run is already a tmpfs
> with all the required properties. We can just reuse it.
Yes, problem is that the /run mount is limited in size, not configurable
(parameters are in systemd's sources) and
filling /var with stuff should never exhaust one of the most critical
filesystems.
>
> > +ExecStartPost=/bin/mkdir -p ${OVERLAY_DIR}/up ${OVERLAY_DIR}/wd
> > +
> > +# lazy unmount, dont block shutdown under any circumstances
> > +ExecStop=/bin/umount -n -l ${OVERLAY_DIR}
> > +ExecStopPost=/bin/rmdir ${OVERLAY_DIR}
> > diff --git a/package/skeleton-init-systemd/overlayfs/overlay.mount.in b/package/skeleton-init-systemd/overlayfs/overlay.mount.in
> > new file mode 100644
> > index 0000000000..84f4d9ee47
> > --- /dev/null
> > +++ b/package/skeleton-init-systemd/overlayfs/overlay.mount.in
> > @@ -0,0 +1,16 @@
> > +[Unit]
> > +Description=Variable storage (/@PATH@)
> > +Documentation=man:file-hierarchy(7)
> > +ConditionPathIsSymbolicLink=!/@PATH@
>
> There's too much @PATH@ here. I actually think we can completely avoid it by
> using %p or %P as appropriate everywhere.
>
> I think that that way, we can indeed reuse both the overlay.mount.in and
> prepare-var-overlay@.service for other overlays. I unfortunately didn't have
> time to implement and test that, so instead I committed it without the %p/%P and
> without a template service.
>
> If you end up implementing it as a template, please make sure to also include
> a runtime test for it, e.g. with /etc as the overlay. Or even better something
> deeper - for the test it could be something silly, like /usr/share.
Yeah, gonna rebase my stuff and pickup where I stopped long ago,
gonna take a while.
>
> > +
> > +After=br-bindmount-run@@PATH@.service
> > +Requires=br-bindmount-run@@PATH@.service
> > +
> > +After=br-overlay-prepare@@PATH@.service
> > +BindsTo=br-overlay-prepare@@PATH@.service
> > +
> > +[Mount]
> > +Type=overlay
> > +What=br_ovl_@PATH@
> > +Where=/@PATH@
> > +Options=redirect_dir=on,index=on,xino=on,lowerdir=/run/.br/bnd/@PATH@,upperdir=/run/.br/ovl/@PATH@/up,workdir=/run/.br/ovl/@PATH@/wd
> > diff --git a/package/skeleton-init-systemd/skeleton-init-systemd.mk b/package/skeleton-init-systemd/skeleton-init-systemd.mk
> > index fb15552f99..ad529cddf6 100644
> > --- a/package/skeleton-init-systemd/skeleton-init-systemd.mk
> > +++ b/package/skeleton-init-systemd/skeleton-init-systemd.mk
> > @@ -57,6 +57,23 @@ define SKELETON_INIT_SYSTEMD_PRE_ROOTFS_VAR
> > endef
> > SKELETON_INIT_SYSTEMD_ROOTFS_PRE_CMD_HOOKS += SKELETON_INIT_SYSTEMD_PRE_ROOTFS_VAR
> > 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_POST_INSTALL_VAR_OVERLAYFS
> > + sed 's,@PATH@,var,g' $(SKELETON_INIT_SYSTEMD_PKGDIR)/overlayfs/overlay.mount.in >$(@D)/var.mount
> > + $(INSTALL) -D -m 0644 $(@D)/var.mount $(TARGET_DIR)/usr/lib/systemd/system/var.mount
> > + $(INSTALL) -D -m 0644 $(SKELETON_INIT_SYSTEMD_PKGDIR)/overlayfs/br-bindmount-run@.service \
> > + $(TARGET_DIR)/usr/lib/systemd/system/br-bindmount-run@.service
> > + $(INSTALL) -D -m 0644 $(SKELETON_INIT_SYSTEMD_PKGDIR)/overlayfs/br-overlay-prepare@.service \
> > + $(TARGET_DIR)/usr/lib/systemd/system/br-overlay-prepare@.service
>
> If it's templates, they can actually be installed independently of the
> BR2_INIT_SYSTEMD_VAR_OVERLAYFS option - maybe you want to use a factory for /var
> but an overlay for /etc...
Sure, but not sure if it should be installed unconditionally. Easy to
just copy those files into a
rootfs-overlay.
>
>
> I've marked this patch as Superseded (because I took Yann's v4). The rest of
> the series I'll look at later.
Ok
>
> Regards,
> Arnout
>
Regards,
Norbert
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Buildroot] [PATCH 3/7] package/skeleton-init-systemd: force permissions for buildroot runtime dirs
2023-01-15 12:52 ` [Buildroot] [PATCH 3/7] package/skeleton-init-systemd: force permissions for buildroot runtime dirs Norbert Lange
@ 2023-10-10 19:32 ` Arnout Vandecappelle via buildroot
2023-10-12 7:53 ` Norbert Lange
0 siblings, 1 reply; 16+ messages in thread
From: Arnout Vandecappelle via buildroot @ 2023-10-10 19:32 UTC (permalink / raw)
To: Norbert Lange, buildroot; +Cc: Yann E . MORIN
Hi Norbert,
Obviously, this doesn't apply any more because I committed a different tree.
However...
On 15/01/2023 13:52, Norbert Lange wrote:
> A previous commit introduced /run/.br and /tmp/.br and a few
> subdirectories.
> Add a tmpfile to ensure the existance, ownership and permissions.
>
> Signed-off-by: Norbert Lange <nolange79@gmail.com>
> ---
> package/skeleton-init-systemd/00-buildroot.conf | 7 +++++++
> package/skeleton-init-systemd/skeleton-init-systemd.mk | 1 +
> 2 files changed, 8 insertions(+)
> create mode 100644 package/skeleton-init-systemd/00-buildroot.conf
>
> diff --git a/package/skeleton-init-systemd/00-buildroot.conf b/package/skeleton-init-systemd/00-buildroot.conf
> new file mode 100644
> index 0000000000..a4c7bf0576
> --- /dev/null
> +++ b/package/skeleton-init-systemd/00-buildroot.conf
> @@ -0,0 +1,7 @@
> +# Create buildroot API directories and fix permissions
> +
> +d /run/.br 0755 root root -
> +d /tmp/.br 0755 root root -
I don't think this tmp directory is used anywhere?
> +z /run/.br/bnd 0700 root root -
> +z /run/.br/ovl 0700 root root -
What's the point of doing this? These directories are created by the overlay
service file. systemd-tmpfiles is started after local-fs.target and the /var
overlay mount comes before, so it's the overlay service file that has to create
them. You could say "hey maybe there's some other service that makes use of
those directories" - but if so, that's another service that is going to come
before local-fs.target, so it _also_ has to create those directories itself...
There's a bit of a problem with systemd-tmpfiles, that it doesn't allow to
specify dependencies/ordering. That's in fact one of the reasons the factory
approach doesn't work so well. systemd-tmpfiles only works for services after
sysinit.target, really - and therefore doesn't work for anything related to
local filesystems.
IMHO it would have been better to put tmpfile blocks in service definitions.
But that's not the world we live in :-)
So, I've marked as Rejected, but feel free to argue my points.
Regards,
Arnout
> diff --git a/package/skeleton-init-systemd/skeleton-init-systemd.mk b/package/skeleton-init-systemd/skeleton-init-systemd.mk
> index ad529cddf6..f431ec4612 100644
> --- a/package/skeleton-init-systemd/skeleton-init-systemd.mk
> +++ b/package/skeleton-init-systemd/skeleton-init-systemd.mk
> @@ -91,6 +91,7 @@ define SKELETON_INIT_SYSTEMD_INSTALL_TARGET_CMDS
> ln -s ../run $(TARGET_DIR)/var/run
> # prevent install scripts to create var/lock as directory
> ln -s ../run/lock $(TARGET_DIR)/var/lock
> + install -D -m644 $(SKELETON_INIT_SYSTEMD_PKGDIR)/00-buildroot.conf $(TARGET_DIR)/usr/lib/tmpfiles.d/00-buildroot.conf
> install -D -m644 $(SKELETON_INIT_SYSTEMD_PKGDIR)/legacy.conf $(TARGET_DIR)/usr/lib/tmpfiles.d/legacy.conf
> $(SKELETON_INIT_SYSTEMD_ROOT_RO_OR_RW)
> endef
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Buildroot] [PATCH 4/7] system: add systemd generator for /var
2023-01-15 12:52 ` [Buildroot] [PATCH 4/7] system: add systemd generator for /var Norbert Lange
@ 2023-10-10 19:59 ` Arnout Vandecappelle via buildroot
0 siblings, 0 replies; 16+ messages in thread
From: Arnout Vandecappelle via buildroot @ 2023-10-10 19:59 UTC (permalink / raw)
To: Norbert Lange, buildroot
Cc: Romain Naour, Jérémy Rosen, Yann E . MORIN
Hi Norbert,
I'm not entirely sure about this one, but not completely against it either.
Since I do have a few comments below, I've marked as Changes Requested.
On 15/01/2023 13:52, Norbert Lange wrote:
> This commit adds an alternative that has the following characteristics:
This commit adds an alternative /var management method that has the following
characteristics:
>
> - Dont depend on anything being available, except the
> API File Systems [1].
>
> - Be a clean drop-in, that can be trivially added / removed.
>
> - Runs before systemd loads its configuration.
>
> Could be extended to handle more tricky paths like /etc.
Well, for /etc there is no real reason for it to be writeable (but not
persistent), is there? There are some debugging situations where it could be
useful, but then I think you could just as well use the overlayfs approach.
What is missing here still is why you'd prefer this over the overlay approach.
That's explained in the help text though. Not that I really believe there's a
good reason though - see below.
> For more explaination, see the commit introducing the overlay method.
That's commit 10c637ab06d935bbce4c833c4ab9695cdb32b6c8 now. I put most of your
explanation in the commit message so this reference should still apply.
explaination -> explanation
>
> The implementation doesnt focus on being expandable but simple,
doesn't
> in the future there could be an attempt to source shell scripts
> for configuration.
> So that multiple paths can be covered (/etc),
> or the mounts and handling specified
> (do-nothing, copy-over or overlay original contents).
I don't think it makes sense to refer to an unproven theoretical extension
like trying for some kind of half-baked writeable overlay without using
overlayfs. Well, I shouldn't be talking, my current project is in fact doing
exactly that - but let me tell you, it's half baked :-)
> The intent is to have a direct replacement for the var factory method.
>
> [1] - https://www.freedesktop.org/wiki/Software/systemd/APIFileSystems/
>
> Cc: Yann E. MORIN <yann.morin.1998@free.fr>
> Cc: Romain Naour <romain.naour@smile.fr>
> Cc: Jérémy Rosen <jeremy.rosen@smile.fr>
> Signed-off-by: Norbert Lange <nolange79@gmail.com>
> ---
> .../generator/br-mount-generator | 19 +++++++++++++++++++
> .../skeleton-init-systemd.mk | 10 +++++++++-
> system/Config.in | 13 +++++++++++++
> 3 files changed, 41 insertions(+), 1 deletion(-)
> create mode 100755 package/skeleton-init-systemd/generator/br-mount-generator
>
> diff --git a/package/skeleton-init-systemd/generator/br-mount-generator b/package/skeleton-init-systemd/generator/br-mount-generator
> new file mode 100755
> index 0000000000..fd10659c1c
> --- /dev/null
> +++ b/package/skeleton-init-systemd/generator/br-mount-generator
> @@ -0,0 +1,19 @@
> +#!/bin/sh
> +set -e
> +# SPDX-License-Identifier: MIT
The MIT license suggest that you copied this from somewhere else. If so, you
must refer to the original - at least to the original author, as required by the
MIT license.
> +# Note: doing heavy stuff here is not recommended, but this way
> +# the ordering is guaranteed. Be quick about everything.
> +# Know that the generator can be run again later.
> +
> +[ "${SYSTEMD_IN_INITRD-0}" = 1 ] && exit
I don't like this redundant default of 0 much. But that's just minor.
> +grep '^tmpfs_br_var /var tmpfs' /proc/self/mounts >/dev/null && exit
Why >/dev/null instead of grep -q?
> +
> +TMPMOUNT=/run/.br/.tmpvar
> +trap "umount -l $TMPMOUNT || :; rmdir $TMPMOUNT || :" 0
> +
> +mkdir -m755 -p $TMPMOUNT
> +mount -n -t tmpfs -o nosuid,nodev,size=50% tmpfs_br_var $TMPMOUNT > +
> +cp -r -p /var/. $TMPMOUNT
> +# this is a shared mount so --move wont work
"this" seems to refer to /run/.br/.tmpvar, which is _not_ a shared mount (and
it's anyway not relevant if it is). /run is a shared mount and that is the
reason you can't --move it.
And perhaps add "so instead, bind-mount and unmount $TMPMOUNT afterwards (in
the trap handler)."
> +mount -n --bind $TMPMOUNT /var
> diff --git a/package/skeleton-init-systemd/skeleton-init-systemd.mk b/package/skeleton-init-systemd/skeleton-init-systemd.mk
> index f431ec4612..b9b8492f58 100644
> --- a/package/skeleton-init-systemd/skeleton-init-systemd.mk
> +++ b/package/skeleton-init-systemd/skeleton-init-systemd.mk
> @@ -69,11 +69,19 @@ define SKELETON_INIT_SYSTEMD_POST_INSTALL_VAR_OVERLAYFS
> $(TARGET_DIR)/usr/lib/systemd/system/br-bindmount-run@.service
> $(INSTALL) -D -m 0644 $(SKELETON_INIT_SYSTEMD_PKGDIR)/overlayfs/br-overlay-prepare@.service \
> $(TARGET_DIR)/usr/lib/systemd/system/br-overlay-prepare@.service
> - # /var mount gets pulled in automatically by basic.target
> + # var.mount gets pulled in automatically by basic.target
If you're anyway going to correct this comment, correct it correctly :-) It's
pulled in by local-fs.target, not basic.target.
> endef
> SKELETON_INIT_SYSTEMD_POST_INSTALL_TARGET_HOOKS += SKELETON_INIT_SYSTEMD_POST_INSTALL_VAR_OVERLAYFS
> endif # BR2_INIT_SYSTEMD_VAR_OVERLAYFS
>
> +ifeq ($(BR2_INIT_SYSTEMD_VAR_GENERATOR),y)
> +define SKELETON_INIT_SYSTEMD_POST_INSTALL_VAR_GENERATOR
> + $(INSTALL) -D -m 0755 $(SKELETON_INIT_SYSTEMD_PKGDIR)/generator/br-mount-generator \
> + $(TARGET_DIR)/usr/lib/systemd/system-generators/br-var-mount-generator
Please keep the same name in PKGDIR. I know the intention is to keep it
general so it can be used for other things (e.g. /etc), but it _isn't_ general
so don't try pretending it is.
> +endef
> +SKELETON_INIT_SYSTEMD_POST_INSTALL_TARGET_HOOKS += SKELETON_INIT_SYSTEMD_POST_INSTALL_VAR_GENERATOR
> +endif # BR2_INIT_SYSTEMD_VAR_GENERATOR
> +
> 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 cdf383d0d4..14fefbf283 100644
> --- a/system/Config.in
> +++ b/system/Config.in
> @@ -200,6 +200,19 @@ config BR2_INIT_SYSTEMD_VAR_OVERLAYFS
> ExecStart=
> ExecStart=/bin/mount --make-private -n /dev/sdc1 ${OVERLAY_DIR}
>
> +config BR2_INIT_SYSTEMD_VAR_GENERATOR
> + bool "use a systemd generator to mount and populate a tmpfs"
> + help
> + Mount an tmpfs on /var, with the the original contents copied.
> +
> + The logic is contained in a systemd generator, to ensure this
> + is done early and ordered before anything can access /var.
> +
> + Unlike the var factory, nothing needs to be prepared and
> + the populating happens before any unit accesses /var.
Well, nothing is _allowed_ to access /var before local-fs-pre.target, exactly
because /var may be mounted (and mounting something depends on local-fs.target).
If you do need to access /var, you need to do special magic like journald does
and wait with using it until it gets mounted.
Do you have an actual proven use case of something that requires /var before
local-fs-pre.target (and that isn't an unacceptable hack)?
> + Unlike the var factory, it does not need an overlayfs.
If this is the only reason, then I don't think it's worth the bother to
replace the factory.
Regards,
Arnout
> +
> config BR2_INIT_SYSTEMD_VAR_NONE
> bool "do nothing"
> help
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Buildroot] [PATCH 5/7] package/skeleton-init-systemd: fix var.mount options
2023-01-15 12:52 ` [Buildroot] [PATCH 5/7] package/skeleton-init-systemd: fix var.mount options Norbert Lange
@ 2023-10-10 20:01 ` Arnout Vandecappelle via buildroot
0 siblings, 0 replies; 16+ messages in thread
From: Arnout Vandecappelle via buildroot @ 2023-10-10 20:01 UTC (permalink / raw)
To: Norbert Lange, buildroot; +Cc: Yann E . MORIN
On 15/01/2023 13:52, Norbert Lange wrote:
> The mode should reflect the mount directory,
> and 755 is the default - so drop the mount option.
>
> Cc: Yann E. MORIN <yann.morin.1998@free.fr>
> Signed-off-by: Norbert Lange <nolange79@gmail.com>
Applied to master, thanks.
Regards,
Arnout
> ---
> package/skeleton-init-systemd/var.mount | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/package/skeleton-init-systemd/var.mount b/package/skeleton-init-systemd/var.mount
> index e97accef93..a681ab0c54 100644
> --- a/package/skeleton-init-systemd/var.mount
> +++ b/package/skeleton-init-systemd/var.mount
> @@ -12,4 +12,4 @@ After=swap.target
> What=tmpfs
> Where=/var
> Type=tmpfs
> -Options=mode=1777,strictatime,nosuid,nodev,size=50%%,nr_inodes=1m
> +Options=nosuid,nodev,size=50%%,nr_inodes=1m
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Buildroot] [PATCH 6/7] package/systemd: handle creation of /var/log/journal
2023-01-15 12:52 ` [Buildroot] [PATCH 6/7] package/systemd: handle creation of /var/log/journal Norbert Lange
@ 2023-10-10 20:33 ` Arnout Vandecappelle via buildroot
0 siblings, 0 replies; 16+ messages in thread
From: Arnout Vandecappelle via buildroot @ 2023-10-10 20:33 UTC (permalink / raw)
To: Norbert Lange, buildroot; +Cc: Yann E . MORIN, Sen Hastings
On 15/01/2023 13:52, Norbert Lange wrote:
> journald will always have a runtime log in /run/systemd/journal,
> and a persistent one in /var/log/journal under certain conditions.
> By default it will check for the existence of that directory.
>
> When /var is not backed by mass-storage you typically dont want your
> log duplicated and journald should be tuned to account for
> having only RAM available.
>
> Buildroot will now create this directory conditionally together with
> it's handling of /var under a read-only filesystem.
The patch now only creates the directory if rootfs-rw is enabled.
This is actually not great IMHO - we have too many things hinging on that
config setting that give meaning to it which doesn't really exist. Still,
there's no better way to do it, really.
> It is rather easy for users to opt-in by either creating that directory
> or editing /etc/systemd/journald.conf.
We really should have documentation of how to do this, and a runtime test that
proves that it works.
But OK, I anyway already committed this to master, thanks.
Regards,
Arnout
>
> Signed-off-by: Norbert Lange <nolange79@gmail.com>
> ---
> package/systemd/systemd.mk | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/package/systemd/systemd.mk b/package/systemd/systemd.mk
> index b96873b73f..420197005c 100644
> --- a/package/systemd/systemd.mk
> +++ b/package/systemd/systemd.mk
> @@ -61,6 +61,7 @@ SYSTEMD_SELINUX_MODULES = systemd udev xdg
> SYSTEMD_PROVIDES = udev
>
> SYSTEMD_CONF_OPTS += \
> + -Dcreate-log-dirs=false \
> -Ddefault-hierarchy=unified \
> -Didn=true \
> -Dima=false \
> @@ -100,6 +101,10 @@ ifeq ($(BR2_nios2),y)
> SYSTEMD_LDFLAGS = $(TARGET_LDFLAGS) -Wl,--no-fatal-warnings
> endif
>
> +ifeq ($(BR2_TARGET_GENERIC_REMOUNT_ROOTFS_RW),y)
> +SYSTEMD_JOURNALD_PERMISSIONS = /var/log/journal d 2755 root systemd-journal - - - - -
> +endif
> +
> ifeq ($(BR2_PACKAGE_ACL),y)
> SYSTEMD_DEPENDENCIES += acl
> SYSTEMD_CONF_OPTS += -Dacl=true
> @@ -603,6 +608,7 @@ define SYSTEMD_PERMISSIONS
> /var/lib/private d 700 0 0 - - - - -
> /var/log/private d 700 0 0 - - - - -
> /var/cache/private d 700 0 0 - - - - -
> + $(SYSTEMD_JOURNALD_PERMISSIONS)
> $(SYSTEMD_LOGIND_PERMISSIONS)
> $(SYSTEMD_MACHINED_PERMISSIONS)
> $(SYSTEMD_HOMED_PERMISSIONS)
> @@ -782,6 +788,7 @@ HOST_SYSTEMD_CONF_OPTS = \
> --libdir=lib \
> --sysconfdir=/etc \
> --localstatedir=/var \
> + -Dcreate-log-dirs=false \
> -Dmode=release \
> -Dutmp=false \
> -Dhibernate=false \
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Buildroot] [PATCH 7/7] package/systemd: create the /boot directory
2023-01-15 12:52 ` [Buildroot] [PATCH 7/7] package/systemd: create the /boot directory Norbert Lange
@ 2023-10-10 20:36 ` Arnout Vandecappelle via buildroot
0 siblings, 0 replies; 16+ messages in thread
From: Arnout Vandecappelle via buildroot @ 2023-10-10 20:36 UTC (permalink / raw)
To: Norbert Lange, buildroot; +Cc: Yann E . MORIN, Sen Hastings
On 15/01/2023 13:52, Norbert Lange wrote:
> The gpt-auto-generator can generate the boot.mount unit, and
> report an error if this directory cant be created (read-only fs).
>
> Signed-off-by: Norbert Lange <nolange79@gmail.com>
Applied to master, thanks.
Regards,
Arnout
> ---
> package/systemd/systemd.mk | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/package/systemd/systemd.mk b/package/systemd/systemd.mk
> index 420197005c..0074fa8791 100644
> --- a/package/systemd/systemd.mk
> +++ b/package/systemd/systemd.mk
> @@ -603,6 +603,7 @@ define SYSTEMD_INSTALL_IMAGES_CMDS
> endef
>
> define SYSTEMD_PERMISSIONS
> + /boot d 700 0 0 - - - - -
> /var/spool d 755 0 0 - - - - -
> /var/lib d 755 0 0 - - - - -
> /var/lib/private d 700 0 0 - - - - -
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Buildroot] [PATCH 3/7] package/skeleton-init-systemd: force permissions for buildroot runtime dirs
2023-10-10 19:32 ` Arnout Vandecappelle via buildroot
@ 2023-10-12 7:53 ` Norbert Lange
0 siblings, 0 replies; 16+ messages in thread
From: Norbert Lange @ 2023-10-12 7:53 UTC (permalink / raw)
To: Arnout Vandecappelle; +Cc: Yann E . MORIN, buildroot
Am Di., 10. Okt. 2023 um 21:32 Uhr schrieb Arnout Vandecappelle
<arnout@mind.be>:
>
> Hi Norbert,
>
> Obviously, this doesn't apply any more because I committed a different tree.
> However...
>
> On 15/01/2023 13:52, Norbert Lange wrote:
> > A previous commit introduced /run/.br and /tmp/.br and a few
> > subdirectories.
> > Add a tmpfile to ensure the existance, ownership and permissions.
> >
> > Signed-off-by: Norbert Lange <nolange79@gmail.com>
> > ---
> > package/skeleton-init-systemd/00-buildroot.conf | 7 +++++++
> > package/skeleton-init-systemd/skeleton-init-systemd.mk | 1 +
> > 2 files changed, 8 insertions(+)
> > create mode 100644 package/skeleton-init-systemd/00-buildroot.conf
> >
> > diff --git a/package/skeleton-init-systemd/00-buildroot.conf b/package/skeleton-init-systemd/00-buildroot.conf
> > new file mode 100644
> > index 0000000000..a4c7bf0576
> > --- /dev/null
> > +++ b/package/skeleton-init-systemd/00-buildroot.conf
> > @@ -0,0 +1,7 @@
> > +# Create buildroot API directories and fix permissions
> > +
> > +d /run/.br 0755 root root -
> > +d /tmp/.br 0755 root root -
>
> I don't think this tmp directory is used anywhere?
Not yet, these would reserve the paths. One usage would
be to use /tmp/.br as base for overlay "upper" dirs, reusing
the /tmp filesystem instead of mounting an extra tmpfs.
Using /run for anything else but small files is a bad idea,
as I mentioned in response to the commit
"package/skeleton-init-systemd: add option to use overlayfs on /var".
>
> > +z /run/.br/bnd 0700 root root -
> > +z /run/.br/ovl 0700 root root -
>
> What's the point of doing this? These directories are created by the overlay
> service file. systemd-tmpfiles is started after local-fs.target and the /var
> overlay mount comes before, so it's the overlay service file that has to create
> them. You could say "hey maybe there's some other service that makes use of
> those directories" - but if so, that's another service that is going to come
> before local-fs.target, so it _also_ has to create those directories itself...
Not all overlays/services have to be enabled, you generally should use
tmpfiles.d
to ensure owner/mode of some sort of protected files.
Prevents hijacking.
Think of mounting an overlay on-demand, running an system update,
testing said update then "commiting" the (merged) overlay to a blockdevice.
if anything breaks, you reboot and you are running the unmodified working
system.
>
> There's a bit of a problem with systemd-tmpfiles, that it doesn't allow to
> specify dependencies/ordering. That's in fact one of the reasons the factory
> approach doesn't work so well. systemd-tmpfiles only works for services after
> sysinit.target, really - and therefore doesn't work for anything related to
> local filesystems.
>
> IMHO it would have been better to put tmpfile blocks in service definitions.
> But that's not the world we live in :-)
That's not what they are for. tmpfiles.d should set up the filesystem whether
services are enabled or not. Erases a whole set of problems.
>
> So, I've marked as Rejected, but feel free to argue my points.
The argument would be to create & protect paths buildroot services could be
using.
>
> Regards,
> Arnout
>
Regards, Norbert
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2023-10-12 7:53 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-01-15 12:52 [Buildroot] [PATCH 0/7] Extent options for read-only /var handling Norbert Lange
2023-01-15 12:52 ` [Buildroot] [PATCH 1/7] system: introduce a choice for /var management Norbert Lange
2023-01-15 12:52 ` [Buildroot] [PATCH 2/7] system: add overlayfs option for ro /var Norbert Lange
2023-10-08 18:37 ` Arnout Vandecappelle via buildroot
2023-10-09 12:16 ` Norbert Lange
2023-01-15 12:52 ` [Buildroot] [PATCH 3/7] package/skeleton-init-systemd: force permissions for buildroot runtime dirs Norbert Lange
2023-10-10 19:32 ` Arnout Vandecappelle via buildroot
2023-10-12 7:53 ` Norbert Lange
2023-01-15 12:52 ` [Buildroot] [PATCH 4/7] system: add systemd generator for /var Norbert Lange
2023-10-10 19:59 ` Arnout Vandecappelle via buildroot
2023-01-15 12:52 ` [Buildroot] [PATCH 5/7] package/skeleton-init-systemd: fix var.mount options Norbert Lange
2023-10-10 20:01 ` Arnout Vandecappelle via buildroot
2023-01-15 12:52 ` [Buildroot] [PATCH 6/7] package/systemd: handle creation of /var/log/journal Norbert Lange
2023-10-10 20:33 ` Arnout Vandecappelle via buildroot
2023-01-15 12:52 ` [Buildroot] [PATCH 7/7] package/systemd: create the /boot directory Norbert Lange
2023-10-10 20:36 ` Arnout Vandecappelle via buildroot
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.