[Buildroot] [PATCH 1/2] package/systemd: set machine id file instalation as optional choice

[Buildroot] [PATCH 1/2] package/systemd: set machine id file instalation as optional choice

[Bartosz Bilas]

In case of e.g writable systems there is no neccesity to have
pre-installed empty machine-id file on target because systemd
generates that automatically during system boot.
Also in case of having empty machine-id file we are not able
to use a service with ConditionFirstBoot because systemd recognizes
machine-id file in system therefore we can't detect new system instance boots up.
Set this option as enable by default to keep compatibility with old builds.

Signed-off-by: Bartosz Bilas <b.bilas@grinn-global.com>
---
 package/systemd/Config.in  | 13 +++++++++++++
 package/systemd/systemd.mk |  2 ++
 2 files changed, 15 insertions(+)

diff --git a/package/systemd/Config.in b/package/systemd/Config.in
index aef39abe27..fadc1a32c8 100644
--- a/package/systemd/Config.in
+++ b/package/systemd/Config.in
@@ -112,6 +112,19 @@ config BR2_PACKAGE_SYSTEMD_BOOT_EFI_ARCH
 	default "x64"   if BR2_x86_64
 	depends on BR2_PACKAGE_SYSTEMD_BOOT
 
+config BR2_PACKAGE_SYSTEMD_MACHINEID_FILE
+	bool "Install empty machine id file"
+	default y
+	help
+	  The /etc/machine-id file contains the unique machine ID
+	  of the local system that is set during installation or
+	  boot. The machine ID is a single newline-terminated,
+	  hexadecimal, 32-character, lowercase ID. When decoded from
+	  hexadecimal, this corresponds to a 16-byte/128-bit value.
+	  This ID may not be all zeros.
+
+	  https://www.freedesktop.org/software/systemd/man/machine-id.html
+
 config BR2_PACKAGE_SYSTEMD_JOURNAL_GATEWAY
 	bool "HTTP server for journal events"
 	select BR2_PACKAGE_LIBMICROHTTPD
diff --git a/package/systemd/systemd.mk b/package/systemd/systemd.mk
index 92490eb86b..fc348fe120 100644
--- a/package/systemd/systemd.mk
+++ b/package/systemd/systemd.mk
@@ -461,9 +461,11 @@ define SYSTEMD_INSTALL_INIT_HOOK
 		$(TARGET_DIR)/etc/systemd/system/multi-user.target.wants/remote-fs.target
 endef
 
+ifeq ($(BR2_PACKAGE_SYSTEMD_MACHINEID_FILE),y)
 define SYSTEMD_INSTALL_MACHINEID_HOOK
 	touch $(TARGET_DIR)/etc/machine-id
 endef
+endif
 
 SYSTEMD_POST_INSTALL_TARGET_HOOKS += \
 	SYSTEMD_INSTALL_TARGET_CRYPTSETUP \
-- 
2.24.0

[Buildroot] [PATCH 2/2] package/systemd: set systemd generators instalation as optional choice

[Bartosz Bilas]

Allow the user to choose which systemd generator should be installed
on the target instead of installing all of them by default.
That's usefull in case of when someone is using firstboot condition
and doesn't want to have e.g getty services created automatically during
system boot by systemd-getty-generator. Set them enabled by default to
keep compatibility with old builds.

Signed-off-by: Bartosz Bilas <b.bilas@grinn-global.com>
---
 package/systemd/Config.in  | 94 ++++++++++++++++++++++++++++++++++++++
 package/systemd/systemd.mk | 56 +++++++++++++++++++++++
 2 files changed, 150 insertions(+)

diff --git a/package/systemd/Config.in b/package/systemd/Config.in
index fadc1a32c8..052b69f4de 100644
--- a/package/systemd/Config.in
+++ b/package/systemd/Config.in
@@ -112,6 +112,100 @@ config BR2_PACKAGE_SYSTEMD_BOOT_EFI_ARCH
 	default "x64"   if BR2_x86_64
 	depends on BR2_PACKAGE_SYSTEMD_BOOT
 
+menu systemd-generators
+
+config BR2_PACKAGE_SYSTEMD_DEBUG_GENERATOR
+	bool "systemd debug generator"
+	default y
+	help
+	  systemd-debug-generator is for enabling a runtime debug
+	  shell and masking specific units at boot.
+
+	  https://www.freedesktop.org/software/systemd/man/systemd-debug-generator.html
+
+config BR2_PACKAGE_SYSTEMD_FSTAB_GENERATOR
+	bool "systemd fstab generator"
+	default y
+	help
+	  systemd-fstab-generator is a generator that translates
+	  /etc/fstab into native systemd units early at boot
+	  and when configuration of the system manager is reloaded.
+	  This will instantiate mount and swap units as necessary.
+
+	  https://www.freedesktop.org/software/systemd/man/systemd-fstab-generator.html
+
+config BR2_PACKAGE_SYSTEMD_GETTY_GENERATOR
+	bool "systemd getty generator"
+	default y
+	help
+	  systemd-getty-generator is a generator that automatically
+	  instantiates serial-getty at .service on the kernel
+	  console(s), if they can function as ttys and are not
+	  provided by the virtual console subsystem. It will also
+	  instantiate serial-getty at .service instances for
+	  virtualizer consoles, if execution in a virtualized
+	  environment is detected.
+
+	  https://www.freedesktop.org/software/systemd/man/systemd-getty-generator.html
+
+config BR2_PACKAGE_SYSTEMD_GPT_AUTO_GENERATOR
+	bool "systemd gpt auto generator"
+	default y
+	help
+	  systemd-gpt-auto-generator is a unit generator that
+	  automatically discovers root, /home/, /srv/, the EFI
+	  System Partition, the Extended Boot Loader Partition and
+	  swap partitions and creates mount and swap units for them,
+	  based on the partition type GUIDs of GUID partition tables
+	  (GPT). It implements the Discoverable Partitions
+	  Specification.
+
+	  https://www.freedesktop.org/software/systemd/man/systemd-gpt-auto-generator.html
+
+config BR2_PACKAGE_SYSTEMD_RC_LOCAL_GENERATOR
+	bool "systemd rc local generator"
+	default y
+	help
+	  systemd-rc-local-generator is a generator that checks
+	  whether /etc/rc.local exists and is executable,
+	  and if it is pulls the rc-local.service unit into the
+	  boot process.
+
+	  https://www.freedesktop.org/software/systemd/man/systemd-rc-local-generator.html
+
+config BR2_PACKAGE_SYSTEMD_RUN_GENERATOR
+	bool "systemd run generator"
+	default y
+	help
+	  systemd-run-generator is for invoking commands specified
+	  on the kernel command line as system service.
+
+	  https://www.freedesktop.org/software/systemd/man/systemd-run-generator.html
+
+config BR2_PACKAGE_SYSTEMD_SYSTEM_UPDATE_GENERATOR
+	bool "systemd system update generator"
+	default y
+	help
+	  systemd-system-update-generator is a generator that
+	  automatically redirects the boot process to
+	  system-update.target, if /system-update exists.
+
+	  https://www.freedesktop.org/software/systemd/man/systemd-system-update-generator.html
+
+config BR2_PACKAGE_SYSTEMD_SYSV_GENERATOR
+	bool "systemd sysv generator"
+	default y
+	help
+	  systemd-sysv-generator is a generator that creates wrapper
+	  .service units for SysV init scripts in /etc/init.d/* at
+	  boot and when configuration of the system manager is
+	  reloaded. This will allow systemd(1) to support them
+	  similarly to native units/
+
+	  https://www.freedesktop.org/software/systemd/man/systemd-system-update-generator.html
+
+endmenu
+
 config BR2_PACKAGE_SYSTEMD_MACHINEID_FILE
 	bool "Install empty machine id file"
 	default y
diff --git a/package/systemd/systemd.mk b/package/systemd/systemd.mk
index fc348fe120..32349980e3 100644
--- a/package/systemd/systemd.mk
+++ b/package/systemd/systemd.mk
@@ -467,6 +467,62 @@ define SYSTEMD_INSTALL_MACHINEID_HOOK
 endef
 endif
 
+ifneq ($(BR2_PACKAGE_SYSTEMD_DEBUG_GENERATOR),y)
+define SYSTEMD_DISABLE_DEBUG_GENERATOR
+	rm -f $(TARGET_DIR)/usr/lib/systemd/system-generators/systemd-debug-generator
+endef
+SYSTEMD_POST_INSTALL_TARGET_HOOKS += SYSTEMD_DISABLE_DEBUG_GENERATOR
+endif
+
+ifneq ($(BR2_PACKAGE_SYSTEMD_FSTAB_GENERATOR),y)
+define SYSTEMD_DISABLE_FSTAB_GENERATOR
+	rm -f $(TARGET_DIR)/usr/lib/systemd/system-generators/systemd-fstab-generator
+endef
+SYSTEMD_POST_INSTALL_TARGET_HOOKS += SYSTEMD_DISABLE_FSTAB_GENERATOR
+endif
+
+ifneq ($(BR2_PACKAGE_SYSTEMD_GETTY_GENERATOR),y)
+define SYSTEMD_DISABLE_GETTY_GENERATOR
+	rm -f $(TARGET_DIR)/usr/lib/systemd/system-generators/systemd-getty-generator
+endef
+SYSTEMD_POST_INSTALL_TARGET_HOOKS += SYSTEMD_DISABLE_GETTY_GENERATOR
+endif
+
+ifneq ($(BR2_PACKAGE_SYSTEMD_GPT_AUTO_GENERATOR),y)
+define SYSTEMD_DISABLE_GPT_AUTO_GENERATOR
+	rm -f $(TARGET_DIR)/usr/lib/systemd/system-generators/systemd-gpt-auto-generator
+endef
+SYSTEMD_POST_INSTALL_TARGET_HOOKS += SYSTEMD_DISABLE_GPT_AUTO_GENERATOR
+endif
+
+ifneq ($(BR2_PACKAGE_SYSTEMD_RC_LOCAL_GENERATOR),y)
+define SYSTEMD_DISABLE_RC_LOCAL_GENERATOR
+	rm -f $(TARGET_DIR)/usr/lib/systemd/system-generators/systemd-rc-local-generator
+endef
+SYSTEMD_POST_INSTALL_TARGET_HOOKS += SYSTEMD_DISABLE_RC_LOCAL_GENERATOR
+endif
+
+ifneq ($(BR2_PACKAGE_SYSTEMD_RUN_GENERATOR),y)
+define SYSTEMD_DISABLE_RUN_GENERATOR
+	rm -f $(TARGET_DIR)/usr/lib/systemd/system-generators/systemd-run-generator
+endef
+SYSTEMD_POST_INSTALL_TARGET_HOOKS += SYSTEMD_DISABLE_RUN_GENERATOR
+endif
+
+ifneq ($(BR2_PACKAGE_SYSTEMD_SYSTEM_UPDATE_GENERATOR),y)
+define SYSTEMD_DISABLE_SYSTEMD_SYSTEM_UPDATE_GENERATOR
+	rm -f $(TARGET_DIR)/usr/lib/systemd/system-generators/systemd-system-update-generator
+endef
+SYSTEMD_POST_INSTALL_TARGET_HOOKS += SYSTEMD_DISABLE_SYSTEMD_SYSTEM_UPDATE_GENERATOR
+endif
+
+ifneq ($(BR2_PACKAGE_SYSTEMD_SYSTEMD_SYSV_GENERATOR),y)
+define SYSTEMD_DISABLE_SYSTEMD_SYSV_GENERATOR
+	rm -f $(TARGET_DIR)/usr/lib/systemd/system-generators/systemd-sysv-generator
+endef
+SYSTEMD_POST_INSTALL_TARGET_HOOKS += SYSTEMD_DISABLE_SYSTEMD_SYSV_GENERATOR
+endif
+
 SYSTEMD_POST_INSTALL_TARGET_HOOKS += \
 	SYSTEMD_INSTALL_TARGET_CRYPTSETUP \
 	SYSTEMD_INSTALL_TARGET_MACHINED \
-- 
2.24.0

[Buildroot] [PATCH 2/2] package/systemd: set systemd generators instalation as optional choice

[Arnout Vandecappelle]

On 17/11/2019 12:33, Bartosz Bilas wrote:
> Allow the user to choose which systemd generator should be installed
> on the target instead of installing all of them by default.
> That's usefull in case of when someone is using firstboot condition
         useful

> and doesn't want to have e.g getty services created automatically during
> system boot by systemd-getty-generator. Set them enabled by default to
> keep compatibility with old builds.
> 
> Signed-off-by: Bartosz Bilas <b.bilas@grinn-global.com>
> ---
>  package/systemd/Config.in  | 94 ++++++++++++++++++++++++++++++++++++++
>  package/systemd/systemd.mk | 56 +++++++++++++++++++++++
>  2 files changed, 150 insertions(+)
> 
> diff --git a/package/systemd/Config.in b/package/systemd/Config.in
> index fadc1a32c8..052b69f4de 100644
> --- a/package/systemd/Config.in
> +++ b/package/systemd/Config.in
> @@ -112,6 +112,100 @@ config BR2_PACKAGE_SYSTEMD_BOOT_EFI_ARCH
>  	default "x64"   if BR2_x86_64
>  	depends on BR2_PACKAGE_SYSTEMD_BOOT
>  
> +menu systemd-generators

 I don't like adding submenus. Instead, I'd just do it with a comment.

 However, doesn't all this depend on BR2_PACKAGE_SYSTEMD_FIRSTBOOT? In that
case, it could be done with a condition just under that option and the
generators would be indented. Although, maybe they don't only get executed on
firstboot...

 So, then I'd move this section to the end of Config.in, and use a comment
instead of a menu.

> +config BR2_PACKAGE_SYSTEMD_DEBUG_GENERATOR
> +	bool "systemd debug generator"
> +	default y

 Although this one should default y for backward compatibility, I'm of a mind to
change the default here. It doesn't sound like something you want to have on by
default.

> +	help
> +	  systemd-debug-generator is for enabling a runtime debug
> +	  shell and masking specific units at boot.
> +
> +	  https://www.freedesktop.org/software/systemd/man/systemd-debug-generator.html
> +
> +config BR2_PACKAGE_SYSTEMD_FSTAB_GENERATOR
> +	bool "systemd fstab generator"
> +	default y
> +	help
> +	  systemd-fstab-generator is a generator that translates
> +	  /etc/fstab into native systemd units early at boot
> +	  and when configuration of the system manager is reloaded.
> +	  This will instantiate mount and swap units as necessary.

 Makes me realize that we probably shouldn't have an fstab in
skeleton-init-systemd...

> +
> +	  https://www.freedesktop.org/software/systemd/man/systemd-fstab-generator.html
> +
> +config BR2_PACKAGE_SYSTEMD_GETTY_GENERATOR
> +	bool "systemd getty generator"
> +	default y
> +	help
> +	  systemd-getty-generator is a generator that automatically
> +	  instantiates serial-getty at .service on the kernel
> +	  console(s), if they can function as ttys and are not
> +	  provided by the virtual console subsystem. It will also
> +	  instantiate serial-getty at .service instances for
> +	  virtualizer consoles, if execution in a virtualized
> +	  environment is detected.
> +
> +	  https://www.freedesktop.org/software/systemd/man/systemd-getty-generator.html
> +
> +config BR2_PACKAGE_SYSTEMD_GPT_AUTO_GENERATOR
> +	bool "systemd gpt auto generator"
> +	default y

 For this one, I also doubt that we want to have this default on.

> +	help
> +	  systemd-gpt-auto-generator is a unit generator that
> +	  automatically discovers root, /home/, /srv/, the EFI
> +	  System Partition, the Extended Boot Loader Partition and
> +	  swap partitions and creates mount and swap units for them,
> +	  based on the partition type GUIDs of GUID partition tables
> +	  (GPT). It implements the Discoverable Partitions
> +	  Specification.
> +
> +	  https://www.freedesktop.org/software/systemd/man/systemd-gpt-auto-generator.html
> +
> +config BR2_PACKAGE_SYSTEMD_RC_LOCAL_GENERATOR
> +	bool "systemd rc local generator"
> +	default y

 Same here. It's pretty useless in Buildroot context.

> +	help
> +	  systemd-rc-local-generator is a generator that checks
> +	  whether /etc/rc.local exists and is executable,
> +	  and if it is pulls the rc-local.service unit into the
> +	  boot process.
> +
> +	  https://www.freedesktop.org/software/systemd/man/systemd-rc-local-generator.html
> +
> +config BR2_PACKAGE_SYSTEMD_RUN_GENERATOR
> +	bool "systemd run generator"
> +	default y
> +	help
> +	  systemd-run-generator is for invoking commands specified
> +	  on the kernel command line as system service.
> +
> +	  https://www.freedesktop.org/software/systemd/man/systemd-run-generator.html
> +
> +config BR2_PACKAGE_SYSTEMD_SYSTEM_UPDATE_GENERATOR
> +	bool "systemd system update generator"
> +	default y
> +	help
> +	  systemd-system-update-generator is a generator that
> +	  automatically redirects the boot process to
> +	  system-update.target, if /system-update exists.
> +
> +	  https://www.freedesktop.org/software/systemd/man/systemd-system-update-generator.html
> +
> +config BR2_PACKAGE_SYSTEMD_SYSV_GENERATOR
> +	bool "systemd sysv generator"
> +	default y
> +	help
> +	  systemd-sysv-generator is a generator that creates wrapper
> +	  .service units for SysV init scripts in /etc/init.d/* at
> +	  boot and when configuration of the system manager is
> +	  reloaded. This will allow systemd(1) to support them
> +	  similarly to native units/
> +
> +	  https://www.freedesktop.org/software/systemd/man/systemd-system-update-generator.html
> +
> +endmenu
> +
>  config BR2_PACKAGE_SYSTEMD_MACHINEID_FILE
>  	bool "Install empty machine id file"
>  	default y
> diff --git a/package/systemd/systemd.mk b/package/systemd/systemd.mk
> index fc348fe120..32349980e3 100644
> --- a/package/systemd/systemd.mk
> +++ b/package/systemd/systemd.mk
> @@ -467,6 +467,62 @@ define SYSTEMD_INSTALL_MACHINEID_HOOK
>  endef
>  endif
>  
> +ifneq ($(BR2_PACKAGE_SYSTEMD_DEBUG_GENERATOR),y)

 We prefer `ifeq ($(...),)` to `ifneq ($(...),y)`. Yes, there are still 145
occurrences of the latter, some of them committed just a couple of days ago, but
that's because of incomplete review :-)

> +define SYSTEMD_DISABLE_DEBUG_GENERATOR
> +	rm -f $(TARGET_DIR)/usr/lib/systemd/system-generators/systemd-debug-generator
> +endef
> +SYSTEMD_POST_INSTALL_TARGET_HOOKS += SYSTEMD_DISABLE_DEBUG_GENERATOR
> +endif> +
> +ifneq ($(BR2_PACKAGE_SYSTEMD_FSTAB_GENERATOR),y)
> +define SYSTEMD_DISABLE_FSTAB_GENERATOR
> +	rm -f $(TARGET_DIR)/usr/lib/systemd/system-generators/systemd-fstab-generator
> +endef
> +SYSTEMD_POST_INSTALL_TARGET_HOOKS += SYSTEMD_DISABLE_FSTAB_GENERATOR
> +endif
> +
> +ifneq ($(BR2_PACKAGE_SYSTEMD_GETTY_GENERATOR),y)
> +define SYSTEMD_DISABLE_GETTY_GENERATOR
> +	rm -f $(TARGET_DIR)/usr/lib/systemd/system-generators/systemd-getty-generator
> +endef
> +SYSTEMD_POST_INSTALL_TARGET_HOOKS += SYSTEMD_DISABLE_GETTY_GENERATOR
> +endif
> +
> +ifneq ($(BR2_PACKAGE_SYSTEMD_GPT_AUTO_GENERATOR),y)
> +define SYSTEMD_DISABLE_GPT_AUTO_GENERATOR
> +	rm -f $(TARGET_DIR)/usr/lib/systemd/system-generators/systemd-gpt-auto-generator
> +endef
> +SYSTEMD_POST_INSTALL_TARGET_HOOKS += SYSTEMD_DISABLE_GPT_AUTO_GENERATOR
> +endif
> +
> +ifneq ($(BR2_PACKAGE_SYSTEMD_RC_LOCAL_GENERATOR),y)
> +define SYSTEMD_DISABLE_RC_LOCAL_GENERATOR
> +	rm -f $(TARGET_DIR)/usr/lib/systemd/system-generators/systemd-rc-local-generator
> +endef
> +SYSTEMD_POST_INSTALL_TARGET_HOOKS += SYSTEMD_DISABLE_RC_LOCAL_GENERATOR
> +endif
> +
> +ifneq ($(BR2_PACKAGE_SYSTEMD_RUN_GENERATOR),y)
> +define SYSTEMD_DISABLE_RUN_GENERATOR
> +	rm -f $(TARGET_DIR)/usr/lib/systemd/system-generators/systemd-run-generator
> +endef
> +SYSTEMD_POST_INSTALL_TARGET_HOOKS += SYSTEMD_DISABLE_RUN_GENERATOR
> +endif
> +
> +ifneq ($(BR2_PACKAGE_SYSTEMD_SYSTEM_UPDATE_GENERATOR),y)
> +define SYSTEMD_DISABLE_SYSTEMD_SYSTEM_UPDATE_GENERATOR
> +	rm -f $(TARGET_DIR)/usr/lib/systemd/system-generators/systemd-system-update-generator
> +endef
> +SYSTEMD_POST_INSTALL_TARGET_HOOKS += SYSTEMD_DISABLE_SYSTEMD_SYSTEM_UPDATE_GENERATOR
> +endif
> +
> +ifneq ($(BR2_PACKAGE_SYSTEMD_SYSTEMD_SYSV_GENERATOR),y)
> +define SYSTEMD_DISABLE_SYSTEMD_SYSV_GENERATOR
> +	rm -f $(TARGET_DIR)/usr/lib/systemd/system-generators/systemd-sysv-generator
> +endef
> +SYSTEMD_POST_INSTALL_TARGET_HOOKS += SYSTEMD_DISABLE_SYSTEMD_SYSV_GENERATOR
> +endif


That's quite a lot of code... How about this refactoring:

SYSTEMD_GENERATORS_TO_DISABLE = \
	$(if $(BR2_PACKAGE_SYSTEMD_DEBUG_GENERATOR),,systemd-debug-generator) \
	...

ifneq ($(strip $(SYSTEMD_GENERATORS_TO_DISABLE)),)
define SYSTEMD_INSTALL_TARGET_GENERATORS
	rm -f $(addprefix
$(TARGET_DIR)/usr/lib/systemd/system-generators/,$(SYSTEMD_GENERATORS_TO_DISABLE))
endef
SYSTEMD_POST_INSTALL_TARGET_HOOKS += SYSTEMD_INSTALL_TARGET_GENERATORS
endif

Also, please put this below...

> +
>  SYSTEMD_POST_INSTALL_TARGET_HOOKS += \
>  	SYSTEMD_INSTALL_TARGET_CRYPTSETUP \
>  	SYSTEMD_INSTALL_TARGET_MACHINED \

... here, so that the above statement stays closer to the definitions of the
variables that are used in it.

 Regards,
 Arnout

[Buildroot] [PATCH 2/2] package/systemd: set systemd generators instalation as optional choice

[Jérémy ROSEN]

overall I'm not very keen on adding options for the various generators...

there are special case where you want to get rid of a specific generator,
but it's really special and probably better done in a post-image script

detailed answers below

Le dim. 17 nov. 2019 ? 15:12, Arnout Vandecappelle <arnout@mind.be> a
?crit :

>
>
> On 17/11/2019 12:33, Bartosz Bilas wrote:
> > Allow the user to choose which systemd generator should be installed
> > on the target instead of installing all of them by default.
> > That's usefull in case of when someone is using firstboot condition
>          useful
>
> > and doesn't want to have e.g getty services created automatically during
> > system boot by systemd-getty-generator. Set them enabled by default to
> > keep compatibility with old builds.
> >
> > Signed-off-by: Bartosz Bilas <b.bilas@grinn-global.com>
> > ---
> >  package/systemd/Config.in  | 94 ++++++++++++++++++++++++++++++++++++++
> >  package/systemd/systemd.mk | 56 +++++++++++++++++++++++
> >  2 files changed, 150 insertions(+)
> >
> > diff --git a/package/systemd/Config.in b/package/systemd/Config.in
> > index fadc1a32c8..052b69f4de 100644
> > --- a/package/systemd/Config.in
> > +++ b/package/systemd/Config.in
> > @@ -112,6 +112,100 @@ config BR2_PACKAGE_SYSTEMD_BOOT_EFI_ARCH
> >       default "x64"   if BR2_x86_64
> >       depends on BR2_PACKAGE_SYSTEMD_BOOT
> >
> > +menu systemd-generators
>
>  I don't like adding submenus. Instead, I'd just do it with a comment.
>
>  However, doesn't all this depend on BR2_PACKAGE_SYSTEMD_FIRSTBOOT? In that
> case, it could be done with a condition just under that option and the
> generators would be indented. Although, maybe they don't only get executed
> on
> firstboot...
>
>
No... generators are a core feature of systemd, it's not related to
first-boot in any way that I know



>  So, then I'd move this section to the end of Config.in, and use a comment
> instead of a menu.
>
> > +config BR2_PACKAGE_SYSTEMD_DEBUG_GENERATOR
> > +     bool "systemd debug generator"
> > +     default y
>
>  Although this one should default y for backward compatibility, I'm of a
> mind to
> change the default here. It doesn't sound like something you want to have
> on by
> default.
>
>
Despite its name, this is not a debug tool, but more of a rescue tool. It
allows you to get a shell back on a
very broken system, or to prevent a unit from starting from the
kernel-command-line

This should really be here all the time except on very specific use-cases,
I don't think making it optional
is a good idea


> > +     help
> > +       systemd-debug-generator is for enabling a runtime debug
> > +       shell and masking specific units at boot.
> > +
> > +
> https://www.freedesktop.org/software/systemd/man/systemd-debug-generator.html
> > +
> > +config BR2_PACKAGE_SYSTEMD_FSTAB_GENERATOR
> > +     bool "systemd fstab generator"
> > +     default y
> > +     help
> > +       systemd-fstab-generator is a generator that translates
> > +       /etc/fstab into native systemd units early at boot
> > +       and when configuration of the system manager is reloaded.
> > +       This will instantiate mount and swap units as necessary.
>
>  Makes me realize that we probably shouldn't have an fstab in
> skeleton-init-systemd...
>
> fstab is supported in systemd and it is not a deprecated feature.
It is the recommended way to automatically mount filesystems at boot.

this one is really fundamental, and should really not be removed. lots of
things might break.

there are a couple of reasons to use .mount units instead (and the
fstab-generator simply
creates .mount units from /etc/fstab) but in the common case you are
supposed to use /etc/fstab

so again, I don't think this is a good idea.




> > +
> > +
> https://www.freedesktop.org/software/systemd/man/systemd-fstab-generator.html
> > +
> > +config BR2_PACKAGE_SYSTEMD_GETTY_GENERATOR
> > +     bool "systemd getty generator"
> > +     default y
> > +     help
> > +       systemd-getty-generator is a generator that automatically
> > +       instantiates serial-getty at .service on the kernel
> > +       console(s), if they can function as ttys and are not
> > +       provided by the virtual console subsystem. It will also
> > +       instantiate serial-getty at .service instances for
> > +       virtualizer consoles, if execution in a virtualized
> > +       environment is detected.
> > +
> > +
> https://www.freedesktop.org/software/systemd/man/systemd-getty-generator.html
> > +
>

That one could be made optional, since it's about runtime-detection of the
right way to start a getty
(i.e figure out if the console is a serial tty, a normal tty, or a
vconsole) and in the embedded case
we usually know what we have

note that it means manually enabling a service instead... which is probably
harder

but otoh, it's typically very small and it does "the right thing" most of
the time. So again, probably a
better fit for a post-image script



> > +config BR2_PACKAGE_SYSTEMD_GPT_AUTO_GENERATOR
> > +     bool "systemd gpt auto generator"
> > +     default y
>
>  For this one, I also doubt that we want to have this default on.
>
>
That one can probably be made optional, yes... it saves 34k approximately


> > +     help
> > +       systemd-gpt-auto-generator is a unit generator that
> > +       automatically discovers root, /home/, /srv/, the EFI
> > +       System Partition, the Extended Boot Loader Partition and
> > +       swap partitions and creates mount and swap units for them,
> > +       based on the partition type GUIDs of GUID partition tables
> > +       (GPT). It implements the Discoverable Partitions
> > +       Specification.
> > +
> > +
> https://www.freedesktop.org/software/systemd/man/systemd-gpt-auto-generator.html
> > +
> > +config BR2_PACKAGE_SYSTEMD_RC_LOCAL_GENERATOR
> > +     bool "systemd rc local generator"
> > +     default y
>
>  Same here. It's pretty useless in Buildroot context.
>
>
this one is already conditional to compiling sysV backward compatibility
support...
which i think is always on in buildroot (neet to double-check that)

I think having an option to enable/disable sysV support would be more
generic and more useful


> > +     help
> > +       systemd-rc-local-generator is a generator that checks
> > +       whether /etc/rc.local exists and is executable,
> > +       and if it is pulls the rc-local.service unit into the
> > +       boot process.
> > +
> > +
> https://www.freedesktop.org/software/systemd/man/systemd-rc-local-generator.html
> > +
> > +config BR2_PACKAGE_SYSTEMD_RUN_GENERATOR
> > +     bool "systemd run generator"
> > +     default y
> > +     help
> > +       systemd-run-generator is for invoking commands specified
> > +       on the kernel command line as system service.
> > +
> > +
> https://www.freedesktop.org/software/systemd/man/systemd-run-generator.html
> > +
>

This one could be optional... it's very usefull for containers, less for
full-blown systems


> > +config BR2_PACKAGE_SYSTEMD_SYSTEM_UPDATE_GENERATOR
> > +     bool "systemd system update generator"
> > +     default y
> > +     help
> > +       systemd-system-update-generator is a generator that
> > +       automatically redirects the boot process to
> > +       system-update.target, if /system-update exists.
> > +
> > +
> https://www.freedesktop.org/software/systemd/man/systemd-system-update-generator.html
> > +
>

this one could be optional


> > +config BR2_PACKAGE_SYSTEMD_SYSV_GENERATOR
> > +     bool "systemd sysv generator"
> > +     default y
> > +     help
> > +       systemd-sysv-generator is a generator that creates wrapper
> > +       .service units for SysV init scripts in /etc/init.d/* at
> > +       boot and when configuration of the system manager is
> > +       reloaded. This will allow systemd(1) to support them
> > +       similarly to native units/
> > +
> > +
> https://www.freedesktop.org/software/systemd/man/systemd-system-update-generator.html
> > +
> > +endmenu
> > +
>

Again, i'd rather have a generic way to disable the sysV support at compile
time...




Ok so overall, I think most generators should stay in and only one or two
should be made optional...
Sorry for the negative feedback, but I don't like adding complex
compilation options that are not supported
upstream, especially when all generators together wait 272k on my debian

The few that could legitimately be made optional are easy enough to remove
in a post-image that I'm not sure
it's worth the trouble

i'd be ok for a patch doing that, though, but only for the few ones that
are worth it...

Cheers
Jeremy

-- 
[image: SMILE]  <http://www.smile.eu/>

20 rue des Jardins
92600 Asni?res-sur-Seine
*J?r?my ROSEN*
Architecte technique

[image: email] jeremy.rosen at smile.fr
[image: phone]  +33 6 88 25 87 42
[image: url] http://www.smile.eu

[image: Twitter] <https://twitter.com/GroupeSmile> [image: Facebook]
<https://www.facebook.com/smileopensource> [image: LinkedIn]
<https://www.linkedin.com/company/smile> [image: Github]
<https://github.com/Smile-SA>

[image: D?couvrez l?univers Smile, rendez-vous sur smile.eu]
<https://www.smile.eu/fr/publications/livres-blancs/yocto?utm_source=signature&utm_medium=email&utm_campaign=signature>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20191117/2c924df3/attachment.html>

[Buildroot] [PATCH 2/2] package/systemd: set systemd generators instalation as optional choice

[Bartosz Bilas]

Hello guys,

On 17.11.2019 16:06, J?r?my ROSEN wrote:
> overall I'm not very keen on adding options for the various generators...
>
> there are special case where you want to get rid of a specific 
> generator, but it's really special and probably better done in a 
> post-image script
>
> detailed answers below
>
> Le?dim. 17 nov. 2019 ??15:12, Arnout Vandecappelle <arnout@mind.be 
> <mailto:arnout@mind.be>> a ?crit?:
>
>
>
>     On 17/11/2019 12:33, Bartosz Bilas wrote:
>     > Allow the user to choose which systemd generator should be installed
>     > on the target instead of installing all of them by default.
>     > That's usefull in case of when someone is using firstboot condition
>     ? ? ? ? ?useful
>
>     > and doesn't want to have e.g getty services created
>     automatically during
>     > system boot by systemd-getty-generator. Set them enabled by
>     default to
>     > keep compatibility with old builds.
>     >
>     > Signed-off-by: Bartosz Bilas <b.bilas@grinn-global.com
>     <mailto:b.bilas@grinn-global.com>>
>     > ---
>     >? package/systemd/Config.in? | 94
>     ++++++++++++++++++++++++++++++++++++++
>     >? package/systemd/systemd.mk <http://systemd.mk> | 56
>     +++++++++++++++++++++++
>     >? 2 files changed, 150 insertions(+)
>     >
>     > diff --git a/package/systemd/Config.in b/package/systemd/Config.in
>     > index fadc1a32c8..052b69f4de 100644
>     > --- a/package/systemd/Config.in
>     > +++ b/package/systemd/Config.in
>     > @@ -112,6 +112,100 @@ config BR2_PACKAGE_SYSTEMD_BOOT_EFI_ARCH
>     >? ? ? ?default "x64"? ?if BR2_x86_64
>     >? ? ? ?depends on BR2_PACKAGE_SYSTEMD_BOOT
>     >
>     > +menu systemd-generators
>
>     ?I don't like adding submenus. Instead, I'd just do it with a comment.
>
>     ?However, doesn't all this depend on
>     BR2_PACKAGE_SYSTEMD_FIRSTBOOT? In that
>     case, it could be done with a condition just under that option and the
>     generators would be indented. Although, maybe they don't only get
>     executed on
>     firstboot...
>
>
> No... generators are a core feature of systemd, it's not related to 
> first-boot in any way that I know
>
>     ?So, then I'd move this section to the end of Config.in, and use a
>     comment
>     instead of a menu.
>
>     > +config BR2_PACKAGE_SYSTEMD_DEBUG_GENERATOR
>     > +? ? ?bool "systemd debug generator"
>     > +? ? ?default y
>
>     ?Although this one should default y for backward compatibility,
>     I'm of a mind to
>     change the default here. It doesn't sound like something you want
>     to have on by
>     default.
>
>
> Despite its name, this is not a debug tool, but more of a rescue tool. 
> It allows you to get a shell back on a
> very broken system, or to prevent a unit from starting from the 
> kernel-command-line
>
> This should really be here all the time except on very specific 
> use-cases, I don't think making it optional
> is a good idea
>
>     > +? ? ?help
>     > +? ? ? ?systemd-debug-generator is for enabling a runtime debug
>     > +? ? ? ?shell and masking specific units at boot.
>     > +
>     > +
>     https://www.freedesktop.org/software/systemd/man/systemd-debug-generator.html
>     > +
>     > +config BR2_PACKAGE_SYSTEMD_FSTAB_GENERATOR
>     > +? ? ?bool "systemd fstab generator"
>     > +? ? ?default y
>     > +? ? ?help
>     > +? ? ? ?systemd-fstab-generator is a generator that translates
>     > +? ? ? ?/etc/fstab into native systemd units early at boot
>     > +? ? ? ?and when configuration of the system manager is reloaded.
>     > +? ? ? ?This will instantiate mount and swap units as necessary.
>
>     ?Makes me realize that we probably shouldn't have an fstab in
>     skeleton-init-systemd...
>
> fstab is supported in systemd and it is not a deprecated feature.
> It is the recommended?way to automatically mount filesystems at boot.
>
> this one is really fundamental, and should really not be removed. lots 
> of things might break.
>
> there are a couple of reasons to use .mount units instead (and the 
> fstab-generator simply
> creates .mount units from /etc/fstab) but in the common case you are 
> supposed to use /etc/fstab
>
> so again, I don't think this is a good idea.
>
>
>     > +
>     > +
>     https://www.freedesktop.org/software/systemd/man/systemd-fstab-generator.html
>     > +
>     > +config BR2_PACKAGE_SYSTEMD_GETTY_GENERATOR
>     > +? ? ?bool "systemd getty generator"
>     > +? ? ?default y
>     > +? ? ?help
>     > +? ? ? ?systemd-getty-generator is a generator that automatically
>     > +? ? ? ?instantiates serial-getty at .service on the kernel
>     > +? ? ? ?console(s), if they can function as ttys and are not
>     > +? ? ? ?provided by the virtual console subsystem. It will also
>     > +? ? ? ?instantiate serial-getty at .service instances for
>     > +? ? ? ?virtualizer consoles, if execution in a virtualized
>     > +? ? ? ?environment is detected.
>     > +
>     > +
>     https://www.freedesktop.org/software/systemd/man/systemd-getty-generator.html
>     > +
>
>
> That one could be made optional, since it's about runtime-detection of 
> the right way to start a getty
> (i.e figure out if the console is a serial tty, a normal tty, or a 
> vconsole) and in the embedded case
> we usually know what we have
>
> note that it means manually enabling a service instead... which is 
> probably harder
>
> but otoh, it's typically very small and it does "the right thing" most 
> of the time. So again, probably a
> better fit for a post-image script
>
>     > +config BR2_PACKAGE_SYSTEMD_GPT_AUTO_GENERATOR
>     > +? ? ?bool "systemd gpt auto generator"
>     > +? ? ?default y
>
>     ?For this one, I also doubt that we want to have this default on.
>
>
> That one can probably be made optional, yes... it saves 34k approximately
>
>     > +? ? ?help
>     > +? ? ? ?systemd-gpt-auto-generator is a unit generator that
>     > +? ? ? ?automatically discovers root, /home/, /srv/, the EFI
>     > +? ? ? ?System Partition, the Extended Boot Loader Partition and
>     > +? ? ? ?swap partitions and creates mount and swap units for them,
>     > +? ? ? ?based on the partition type GUIDs of GUID partition tables
>     > +? ? ? ?(GPT). It implements the Discoverable Partitions
>     > +? ? ? ?Specification.
>     > +
>     > +
>     https://www.freedesktop.org/software/systemd/man/systemd-gpt-auto-generator.html
>     > +
>     > +config BR2_PACKAGE_SYSTEMD_RC_LOCAL_GENERATOR
>     > +? ? ?bool "systemd rc local generator"
>     > +? ? ?default y
>
>     ?Same here. It's pretty useless in Buildroot context.
>
>
> this one is already conditional to compiling sysV backward 
> compatibility support...
> which i think is always on in buildroot (neet to double-check that)
>
> I think having an option to enable/disable sysV support would be more 
> generic and more useful
>
>     > +? ? ?help
>     > +? ? ? ?systemd-rc-local-generator is a generator that checks
>     > +? ? ? ?whether /etc/rc.local exists and is executable,
>     > +? ? ? ?and if it is pulls the rc-local.service unit into the
>     > +? ? ? ?boot process.
>     > +
>     > +
>     https://www.freedesktop.org/software/systemd/man/systemd-rc-local-generator.html
>     > +
>     > +config BR2_PACKAGE_SYSTEMD_RUN_GENERATOR
>     > +? ? ?bool "systemd run generator"
>     > +? ? ?default y
>     > +? ? ?help
>     > +? ? ? ?systemd-run-generator is for invoking commands specified
>     > +? ? ? ?on the kernel command line as system service.
>     > +
>     > +
>     https://www.freedesktop.org/software/systemd/man/systemd-run-generator.html
>     > +
>
>
> This one could be optional... it's very usefull?for containers, less 
> for full-blown systems
>
>     > +config BR2_PACKAGE_SYSTEMD_SYSTEM_UPDATE_GENERATOR
>     > +? ? ?bool "systemd system update generator"
>     > +? ? ?default y
>     > +? ? ?help
>     > +? ? ? ?systemd-system-update-generator is a generator that
>     > +? ? ? ?automatically redirects the boot process to
>     > +? ? ? ?system-update.target, if /system-update exists.
>     > +
>     > +
>     https://www.freedesktop.org/software/systemd/man/systemd-system-update-generator.html
>     > +
>
>
> this one could be optional
>
>     > +config BR2_PACKAGE_SYSTEMD_SYSV_GENERATOR
>     > +? ? ?bool "systemd sysv generator"
>     > +? ? ?default y
>     > +? ? ?help
>     > +? ? ? ?systemd-sysv-generator is a generator that creates wrapper
>     > +? ? ? ?.service units for SysV init scripts in /etc/init.d/* at
>     > +? ? ? ?boot and when configuration of the system manager is
>     > +? ? ? ?reloaded. This will allow systemd(1) to support them
>     > +? ? ? ?similarly to native units/
>     > +
>     > +
>     https://www.freedesktop.org/software/systemd/man/systemd-system-update-generator.html
>     > +
>     > +endmenu
>     > +
>
>
> Again, i'd rather have a generic way to disable the sysV support at 
> compile time...
>
>
>
> Ok so overall, I think most generators should stay in and only one or 
> two should be made optional...
> Sorry for the negative feedback, but I don't like adding complex 
> compilation options that are not supported
> upstream, especially when all generators together wait 272k on my debian
Until we don't decide about the installation machine-id file that patch 
doesn't make any sense due to the impossibility to run those generators 
at all.

Best
Bartek
>
> The few that could legitimately be made optional are easy enough to 
> remove in a post-image that I'm not sure
> it's worth the trouble
>
> i'd?be ok for a patch doing that, though, but only for the few ones 
> that are worth it...
>
> Cheers
> Jeremy
>
> -- 
> SMILE <http://www.smile.eu/>
>
> 20 rue des Jardins
> 92600 Asni?res-sur-Seine
>
> 	
> *J?r?my ROSEN*
> Architecte technique
>
> email jeremy.rosen at smile.fr <mailto:jeremy.rosen@smile.fr>
> phone? +33 6 88 25 87 42
> url http://www.smile.eu <http://www.smile.eu/>
>
> Twitter <https://twitter.com/GroupeSmile> Facebook 
> <https://www.facebook.com/smileopensource> LinkedIn 
> <https://www.linkedin.com/company/smile> Github 
> <https://github.com/Smile-SA>
>
>
> D?couvrez l?univers Smile, rendez-vous sur smile.eu 
> <https://www.smile.eu/fr/publications/livres-blancs/yocto?utm_source=signature&utm_medium=email&utm_campaign=signature>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20191125/714955a0/attachment.html>

[Buildroot] [PATCH 2/2] package/systemd: set systemd generators instalation as optional choice

[Jérémy ROSEN]

I don't understand that remark...

generators are run at every boot and also when "systemctl daemon-reload" is
called
They have nothing to do with the machine-id or the firstboot logic...

Le lun. 25 nov. 2019 ? 17:44, Bartosz Bilas <b.bilas@grinn-global.com> a
?crit :

> Hello guys,
> On 17.11.2019 16:06, J?r?my ROSEN wrote:
>
> overall I'm not very keen on adding options for the various generators...
>
> there are special case where you want to get rid of a specific generator,
> but it's really special and probably better done in a post-image script
>
> detailed answers below
>
> Le dim. 17 nov. 2019 ? 15:12, Arnout Vandecappelle <arnout@mind.be> a
> ?crit :
>
>>
>>
>> On 17/11/2019 12:33, Bartosz Bilas wrote:
>> > Allow the user to choose which systemd generator should be installed
>> > on the target instead of installing all of them by default.
>> > That's usefull in case of when someone is using firstboot condition
>>          useful
>>
>> > and doesn't want to have e.g getty services created automatically during
>> > system boot by systemd-getty-generator. Set them enabled by default to
>> > keep compatibility with old builds.
>> >
>> > Signed-off-by: Bartosz Bilas <b.bilas@grinn-global.com>
>> > ---
>> >  package/systemd/Config.in  | 94 ++++++++++++++++++++++++++++++++++++++
>> >  package/systemd/systemd.mk | 56 +++++++++++++++++++++++
>> >  2 files changed, 150 insertions(+)
>> >
>> > diff --git a/package/systemd/Config.in b/package/systemd/Config.in
>> > index fadc1a32c8..052b69f4de 100644
>> > --- a/package/systemd/Config.in
>> > +++ b/package/systemd/Config.in
>> > @@ -112,6 +112,100 @@ config BR2_PACKAGE_SYSTEMD_BOOT_EFI_ARCH
>> >       default "x64"   if BR2_x86_64
>> >       depends on BR2_PACKAGE_SYSTEMD_BOOT
>> >
>> > +menu systemd-generators
>>
>>  I don't like adding submenus. Instead, I'd just do it with a comment.
>>
>>  However, doesn't all this depend on BR2_PACKAGE_SYSTEMD_FIRSTBOOT? In
>> that
>> case, it could be done with a condition just under that option and the
>> generators would be indented. Although, maybe they don't only get
>> executed on
>> firstboot...
>>
>>
> No... generators are a core feature of systemd, it's not related to
> first-boot in any way that I know
>
>
>
>>  So, then I'd move this section to the end of Config.in, and use a comment
>> instead of a menu.
>>
>> > +config BR2_PACKAGE_SYSTEMD_DEBUG_GENERATOR
>> > +     bool "systemd debug generator"
>> > +     default y
>>
>>  Although this one should default y for backward compatibility, I'm of a
>> mind to
>> change the default here. It doesn't sound like something you want to have
>> on by
>> default.
>>
>>
> Despite its name, this is not a debug tool, but more of a rescue tool. It
> allows you to get a shell back on a
> very broken system, or to prevent a unit from starting from the
> kernel-command-line
>
> This should really be here all the time except on very specific use-cases,
> I don't think making it optional
> is a good idea
>
>
>> > +     help
>> > +       systemd-debug-generator is for enabling a runtime debug
>> > +       shell and masking specific units at boot.
>> > +
>> > +
>> https://www.freedesktop.org/software/systemd/man/systemd-debug-generator.html
>> > +
>> > +config BR2_PACKAGE_SYSTEMD_FSTAB_GENERATOR
>> > +     bool "systemd fstab generator"
>> > +     default y
>> > +     help
>> > +       systemd-fstab-generator is a generator that translates
>> > +       /etc/fstab into native systemd units early at boot
>> > +       and when configuration of the system manager is reloaded.
>> > +       This will instantiate mount and swap units as necessary.
>>
>>  Makes me realize that we probably shouldn't have an fstab in
>> skeleton-init-systemd...
>>
>> fstab is supported in systemd and it is not a deprecated feature.
> It is the recommended way to automatically mount filesystems at boot.
>
> this one is really fundamental, and should really not be removed. lots of
> things might break.
>
> there are a couple of reasons to use .mount units instead (and the
> fstab-generator simply
> creates .mount units from /etc/fstab) but in the common case you are
> supposed to use /etc/fstab
>
> so again, I don't think this is a good idea.
>
>
>
>
>> > +
>> > +
>> https://www.freedesktop.org/software/systemd/man/systemd-fstab-generator.html
>> > +
>> > +config BR2_PACKAGE_SYSTEMD_GETTY_GENERATOR
>> > +     bool "systemd getty generator"
>> > +     default y
>> > +     help
>> > +       systemd-getty-generator is a generator that automatically
>> > +       instantiates serial-getty at .service on the kernel
>> > +       console(s), if they can function as ttys and are not
>> > +       provided by the virtual console subsystem. It will also
>> > +       instantiate serial-getty at .service instances for
>> > +       virtualizer consoles, if execution in a virtualized
>> > +       environment is detected.
>> > +
>> > +
>> https://www.freedesktop.org/software/systemd/man/systemd-getty-generator.html
>> > +
>>
>
> That one could be made optional, since it's about runtime-detection of the
> right way to start a getty
> (i.e figure out if the console is a serial tty, a normal tty, or a
> vconsole) and in the embedded case
> we usually know what we have
>
> note that it means manually enabling a service instead... which is
> probably harder
>
> but otoh, it's typically very small and it does "the right thing" most of
> the time. So again, probably a
> better fit for a post-image script
>
>
>
>> > +config BR2_PACKAGE_SYSTEMD_GPT_AUTO_GENERATOR
>> > +     bool "systemd gpt auto generator"
>> > +     default y
>>
>>  For this one, I also doubt that we want to have this default on.
>>
>>
> That one can probably be made optional, yes... it saves 34k approximately
>
>
>> > +     help
>> > +       systemd-gpt-auto-generator is a unit generator that
>> > +       automatically discovers root, /home/, /srv/, the EFI
>> > +       System Partition, the Extended Boot Loader Partition and
>> > +       swap partitions and creates mount and swap units for them,
>> > +       based on the partition type GUIDs of GUID partition tables
>> > +       (GPT). It implements the Discoverable Partitions
>> > +       Specification.
>> > +
>> > +
>> https://www.freedesktop.org/software/systemd/man/systemd-gpt-auto-generator.html
>> > +
>> > +config BR2_PACKAGE_SYSTEMD_RC_LOCAL_GENERATOR
>> > +     bool "systemd rc local generator"
>> > +     default y
>>
>>  Same here. It's pretty useless in Buildroot context.
>>
>>
> this one is already conditional to compiling sysV backward compatibility
> support...
> which i think is always on in buildroot (neet to double-check that)
>
> I think having an option to enable/disable sysV support would be more
> generic and more useful
>
>
>> > +     help
>> > +       systemd-rc-local-generator is a generator that checks
>> > +       whether /etc/rc.local exists and is executable,
>> > +       and if it is pulls the rc-local.service unit into the
>> > +       boot process.
>> > +
>> > +
>> https://www.freedesktop.org/software/systemd/man/systemd-rc-local-generator.html
>> > +
>> > +config BR2_PACKAGE_SYSTEMD_RUN_GENERATOR
>> > +     bool "systemd run generator"
>> > +     default y
>> > +     help
>> > +       systemd-run-generator is for invoking commands specified
>> > +       on the kernel command line as system service.
>> > +
>> > +
>> https://www.freedesktop.org/software/systemd/man/systemd-run-generator.html
>> > +
>>
>
> This one could be optional... it's very usefull for containers, less for
> full-blown systems
>
>
>> > +config BR2_PACKAGE_SYSTEMD_SYSTEM_UPDATE_GENERATOR
>> > +     bool "systemd system update generator"
>> > +     default y
>> > +     help
>> > +       systemd-system-update-generator is a generator that
>> > +       automatically redirects the boot process to
>> > +       system-update.target, if /system-update exists.
>> > +
>> > +
>> https://www.freedesktop.org/software/systemd/man/systemd-system-update-generator.html
>> > +
>>
>
> this one could be optional
>
>
>> > +config BR2_PACKAGE_SYSTEMD_SYSV_GENERATOR
>> > +     bool "systemd sysv generator"
>> > +     default y
>> > +     help
>> > +       systemd-sysv-generator is a generator that creates wrapper
>> > +       .service units for SysV init scripts in /etc/init.d/* at
>> > +       boot and when configuration of the system manager is
>> > +       reloaded. This will allow systemd(1) to support them
>> > +       similarly to native units/
>> > +
>> > +
>> https://www.freedesktop.org/software/systemd/man/systemd-system-update-generator.html
>> > +
>> > +endmenu
>> > +
>>
>
> Again, i'd rather have a generic way to disable the sysV support at
> compile time...
>
>
>
>
> Ok so overall, I think most generators should stay in and only one or two
> should be made optional...
> Sorry for the negative feedback, but I don't like adding complex
> compilation options that are not supported
> upstream, especially when all generators together wait 272k on my debian
>
> Until we don't decide about the installation machine-id file that patch
> doesn't make any sense due to the impossibility to run those generators at
> all.
>
> Best
> Bartek
>
>
> The few that could legitimately be made optional are easy enough to remove
> in a post-image that I'm not sure
> it's worth the trouble
>
> i'd be ok for a patch doing that, though, but only for the few ones that
> are worth it...
>
> Cheers
> Jeremy
>
> --
> [image: SMILE]  <http://www.smile.eu/>
>
> 20 rue des Jardins
> 92600 Asni?res-sur-Seine
> *J?r?my ROSEN*
> Architecte technique
>
> [image: email] jeremy.rosen at smile.fr
> [image: phone]  +33 6 88 25 87 42
> [image: url] http://www.smile.eu
>
> [image: Twitter] <https://twitter.com/GroupeSmile> [image: Facebook]
> <https://www.facebook.com/smileopensource> [image: LinkedIn]
> <https://www.linkedin.com/company/smile> [image: Github]
> <https://github.com/Smile-SA>
>
> [image: D?couvrez l?univers Smile, rendez-vous sur smile.eu]
> <https://www.smile.eu/fr/publications/livres-blancs/yocto?utm_source=signature&utm_medium=email&utm_campaign=signature>
>
>

-- 
[image: SMILE]  <http://www.smile.eu/>

20 rue des Jardins
92600 Asni?res-sur-Seine
*J?r?my ROSEN*
Architecte technique

[image: email] jeremy.rosen at smile.fr
[image: phone]  +33 6 88 25 87 42
[image: url] http://www.smile.eu

[image: Twitter] <https://twitter.com/GroupeSmile> [image: Facebook]
<https://www.facebook.com/smileopensource> [image: LinkedIn]
<https://www.linkedin.com/company/smile> [image: Github]
<https://github.com/Smile-SA>

[image: D?couvrez l?univers Smile, rendez-vous sur smile.eu]
<https://www.smile.eu/fr/publications/livres-blancs/yocto?utm_source=signature&utm_medium=email&utm_campaign=signature>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20191125/91bcc1e9/attachment.html>

[Buildroot] [PATCH 2/2] package/systemd: set systemd generators instalation as optional choice

[Bartosz Bilas]

Hello,

On 25.11.2019 17:48, J?r?my ROSEN wrote:
> I don't understand that remark...
>
> generators are run at every boot and also when "systemctl 
> daemon-reload" is called
> They have nothing to do with the machine-id or the firstboot logic...

that's weird because when I was testing I noticed the generators were 
executing only once during the first new system instance boots up. I'll 
double-check that then.

Best
Bartek
>
> Le?lun. 25 nov. 2019 ??17:44, Bartosz Bilas <b.bilas@grinn-global.com 
> <mailto:b.bilas@grinn-global.com>> a ?crit?:
>
>     Hello guys,
>
>     On 17.11.2019 16:06, J?r?my ROSEN wrote:
>>     overall I'm not very keen on adding options for the various
>>     generators...
>>
>>     there are special case where you want to get rid of a specific
>>     generator, but it's really special and probably better done in a
>>     post-image script
>>
>>     detailed answers below
>>
>>     Le?dim. 17 nov. 2019 ??15:12, Arnout Vandecappelle
>>     <arnout at mind.be <mailto:arnout@mind.be>> a ?crit?:
>>
>>
>>
>>         On 17/11/2019 12:33, Bartosz Bilas wrote:
>>         > Allow the user to choose which systemd generator should be
>>         installed
>>         > on the target instead of installing all of them by default.
>>         > That's usefull in case of when someone is using firstboot
>>         condition
>>         ? ? ? ? ?useful
>>
>>         > and doesn't want to have e.g getty services created
>>         automatically during
>>         > system boot by systemd-getty-generator. Set them enabled by
>>         default to
>>         > keep compatibility with old builds.
>>         >
>>         > Signed-off-by: Bartosz Bilas <b.bilas@grinn-global.com
>>         <mailto:b.bilas@grinn-global.com>>
>>         > ---
>>         >? package/systemd/Config.in? | 94
>>         ++++++++++++++++++++++++++++++++++++++
>>         >? package/systemd/systemd.mk <http://systemd.mk> | 56
>>         +++++++++++++++++++++++
>>         >? 2 files changed, 150 insertions(+)
>>         >
>>         > diff --git a/package/systemd/Config.in
>>         b/package/systemd/Config.in
>>         > index fadc1a32c8..052b69f4de 100644
>>         > --- a/package/systemd/Config.in
>>         > +++ b/package/systemd/Config.in
>>         > @@ -112,6 +112,100 @@ config BR2_PACKAGE_SYSTEMD_BOOT_EFI_ARCH
>>         >? ? ? ?default "x64"? ?if BR2_x86_64
>>         >? ? ? ?depends on BR2_PACKAGE_SYSTEMD_BOOT
>>         >
>>         > +menu systemd-generators
>>
>>         ?I don't like adding submenus. Instead, I'd just do it with a
>>         comment.
>>
>>         ?However, doesn't all this depend on
>>         BR2_PACKAGE_SYSTEMD_FIRSTBOOT? In that
>>         case, it could be done with a condition just under that
>>         option and the
>>         generators would be indented. Although, maybe they don't only
>>         get executed on
>>         firstboot...
>>
>>
>>     No... generators are a core feature of systemd, it's not related
>>     to first-boot in any way that I know
>>
>>         ?So, then I'd move this section to the end of Config.in, and
>>         use a comment
>>         instead of a menu.
>>
>>         > +config BR2_PACKAGE_SYSTEMD_DEBUG_GENERATOR
>>         > +? ? ?bool "systemd debug generator"
>>         > +? ? ?default y
>>
>>         ?Although this one should default y for backward
>>         compatibility, I'm of a mind to
>>         change the default here. It doesn't sound like something you
>>         want to have on by
>>         default.
>>
>>
>>     Despite its name, this is not a debug tool, but more of a rescue
>>     tool. It allows you to get a shell back on a
>>     very broken system, or to prevent a unit from starting from the
>>     kernel-command-line
>>
>>     This should really be here all the time except on very specific
>>     use-cases, I don't think making it optional
>>     is a good idea
>>
>>         > +? ? ?help
>>         > +? ? ? ?systemd-debug-generator is for enabling a runtime debug
>>         > +? ? ? ?shell and masking specific units at boot.
>>         > +
>>         > +
>>         https://www.freedesktop.org/software/systemd/man/systemd-debug-generator.html
>>         > +
>>         > +config BR2_PACKAGE_SYSTEMD_FSTAB_GENERATOR
>>         > +? ? ?bool "systemd fstab generator"
>>         > +? ? ?default y
>>         > +? ? ?help
>>         > +? ? ? ?systemd-fstab-generator is a generator that translates
>>         > +? ? ? ?/etc/fstab into native systemd units early at boot
>>         > +? ? ? ?and when configuration of the system manager is
>>         reloaded.
>>         > +? ? ? ?This will instantiate mount and swap units as
>>         necessary.
>>
>>         ?Makes me realize that we probably shouldn't have an fstab in
>>         skeleton-init-systemd...
>>
>>     fstab is supported in systemd and it is not a deprecated feature.
>>     It is the recommended?way to automatically mount filesystems at boot.
>>
>>     this one is really fundamental, and should really not be removed.
>>     lots of things might break.
>>
>>     there are a couple of reasons to use .mount units instead (and
>>     the fstab-generator simply
>>     creates .mount units from /etc/fstab) but in the common case you
>>     are supposed to use /etc/fstab
>>
>>     so again, I don't think this is a good idea.
>>
>>
>>         > +
>>         > +
>>         https://www.freedesktop.org/software/systemd/man/systemd-fstab-generator.html
>>         > +
>>         > +config BR2_PACKAGE_SYSTEMD_GETTY_GENERATOR
>>         > +? ? ?bool "systemd getty generator"
>>         > +? ? ?default y
>>         > +? ? ?help
>>         > +? ? ? ?systemd-getty-generator is a generator that
>>         automatically
>>         > +? ? ? ?instantiates serial-getty at .service
>>         <mailto:serial-getty@.service> on the kernel
>>         > +? ? ? ?console(s), if they can function as ttys and are not
>>         > +? ? ? ?provided by the virtual console subsystem. It will also
>>         > +? ? ? ?instantiate serial-getty at .service
>>         <mailto:serial-getty@.service> instances for
>>         > +? ? ? ?virtualizer consoles, if execution in a virtualized
>>         > +? ? ? ?environment is detected.
>>         > +
>>         > +
>>         https://www.freedesktop.org/software/systemd/man/systemd-getty-generator.html
>>         > +
>>
>>
>>     That one could be made optional, since it's about
>>     runtime-detection of the right way to start a getty
>>     (i.e figure out if the console is a serial tty, a normal tty, or
>>     a vconsole) and in the embedded case
>>     we usually know what we have
>>
>>     note that it means manually enabling a service instead... which
>>     is probably harder
>>
>>     but otoh, it's typically very small and it does "the right thing"
>>     most of the time. So again, probably a
>>     better fit for a post-image script
>>
>>         > +config BR2_PACKAGE_SYSTEMD_GPT_AUTO_GENERATOR
>>         > +? ? ?bool "systemd gpt auto generator"
>>         > +? ? ?default y
>>
>>         ?For this one, I also doubt that we want to have this default on.
>>
>>
>>     That one can probably be made optional, yes... it saves 34k
>>     approximately
>>
>>         > +? ? ?help
>>         > +? ? ? ?systemd-gpt-auto-generator is a unit generator that
>>         > +? ? ? ?automatically discovers root, /home/, /srv/, the EFI
>>         > +? ? ? ?System Partition, the Extended Boot Loader
>>         Partition and
>>         > +? ? ? ?swap partitions and creates mount and swap units
>>         for them,
>>         > +? ? ? ?based on the partition type GUIDs of GUID partition
>>         tables
>>         > +? ? ? ?(GPT). It implements the Discoverable Partitions
>>         > +? ? ? ?Specification.
>>         > +
>>         > +
>>         https://www.freedesktop.org/software/systemd/man/systemd-gpt-auto-generator.html
>>         > +
>>         > +config BR2_PACKAGE_SYSTEMD_RC_LOCAL_GENERATOR
>>         > +? ? ?bool "systemd rc local generator"
>>         > +? ? ?default y
>>
>>         ?Same here. It's pretty useless in Buildroot context.
>>
>>
>>     this one is already conditional to compiling sysV backward
>>     compatibility support...
>>     which i think is always on in buildroot (neet to double-check that)
>>
>>     I think having an option to enable/disable sysV support would be
>>     more generic and more useful
>>
>>         > +? ? ?help
>>         > +? ? ? ?systemd-rc-local-generator is a generator that checks
>>         > +? ? ? ?whether /etc/rc.local exists and is executable,
>>         > +? ? ? ?and if it is pulls the rc-local.service unit into the
>>         > +? ? ? ?boot process.
>>         > +
>>         > +
>>         https://www.freedesktop.org/software/systemd/man/systemd-rc-local-generator.html
>>         > +
>>         > +config BR2_PACKAGE_SYSTEMD_RUN_GENERATOR
>>         > +? ? ?bool "systemd run generator"
>>         > +? ? ?default y
>>         > +? ? ?help
>>         > +? ? ? ?systemd-run-generator is for invoking commands
>>         specified
>>         > +? ? ? ?on the kernel command line as system service.
>>         > +
>>         > +
>>         https://www.freedesktop.org/software/systemd/man/systemd-run-generator.html
>>         > +
>>
>>
>>     This one could be optional... it's very usefull?for containers,
>>     less for full-blown systems
>>
>>         > +config BR2_PACKAGE_SYSTEMD_SYSTEM_UPDATE_GENERATOR
>>         > +? ? ?bool "systemd system update generator"
>>         > +? ? ?default y
>>         > +? ? ?help
>>         > +? ? ? ?systemd-system-update-generator is a generator that
>>         > +? ? ? ?automatically redirects the boot process to
>>         > +? ? ? ?system-update.target, if /system-update exists.
>>         > +
>>         > +
>>         https://www.freedesktop.org/software/systemd/man/systemd-system-update-generator.html
>>         > +
>>
>>
>>     this one could be optional
>>
>>         > +config BR2_PACKAGE_SYSTEMD_SYSV_GENERATOR
>>         > +? ? ?bool "systemd sysv generator"
>>         > +? ? ?default y
>>         > +? ? ?help
>>         > +? ? ? ?systemd-sysv-generator is a generator that creates
>>         wrapper
>>         > +? ? ? ?.service units for SysV init scripts in
>>         /etc/init.d/* at
>>         > +? ? ? ?boot and when configuration of the system manager is
>>         > +? ? ? ?reloaded. This will allow systemd(1) to support them
>>         > +? ? ? ?similarly to native units/
>>         > +
>>         > +
>>         https://www.freedesktop.org/software/systemd/man/systemd-system-update-generator.html
>>         > +
>>         > +endmenu
>>         > +
>>
>>
>>     Again, i'd rather have a generic way to disable the sysV support
>>     at compile time...
>>
>>
>>
>>     Ok so overall, I think most generators should stay in and only
>>     one or two should be made optional...
>>     Sorry for the negative feedback, but I don't like adding complex
>>     compilation options that are not supported
>>     upstream, especially when all generators together wait 272k on my
>>     debian
>     Until we don't decide about the installation machine-id file that
>     patch doesn't make any sense due to the impossibility to run those
>     generators at all.
>
>     Best
>     Bartek
>>
>>     The few that could legitimately be made optional are easy enough
>>     to remove in a post-image that I'm not sure
>>     it's worth the trouble
>>
>>     i'd?be ok for a patch doing that, though, but only for the few
>>     ones that are worth it...
>>
>>     Cheers
>>     Jeremy
>>
>>     -- 
>>     SMILE <http://www.smile.eu/>
>>
>>     20 rue des Jardins
>>     92600 Asni?res-sur-Seine
>>
>>     	
>>     *J?r?my ROSEN*
>>     Architecte technique
>>
>>     email jeremy.rosen at smile.fr <mailto:jeremy.rosen@smile.fr>
>>     phone? +33 6 88 25 87 42
>>     url http://www.smile.eu <http://www.smile.eu/>
>>
>>     Twitter <https://twitter.com/GroupeSmile> Facebook
>>     <https://www.facebook.com/smileopensource> LinkedIn
>>     <https://www.linkedin.com/company/smile> Github
>>     <https://github.com/Smile-SA>
>>
>>
>>     D?couvrez l?univers Smile, rendez-vous sur smile.eu
>>     <https://www.smile.eu/fr/publications/livres-blancs/yocto?utm_source=signature&utm_medium=email&utm_campaign=signature>
>
>
>
> -- 
> SMILE <http://www.smile.eu/>
>
> 20 rue des Jardins
> 92600 Asni?res-sur-Seine
>
> 	
> *J?r?my ROSEN*
> Architecte technique
>
> email jeremy.rosen at smile.fr <mailto:jeremy.rosen@smile.fr>
> phone? +33 6 88 25 87 42
> url http://www.smile.eu <http://www.smile.eu/>
>
> Twitter <https://twitter.com/GroupeSmile> Facebook 
> <https://www.facebook.com/smileopensource> LinkedIn 
> <https://www.linkedin.com/company/smile> Github 
> <https://github.com/Smile-SA>
>
>
> D?couvrez l?univers Smile, rendez-vous sur smile.eu 
> <https://www.smile.eu/fr/publications/livres-blancs/yocto?utm_source=signature&utm_medium=email&utm_campaign=signature>
>
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20191125/d68c75f9/attachment.html>

[Buildroot] [PATCH 2/2] package/systemd: set systemd generators instalation as optional choice

[Jérémy ROSEN]

That's very weird... I'm absolutely certain that generators are (supposed
to) run on config reload and every reboot.
The files they create are stored under /run, so they are destroyed on every
reboot.

Either you have some bug somewhere or you misdiagnosed something...

Do not that generators are run *very early* in the boot (before the unit
files are even loaded) so stuff like journald are not around yet.
The best way to check if they are run might be to create a tiny generator
that saves the current date and time in /run or something like that...

Jeremy


Le lun. 25 nov. 2019 ? 17:55, Bartosz Bilas <b.bilas@grinn-global.com> a
?crit :

> Hello,
> On 25.11.2019 17:48, J?r?my ROSEN wrote:
>
> I don't understand that remark...
>
> generators are run at every boot and also when "systemctl daemon-reload"
> is called
> They have nothing to do with the machine-id or the firstboot logic...
>
> that's weird because when I was testing I noticed the generators were
> executing only once during the first new system instance boots up. I'll
> double-check that then.
> Best
> Bartek
>
>
> Le lun. 25 nov. 2019 ? 17:44, Bartosz Bilas <b.bilas@grinn-global.com> a
> ?crit :
>
>> Hello guys,
>> On 17.11.2019 16:06, J?r?my ROSEN wrote:
>>
>> overall I'm not very keen on adding options for the various generators...
>>
>> there are special case where you want to get rid of a specific generator,
>> but it's really special and probably better done in a post-image script
>>
>> detailed answers below
>>
>> Le dim. 17 nov. 2019 ? 15:12, Arnout Vandecappelle <arnout@mind.be> a
>> ?crit :
>>
>>>
>>>
>>> On 17/11/2019 12:33, Bartosz Bilas wrote:
>>> > Allow the user to choose which systemd generator should be installed
>>> > on the target instead of installing all of them by default.
>>> > That's usefull in case of when someone is using firstboot condition
>>>          useful
>>>
>>> > and doesn't want to have e.g getty services created automatically
>>> during
>>> > system boot by systemd-getty-generator. Set them enabled by default to
>>> > keep compatibility with old builds.
>>> >
>>> > Signed-off-by: Bartosz Bilas <b.bilas@grinn-global.com>
>>> > ---
>>> >  package/systemd/Config.in  | 94 ++++++++++++++++++++++++++++++++++++++
>>> >  package/systemd/systemd.mk | 56 +++++++++++++++++++++++
>>> >  2 files changed, 150 insertions(+)
>>> >
>>> > diff --git a/package/systemd/Config.in b/package/systemd/Config.in
>>> > index fadc1a32c8..052b69f4de 100644
>>> > --- a/package/systemd/Config.in
>>> > +++ b/package/systemd/Config.in
>>> > @@ -112,6 +112,100 @@ config BR2_PACKAGE_SYSTEMD_BOOT_EFI_ARCH
>>> >       default "x64"   if BR2_x86_64
>>> >       depends on BR2_PACKAGE_SYSTEMD_BOOT
>>> >
>>> > +menu systemd-generators
>>>
>>>  I don't like adding submenus. Instead, I'd just do it with a comment.
>>>
>>>  However, doesn't all this depend on BR2_PACKAGE_SYSTEMD_FIRSTBOOT? In
>>> that
>>> case, it could be done with a condition just under that option and the
>>> generators would be indented. Although, maybe they don't only get
>>> executed on
>>> firstboot...
>>>
>>>
>> No... generators are a core feature of systemd, it's not related to
>> first-boot in any way that I know
>>
>>
>>
>>>  So, then I'd move this section to the end of Config.in, and use a
>>> comment
>>> instead of a menu.
>>>
>>> > +config BR2_PACKAGE_SYSTEMD_DEBUG_GENERATOR
>>> > +     bool "systemd debug generator"
>>> > +     default y
>>>
>>>  Although this one should default y for backward compatibility, I'm of a
>>> mind to
>>> change the default here. It doesn't sound like something you want to
>>> have on by
>>> default.
>>>
>>>
>> Despite its name, this is not a debug tool, but more of a rescue tool. It
>> allows you to get a shell back on a
>> very broken system, or to prevent a unit from starting from the
>> kernel-command-line
>>
>> This should really be here all the time except on very specific
>> use-cases, I don't think making it optional
>> is a good idea
>>
>>
>>> > +     help
>>> > +       systemd-debug-generator is for enabling a runtime debug
>>> > +       shell and masking specific units at boot.
>>> > +
>>> > +
>>> https://www.freedesktop.org/software/systemd/man/systemd-debug-generator.html
>>> > +
>>> > +config BR2_PACKAGE_SYSTEMD_FSTAB_GENERATOR
>>> > +     bool "systemd fstab generator"
>>> > +     default y
>>> > +     help
>>> > +       systemd-fstab-generator is a generator that translates
>>> > +       /etc/fstab into native systemd units early at boot
>>> > +       and when configuration of the system manager is reloaded.
>>> > +       This will instantiate mount and swap units as necessary.
>>>
>>>  Makes me realize that we probably shouldn't have an fstab in
>>> skeleton-init-systemd...
>>>
>>> fstab is supported in systemd and it is not a deprecated feature.
>> It is the recommended way to automatically mount filesystems at boot.
>>
>> this one is really fundamental, and should really not be removed. lots of
>> things might break.
>>
>> there are a couple of reasons to use .mount units instead (and the
>> fstab-generator simply
>> creates .mount units from /etc/fstab) but in the common case you are
>> supposed to use /etc/fstab
>>
>> so again, I don't think this is a good idea.
>>
>>
>>
>>
>>> > +
>>> > +
>>> https://www.freedesktop.org/software/systemd/man/systemd-fstab-generator.html
>>> > +
>>> > +config BR2_PACKAGE_SYSTEMD_GETTY_GENERATOR
>>> > +     bool "systemd getty generator"
>>> > +     default y
>>> > +     help
>>> > +       systemd-getty-generator is a generator that automatically
>>> > +       instantiates serial-getty at .service on the kernel
>>> > +       console(s), if they can function as ttys and are not
>>> > +       provided by the virtual console subsystem. It will also
>>> > +       instantiate serial-getty at .service instances for
>>> > +       virtualizer consoles, if execution in a virtualized
>>> > +       environment is detected.
>>> > +
>>> > +
>>> https://www.freedesktop.org/software/systemd/man/systemd-getty-generator.html
>>> > +
>>>
>>
>> That one could be made optional, since it's about runtime-detection of
>> the right way to start a getty
>> (i.e figure out if the console is a serial tty, a normal tty, or a
>> vconsole) and in the embedded case
>> we usually know what we have
>>
>> note that it means manually enabling a service instead... which is
>> probably harder
>>
>> but otoh, it's typically very small and it does "the right thing" most of
>> the time. So again, probably a
>> better fit for a post-image script
>>
>>
>>
>>> > +config BR2_PACKAGE_SYSTEMD_GPT_AUTO_GENERATOR
>>> > +     bool "systemd gpt auto generator"
>>> > +     default y
>>>
>>>  For this one, I also doubt that we want to have this default on.
>>>
>>>
>> That one can probably be made optional, yes... it saves 34k approximately
>>
>>
>>> > +     help
>>> > +       systemd-gpt-auto-generator is a unit generator that
>>> > +       automatically discovers root, /home/, /srv/, the EFI
>>> > +       System Partition, the Extended Boot Loader Partition and
>>> > +       swap partitions and creates mount and swap units for them,
>>> > +       based on the partition type GUIDs of GUID partition tables
>>> > +       (GPT). It implements the Discoverable Partitions
>>> > +       Specification.
>>> > +
>>> > +
>>> https://www.freedesktop.org/software/systemd/man/systemd-gpt-auto-generator.html
>>> > +
>>> > +config BR2_PACKAGE_SYSTEMD_RC_LOCAL_GENERATOR
>>> > +     bool "systemd rc local generator"
>>> > +     default y
>>>
>>>  Same here. It's pretty useless in Buildroot context.
>>>
>>>
>> this one is already conditional to compiling sysV backward compatibility
>> support...
>> which i think is always on in buildroot (neet to double-check that)
>>
>> I think having an option to enable/disable sysV support would be more
>> generic and more useful
>>
>>
>>> > +     help
>>> > +       systemd-rc-local-generator is a generator that checks
>>> > +       whether /etc/rc.local exists and is executable,
>>> > +       and if it is pulls the rc-local.service unit into the
>>> > +       boot process.
>>> > +
>>> > +
>>> https://www.freedesktop.org/software/systemd/man/systemd-rc-local-generator.html
>>> > +
>>> > +config BR2_PACKAGE_SYSTEMD_RUN_GENERATOR
>>> > +     bool "systemd run generator"
>>> > +     default y
>>> > +     help
>>> > +       systemd-run-generator is for invoking commands specified
>>> > +       on the kernel command line as system service.
>>> > +
>>> > +
>>> https://www.freedesktop.org/software/systemd/man/systemd-run-generator.html
>>> > +
>>>
>>
>> This one could be optional... it's very usefull for containers, less for
>> full-blown systems
>>
>>
>>> > +config BR2_PACKAGE_SYSTEMD_SYSTEM_UPDATE_GENERATOR
>>> > +     bool "systemd system update generator"
>>> > +     default y
>>> > +     help
>>> > +       systemd-system-update-generator is a generator that
>>> > +       automatically redirects the boot process to
>>> > +       system-update.target, if /system-update exists.
>>> > +
>>> > +
>>> https://www.freedesktop.org/software/systemd/man/systemd-system-update-generator.html
>>> > +
>>>
>>
>> this one could be optional
>>
>>
>>> > +config BR2_PACKAGE_SYSTEMD_SYSV_GENERATOR
>>> > +     bool "systemd sysv generator"
>>> > +     default y
>>> > +     help
>>> > +       systemd-sysv-generator is a generator that creates wrapper
>>> > +       .service units for SysV init scripts in /etc/init.d/* at
>>> > +       boot and when configuration of the system manager is
>>> > +       reloaded. This will allow systemd(1) to support them
>>> > +       similarly to native units/
>>> > +
>>> > +
>>> https://www.freedesktop.org/software/systemd/man/systemd-system-update-generator.html
>>> > +
>>> > +endmenu
>>> > +
>>>
>>
>> Again, i'd rather have a generic way to disable the sysV support at
>> compile time...
>>
>>
>>
>>
>> Ok so overall, I think most generators should stay in and only one or two
>> should be made optional...
>> Sorry for the negative feedback, but I don't like adding complex
>> compilation options that are not supported
>> upstream, especially when all generators together wait 272k on my debian
>>
>> Until we don't decide about the installation machine-id file that patch
>> doesn't make any sense due to the impossibility to run those generators at
>> all.
>>
>> Best
>> Bartek
>>
>>
>> The few that could legitimately be made optional are easy enough to
>> remove in a post-image that I'm not sure
>> it's worth the trouble
>>
>> i'd be ok for a patch doing that, though, but only for the few ones that
>> are worth it...
>>
>> Cheers
>> Jeremy
>>
>> --
>> [image: SMILE]  <http://www.smile.eu/>
>>
>> 20 rue des Jardins
>> 92600 Asni?res-sur-Seine
>> *J?r?my ROSEN*
>> Architecte technique
>>
>> [image: email] jeremy.rosen at smile.fr
>> [image: phone]  +33 6 88 25 87 42
>> [image: url] http://www.smile.eu
>>
>> [image: Twitter] <https://twitter.com/GroupeSmile> [image: Facebook]
>> <https://www.facebook.com/smileopensource> [image: LinkedIn]
>> <https://www.linkedin.com/company/smile> [image: Github]
>> <https://github.com/Smile-SA>
>>
>> [image: D?couvrez l?univers Smile, rendez-vous sur smile.eu]
>> <https://www.smile.eu/fr/publications/livres-blancs/yocto?utm_source=signature&utm_medium=email&utm_campaign=signature>
>>
>>
>
> --
> [image: SMILE]  <http://www.smile.eu/>
>
> 20 rue des Jardins
> 92600 Asni?res-sur-Seine
> *J?r?my ROSEN*
> Architecte technique
>
> [image: email] jeremy.rosen at smile.fr
> [image: phone]  +33 6 88 25 87 42
> [image: url] http://www.smile.eu
>
> [image: Twitter] <https://twitter.com/GroupeSmile> [image: Facebook]
> <https://www.facebook.com/smileopensource> [image: LinkedIn]
> <https://www.linkedin.com/company/smile> [image: Github]
> <https://github.com/Smile-SA>
>
> [image: D?couvrez l?univers Smile, rendez-vous sur smile.eu]
> <https://www.smile.eu/fr/publications/livres-blancs/yocto?utm_source=signature&utm_medium=email&utm_campaign=signature>
>
> _______________________________________________
> buildroot mailing listbuildroot at busybox.nethttp://lists.busybox.net/mailman/listinfo/buildroot
>
>

-- 
[image: SMILE]  <http://www.smile.eu/>

20 rue des Jardins
92600 Asni?res-sur-Seine
*J?r?my ROSEN*
Architecte technique

[image: email] jeremy.rosen at smile.fr
[image: phone]  +33 6 88 25 87 42
[image: url] http://www.smile.eu

[image: Twitter] <https://twitter.com/GroupeSmile> [image: Facebook]
<https://www.facebook.com/smileopensource> [image: LinkedIn]
<https://www.linkedin.com/company/smile> [image: Github]
<https://github.com/Smile-SA>

[image: D?couvrez l?univers Smile, rendez-vous sur smile.eu]
<https://www.smile.eu/fr/publications/livres-blancs/yocto?utm_source=signature&utm_medium=email&utm_campaign=signature>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20191125/b36b8a36/attachment-0001.html>

[Buildroot] [PATCH 2/2] package/systemd: set systemd generators instalation as optional choice

[Bartosz Bilas]

Hi everyone,

I had finally a couple of time to double-check that and I agree with 
Jeremy that I was wrong therefore let's reject this patch as it turned 
out as an unthought idea.


Best
Bartek
On 25.11.2019 18:02, J?r?my ROSEN wrote:
> That's very weird... I'm absolutely certain that generators are 
> (supposed to) run on config reload and every reboot.
> The files they create are stored under /run, so they are destroyed on 
> every reboot.
>
> Either you have some bug somewhere or you misdiagnosed something...
>
> Do not that generators are run *very early* in the boot (before the 
> unit files are even loaded) so stuff like journald are not around yet.
> The best way to check if they are run might be to create a tiny 
> generator that saves the current date and time in /run or something 
> like that...
>
> Jeremy
>
>
> Le?lun. 25 nov. 2019 ??17:55, Bartosz Bilas <b.bilas@grinn-global.com 
> <mailto:b.bilas@grinn-global.com>> a ?crit?:
>
>     Hello,
>
>     On 25.11.2019 17:48, J?r?my ROSEN wrote:
>>     I don't understand that remark...
>>
>>     generators are run at every boot and also when "systemctl
>>     daemon-reload" is called
>>     They have nothing to do with the machine-id or the firstboot logic...
>
>     that's weird because when I was testing I noticed the generators
>     were executing only once during the first new system instance
>     boots up. I'll double-check that then.
>
>     Best
>     Bartek
>>
>>     Le?lun. 25 nov. 2019 ??17:44, Bartosz Bilas
>>     <b.bilas at grinn-global.com <mailto:b.bilas@grinn-global.com>> a
>>     ?crit?:
>>
>>         Hello guys,
>>
>>         On 17.11.2019 16:06, J?r?my ROSEN wrote:
>>>         overall I'm not very keen on adding options for the various
>>>         generators...
>>>
>>>         there are special case where you want to get rid of a
>>>         specific generator, but it's really special and probably
>>>         better done in a post-image script
>>>
>>>         detailed answers below
>>>
>>>         Le?dim. 17 nov. 2019 ??15:12, Arnout Vandecappelle
>>>         <arnout at mind.be <mailto:arnout@mind.be>> a ?crit?:
>>>
>>>
>>>
>>>             On 17/11/2019 12:33, Bartosz Bilas wrote:
>>>             > Allow the user to choose which systemd generator
>>>             should be installed
>>>             > on the target instead of installing all of them by
>>>             default.
>>>             > That's usefull in case of when someone is using
>>>             firstboot condition
>>>             ? ? ? ? ?useful
>>>
>>>             > and doesn't want to have e.g getty services created
>>>             automatically during
>>>             > system boot by systemd-getty-generator. Set them
>>>             enabled by default to
>>>             > keep compatibility with old builds.
>>>             >
>>>             > Signed-off-by: Bartosz Bilas <b.bilas@grinn-global.com
>>>             <mailto:b.bilas@grinn-global.com>>
>>>             > ---
>>>             >? package/systemd/Config.in? | 94
>>>             ++++++++++++++++++++++++++++++++++++++
>>>             >? package/systemd/systemd.mk <http://systemd.mk> | 56
>>>             +++++++++++++++++++++++
>>>             >? 2 files changed, 150 insertions(+)
>>>             >
>>>             > diff --git a/package/systemd/Config.in
>>>             b/package/systemd/Config.in
>>>             > index fadc1a32c8..052b69f4de 100644
>>>             > --- a/package/systemd/Config.in
>>>             > +++ b/package/systemd/Config.in
>>>             > @@ -112,6 +112,100 @@ config
>>>             BR2_PACKAGE_SYSTEMD_BOOT_EFI_ARCH
>>>             >? ? ? ?default "x64"? ?if BR2_x86_64
>>>             >? ? ? ?depends on BR2_PACKAGE_SYSTEMD_BOOT
>>>             >
>>>             > +menu systemd-generators
>>>
>>>             ?I don't like adding submenus. Instead, I'd just do it
>>>             with a comment.
>>>
>>>             ?However, doesn't all this depend on
>>>             BR2_PACKAGE_SYSTEMD_FIRSTBOOT? In that
>>>             case, it could be done with a condition just under that
>>>             option and the
>>>             generators would be indented. Although, maybe they don't
>>>             only get executed on
>>>             firstboot...
>>>
>>>
>>>         No... generators are a core feature of systemd, it's not
>>>         related to first-boot in any way that I know
>>>
>>>             ?So, then I'd move this section to the end of Config.in,
>>>             and use a comment
>>>             instead of a menu.
>>>
>>>             > +config BR2_PACKAGE_SYSTEMD_DEBUG_GENERATOR
>>>             > +? ? ?bool "systemd debug generator"
>>>             > +? ? ?default y
>>>
>>>             ?Although this one should default y for backward
>>>             compatibility, I'm of a mind to
>>>             change the default here. It doesn't sound like something
>>>             you want to have on by
>>>             default.
>>>
>>>
>>>         Despite its name, this is not a debug tool, but more of a
>>>         rescue tool. It allows you to get a shell back on a
>>>         very broken system, or to prevent a unit from starting from
>>>         the kernel-command-line
>>>
>>>         This should really be here all the time except on very
>>>         specific use-cases, I don't think making it optional
>>>         is a good idea
>>>
>>>             > + ? ?help
>>>             > +? ? ? ?systemd-debug-generator is for enabling a
>>>             runtime debug
>>>             > +? ? ? ?shell and masking specific units at boot.
>>>             > +
>>>             > +
>>>             https://www.freedesktop.org/software/systemd/man/systemd-debug-generator.html
>>>             > +
>>>             > +config BR2_PACKAGE_SYSTEMD_FSTAB_GENERATOR
>>>             > +? ? ?bool "systemd fstab generator"
>>>             > +? ? ?default y
>>>             > +? ? ?help
>>>             > +? ? ? ?systemd-fstab-generator is a generator that
>>>             translates
>>>             > +? ? ? ?/etc/fstab into native systemd units early at boot
>>>             > +? ? ? ?and when configuration of the system manager
>>>             is reloaded.
>>>             > +? ? ? ?This will instantiate mount and swap units as
>>>             necessary.
>>>
>>>             ?Makes me realize that we probably shouldn't have an
>>>             fstab in
>>>             skeleton-init-systemd...
>>>
>>>         fstab is supported in systemd and it is not a deprecated
>>>         feature.
>>>         It is the recommended?way to automatically mount filesystems
>>>         at boot.
>>>
>>>         this one is really fundamental, and should really not be
>>>         removed. lots of things might break.
>>>
>>>         there are a couple of reasons to use .mount units instead
>>>         (and the fstab-generator simply
>>>         creates .mount units from /etc/fstab) but in the common case
>>>         you are supposed to use /etc/fstab
>>>
>>>         so again, I don't think this is a good idea.
>>>
>>>
>>>             > +
>>>             > +
>>>             https://www.freedesktop.org/software/systemd/man/systemd-fstab-generator.html
>>>             > +
>>>             > +config BR2_PACKAGE_SYSTEMD_GETTY_GENERATOR
>>>             > +? ? ?bool "systemd getty generator"
>>>             > +? ? ?default y
>>>             > +? ? ?help
>>>             > +? ? ? ?systemd-getty-generator is a generator that
>>>             automatically
>>>             > +? ? ? ?instantiates serial-getty at .service
>>>             <mailto:serial-getty@.service> on the kernel
>>>             > +? ? ? ?console(s), if they can function as ttys and
>>>             are not
>>>             > +? ? ? ?provided by the virtual console subsystem. It
>>>             will also
>>>             > +? ? ? ?instantiate serial-getty at .service
>>>             <mailto:serial-getty@.service> instances for
>>>             > +? ? ? ?virtualizer consoles, if execution in a
>>>             virtualized
>>>             > +? ? ? ?environment is detected.
>>>             > +
>>>             > +
>>>             https://www.freedesktop.org/software/systemd/man/systemd-getty-generator.html
>>>             > +
>>>
>>>
>>>         That one could be made optional, since it's about
>>>         runtime-detection of the right way to start a getty
>>>         (i.e figure out if the console is a serial tty, a normal
>>>         tty, or a vconsole) and in the embedded case
>>>         we usually know what we have
>>>
>>>         note that it means manually enabling a service instead...
>>>         which is probably harder
>>>
>>>         but otoh, it's typically very small and it does "the right
>>>         thing" most of the time. So again, probably a
>>>         better fit for a post-image script
>>>
>>>             > +config BR2_PACKAGE_SYSTEMD_GPT_AUTO_GENERATOR
>>>             > +? ? ?bool "systemd gpt auto generator"
>>>             > +? ? ?default y
>>>
>>>             ?For this one, I also doubt that we want to have this
>>>             default on.
>>>
>>>
>>>         That one can probably be made optional, yes... it saves 34k
>>>         approximately
>>>
>>>             > + ? ?help
>>>             > +? ? ? ?systemd-gpt-auto-generator is a unit generator
>>>             that
>>>             > +? ? ? ?automatically discovers root, /home/, /srv/,
>>>             the EFI
>>>             > +? ? ? ?System Partition, the Extended Boot Loader
>>>             Partition and
>>>             > +? ? ? ?swap partitions and creates mount and swap
>>>             units for them,
>>>             > +? ? ? ?based on the partition type GUIDs of GUID
>>>             partition tables
>>>             > +? ? ? ?(GPT). It implements the Discoverable Partitions
>>>             > +? ? ? ?Specification.
>>>             > +
>>>             > +
>>>             https://www.freedesktop.org/software/systemd/man/systemd-gpt-auto-generator.html
>>>             > +
>>>             > +config BR2_PACKAGE_SYSTEMD_RC_LOCAL_GENERATOR
>>>             > +? ? ?bool "systemd rc local generator"
>>>             > +? ? ?default y
>>>
>>>             ?Same here. It's pretty useless in Buildroot context.
>>>
>>>
>>>         this one is already conditional to compiling sysV backward
>>>         compatibility support...
>>>         which i think is always on in buildroot (neet to
>>>         double-check that)
>>>
>>>         I think having an option to enable/disable sysV support
>>>         would be more generic and more useful
>>>
>>>             > + ? ?help
>>>             > +? ? ? ?systemd-rc-local-generator is a generator that
>>>             checks
>>>             > +? ? ? ?whether /etc/rc.local exists and is executable,
>>>             > +? ? ? ?and if it is pulls the rc-local.service unit
>>>             into the
>>>             > +? ? ? ?boot process.
>>>             > +
>>>             > +
>>>             https://www.freedesktop.org/software/systemd/man/systemd-rc-local-generator.html
>>>             > +
>>>             > +config BR2_PACKAGE_SYSTEMD_RUN_GENERATOR
>>>             > +? ? ?bool "systemd run generator"
>>>             > +? ? ?default y
>>>             > +? ? ?help
>>>             > +? ? ? ?systemd-run-generator is for invoking commands
>>>             specified
>>>             > +? ? ? ?on the kernel command line as system service.
>>>             > +
>>>             > +
>>>             https://www.freedesktop.org/software/systemd/man/systemd-run-generator.html
>>>             > +
>>>
>>>
>>>         This one could be optional... it's very usefull?for
>>>         containers, less for full-blown systems
>>>
>>>             > +config BR2_PACKAGE_SYSTEMD_SYSTEM_UPDATE_GENERATOR
>>>             > +? ? ?bool "systemd system update generator"
>>>             > +? ? ?default y
>>>             > +? ? ?help
>>>             > +? ? ? ?systemd-system-update-generator is a generator
>>>             that
>>>             > +? ? ? ?automatically redirects the boot process to
>>>             > +? ? ? ?system-update.target, if /system-update exists.
>>>             > +
>>>             > +
>>>             https://www.freedesktop.org/software/systemd/man/systemd-system-update-generator.html
>>>             > +
>>>
>>>
>>>         this one could be optional
>>>
>>>             > +config BR2_PACKAGE_SYSTEMD_SYSV_GENERATOR
>>>             > +? ? ?bool "systemd sysv generator"
>>>             > +? ? ?default y
>>>             > +? ? ?help
>>>             > +? ? ? ?systemd-sysv-generator is a generator that
>>>             creates wrapper
>>>             > +? ? ? ?.service units for SysV init scripts in
>>>             /etc/init.d/* at
>>>             > +? ? ? ?boot and when configuration of the system
>>>             manager is
>>>             > +? ? ? ?reloaded. This will allow systemd(1) to
>>>             support them
>>>             > +? ? ? ?similarly to native units/
>>>             > +
>>>             > +
>>>             https://www.freedesktop.org/software/systemd/man/systemd-system-update-generator.html
>>>             > +
>>>             > +endmenu
>>>             > +
>>>
>>>
>>>         Again, i'd rather have a generic way to disable the sysV
>>>         support at compile time...
>>>
>>>
>>>
>>>         Ok so overall, I think most generators should stay in and
>>>         only one or two should be made optional...
>>>         Sorry for the negative feedback, but I don't like adding
>>>         complex compilation options that are not supported
>>>         upstream, especially when all generators together wait 272k
>>>         on my debian
>>         Until we don't decide about the installation machine-id file
>>         that patch doesn't make any sense due to the impossibility to
>>         run those generators at all.
>>
>>         Best
>>         Bartek
>>>
>>>         The few that could legitimately be made optional are easy
>>>         enough to remove in a post-image that I'm not sure
>>>         it's worth the trouble
>>>
>>>         i'd?be ok for a patch doing that, though, but only for the
>>>         few ones that are worth it...
>>>
>>>         Cheers
>>>         Jeremy
>>>
>>>         -- 
>>>         SMILE <http://www.smile.eu/>
>>>
>>>         20 rue des Jardins
>>>         92600 Asni?res-sur-Seine
>>>
>>>         	
>>>         *J?r?my ROSEN*
>>>         Architecte technique
>>>
>>>         email jeremy.rosen at smile.fr <mailto:jeremy.rosen@smile.fr>
>>>         phone +33 6 88 25 87 42
>>>         url http://www.smile.eu <http://www.smile.eu/>
>>>
>>>         Twitter <https://twitter.com/GroupeSmile> Facebook
>>>         <https://www.facebook.com/smileopensource> LinkedIn
>>>         <https://www.linkedin.com/company/smile> Github
>>>         <https://github.com/Smile-SA>
>>>
>>>
>>>         D?couvrez l?univers Smile, rendez-vous sur smile.eu
>>>         <https://www.smile.eu/fr/publications/livres-blancs/yocto?utm_source=signature&utm_medium=email&utm_campaign=signature>
>>
>>
>>
>>     -- 
>>     SMILE <http://www.smile.eu/>
>>
>>     20 rue des Jardins
>>     92600 Asni?res-sur-Seine
>>
>>     	
>>     *J?r?my ROSEN*
>>     Architecte technique
>>
>>     email jeremy.rosen at smile.fr <mailto:jeremy.rosen@smile.fr>
>>     phone? +33 6 88 25 87 42
>>     url http://www.smile.eu <http://www.smile.eu/>
>>
>>     Twitter <https://twitter.com/GroupeSmile> Facebook
>>     <https://www.facebook.com/smileopensource> LinkedIn
>>     <https://www.linkedin.com/company/smile> Github
>>     <https://github.com/Smile-SA>
>>
>>
>>     D?couvrez l?univers Smile, rendez-vous sur smile.eu
>>     <https://www.smile.eu/fr/publications/livres-blancs/yocto?utm_source=signature&utm_medium=email&utm_campaign=signature>
>>
>>     _______________________________________________
>>     buildroot mailing list
>>     buildroot at busybox.net  <mailto:buildroot@busybox.net>
>>     http://lists.busybox.net/mailman/listinfo/buildroot
>
>
>
> -- 
> SMILE <http://www.smile.eu/>
>
> 20 rue des Jardins
> 92600 Asni?res-sur-Seine
>
> 	
> *J?r?my ROSEN*
> Architecte technique
>
> email jeremy.rosen at smile.fr <mailto:jeremy.rosen@smile.fr>
> phone? +33 6 88 25 87 42
> url http://www.smile.eu <http://www.smile.eu/>
>
> Twitter <https://twitter.com/GroupeSmile> Facebook 
> <https://www.facebook.com/smileopensource> LinkedIn 
> <https://www.linkedin.com/company/smile> Github 
> <https://github.com/Smile-SA>
>
>
> D?couvrez l?univers Smile, rendez-vous sur smile.eu 
> <https://www.smile.eu/fr/publications/livres-blancs/yocto?utm_source=signature&utm_medium=email&utm_campaign=signature>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20200203/b959925e/attachment.html>

[Buildroot] [PATCH 1/2] package/systemd: set machine id file instalation as optional choice

[Arnout Vandecappelle]

 Hi Bartosz,

On 17/11/2019 12:33, Bartosz Bilas wrote:
> In case of e.g writable systems there is no neccesity to have
                 writeable                    necessity

> pre-installed empty machine-id file on target because systemd
> generates that automatically during system boot.
> Also in case of having empty machine-id file we are not able
> to use a service with ConditionFirstBoot because systemd recognizes
> machine-id file in system therefore we can't detect new system instance boots up.
> Set this option as enable by default to keep compatibility with old builds.

 Nice that you take a look at this! I'm immediately going to follow it up with
more feature requests though :-)

- If there is a writeable persistent partition, but /etc is not writeable, can
we create a symlink and will systemd still create it correctly at first boot?

- Maybe if BR2_TARGET_GENERIC_REMOUNT_ROOTFS_RW is set, we should default it or
even force it to no.


 Regards,
 Arnout

> 
> Signed-off-by: Bartosz Bilas <b.bilas@grinn-global.com>
> ---
>  package/systemd/Config.in  | 13 +++++++++++++
>  package/systemd/systemd.mk |  2 ++
>  2 files changed, 15 insertions(+)
> 
> diff --git a/package/systemd/Config.in b/package/systemd/Config.in
> index aef39abe27..fadc1a32c8 100644
> --- a/package/systemd/Config.in
> +++ b/package/systemd/Config.in
> @@ -112,6 +112,19 @@ config BR2_PACKAGE_SYSTEMD_BOOT_EFI_ARCH
>  	default "x64"   if BR2_x86_64
>  	depends on BR2_PACKAGE_SYSTEMD_BOOT
>  
> +config BR2_PACKAGE_SYSTEMD_MACHINEID_FILE
> +	bool "Install empty machine id file"
> +	default y
> +	help
> +	  The /etc/machine-id file contains the unique machine ID
> +	  of the local system that is set during installation or
> +	  boot. The machine ID is a single newline-terminated,
> +	  hexadecimal, 32-character, lowercase ID. When decoded from
> +	  hexadecimal, this corresponds to a 16-byte/128-bit value.
> +	  This ID may not be all zeros.
> +
> +	  https://www.freedesktop.org/software/systemd/man/machine-id.html
> +
>  config BR2_PACKAGE_SYSTEMD_JOURNAL_GATEWAY
>  	bool "HTTP server for journal events"
>  	select BR2_PACKAGE_LIBMICROHTTPD
> diff --git a/package/systemd/systemd.mk b/package/systemd/systemd.mk
> index 92490eb86b..fc348fe120 100644
> --- a/package/systemd/systemd.mk
> +++ b/package/systemd/systemd.mk
> @@ -461,9 +461,11 @@ define SYSTEMD_INSTALL_INIT_HOOK
>  		$(TARGET_DIR)/etc/systemd/system/multi-user.target.wants/remote-fs.target
>  endef
>  
> +ifeq ($(BR2_PACKAGE_SYSTEMD_MACHINEID_FILE),y)
>  define SYSTEMD_INSTALL_MACHINEID_HOOK
>  	touch $(TARGET_DIR)/etc/machine-id
>  endef
> +endif
>  
>  SYSTEMD_POST_INSTALL_TARGET_HOOKS += \
>  	SYSTEMD_INSTALL_TARGET_CRYPTSETUP \
> 

[Buildroot] [PATCH 1/2] package/systemd: set machine id file instalation as optional choice

[Jérémy ROSEN]

hmmm, I'm kinda torn on that one..

The only difference I see betweed no machine-id and an empty machine-id is
systemd-firstboot and ConditionFirstBoot

if the file is empty or missing and systemd can write to it, systemd will
set it up (not sure what happens for Arnout's symlink, that's worth testing)
however, if the file exists but is empty we will skip systemd-firstboot

for context, systemd-firstboot does the following:
* set (unconditionnaly) a machine-id
* sets the locale (LANG= LC_MESSGES)
* sets the hostname
* sets the timezone
* sets the root password

systemd-firstboot can use values from its command line, but when launched
on the target, the point is usually to prompt the user for answers.
(as a side note, we can call it with --root=$DESTDIR once we have
host-systemd)

So I would tend to consider systemd-firstboot as "an uncommon case" because
prompting user on first boot is not something we see often in the embedded
space

The good news is: we already know when systemd-firstboot is used because
it's a config option of the systemd package.

ConditionFirstBoot is a bit more useful for us.. it allows to easily run a
service only at first boot (or skip it on first boot)

we also have a big clue if the system is meant to be read-only via the
"remount RW" option

So, putting it all together
* if we use systemd-firstboot, we don't want a machine-id
* if we have a read-only rootfs, we want an empty machine-id
* in other cases, we can deal with both, but it's better to have no
machine-id
* I don't think that the concept of first boot makes any sense with a
read-only rootfs...

Could something like that be enough ? can we trust "remount RW" ?
maybe "remount RW" should be renamed "create a RW filesystem" and enable
various tweaks related to RO vs RW

my two cents...


Le dim. 17 nov. 2019 ? 14:39, Arnout Vandecappelle <arnout@mind.be> a
?crit :

>  Hi Bartosz,
>
> On 17/11/2019 12:33, Bartosz Bilas wrote:
> > In case of e.g writable systems there is no neccesity to have
>                  writeable                    necessity
>
> > pre-installed empty machine-id file on target because systemd
> > generates that automatically during system boot.
> > Also in case of having empty machine-id file we are not able
> > to use a service with ConditionFirstBoot because systemd recognizes
> > machine-id file in system therefore we can't detect new system instance
> boots up.
> > Set this option as enable by default to keep compatibility with old
> builds.
>
>  Nice that you take a look at this! I'm immediately going to follow it up
> with
> more feature requests though :-)
>
> - If there is a writeable persistent partition, but /etc is not writeable,
> can
> we create a symlink and will systemd still create it correctly at first
> boot?
>
> - Maybe if BR2_TARGET_GENERIC_REMOUNT_ROOTFS_RW is set, we should default
> it or
> even force it to no.
>
>
>  Regards,
>  Arnout
>
> >
> > Signed-off-by: Bartosz Bilas <b.bilas@grinn-global.com>
> > ---
> >  package/systemd/Config.in  | 13 +++++++++++++
> >  package/systemd/systemd.mk |  2 ++
> >  2 files changed, 15 insertions(+)
> >
> > diff --git a/package/systemd/Config.in b/package/systemd/Config.in
> > index aef39abe27..fadc1a32c8 100644
> > --- a/package/systemd/Config.in
> > +++ b/package/systemd/Config.in
> > @@ -112,6 +112,19 @@ config BR2_PACKAGE_SYSTEMD_BOOT_EFI_ARCH
> >       default "x64"   if BR2_x86_64
> >       depends on BR2_PACKAGE_SYSTEMD_BOOT
> >
> > +config BR2_PACKAGE_SYSTEMD_MACHINEID_FILE
> > +     bool "Install empty machine id file"
> > +     default y
> > +     help
> > +       The /etc/machine-id file contains the unique machine ID
> > +       of the local system that is set during installation or
> > +       boot. The machine ID is a single newline-terminated,
> > +       hexadecimal, 32-character, lowercase ID. When decoded from
> > +       hexadecimal, this corresponds to a 16-byte/128-bit value.
> > +       This ID may not be all zeros.
> > +
> > +       https://www.freedesktop.org/software/systemd/man/machine-id.html
> > +
> >  config BR2_PACKAGE_SYSTEMD_JOURNAL_GATEWAY
> >       bool "HTTP server for journal events"
> >       select BR2_PACKAGE_LIBMICROHTTPD
> > diff --git a/package/systemd/systemd.mk b/package/systemd/systemd.mk
> > index 92490eb86b..fc348fe120 100644
> > --- a/package/systemd/systemd.mk
> > +++ b/package/systemd/systemd.mk
> > @@ -461,9 +461,11 @@ define SYSTEMD_INSTALL_INIT_HOOK
> >
>  $(TARGET_DIR)/etc/systemd/system/multi-user.target.wants/remote-fs.target
> >  endef
> >
> > +ifeq ($(BR2_PACKAGE_SYSTEMD_MACHINEID_FILE),y)
> >  define SYSTEMD_INSTALL_MACHINEID_HOOK
> >       touch $(TARGET_DIR)/etc/machine-id
> >  endef
> > +endif
> >
> >  SYSTEMD_POST_INSTALL_TARGET_HOOKS += \
> >       SYSTEMD_INSTALL_TARGET_CRYPTSETUP \
> >
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
>


-- 
[image: SMILE]  <http://www.smile.eu/>

20 rue des Jardins
92600 Asni?res-sur-Seine
*J?r?my ROSEN*
Architecte technique

[image: email] jeremy.rosen at smile.fr
[image: phone]  +33 6 88 25 87 42
[image: url] http://www.smile.eu

[image: Twitter] <https://twitter.com/GroupeSmile> [image: Facebook]
<https://www.facebook.com/smileopensource> [image: LinkedIn]
<https://www.linkedin.com/company/smile> [image: Github]
<https://github.com/Smile-SA>

[image: D?couvrez l?univers Smile, rendez-vous sur smile.eu]
<https://www.smile.eu/fr/publications/livres-blancs/yocto?utm_source=signature&utm_medium=email&utm_campaign=signature>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20191117/45cea66a/attachment.html>

[Buildroot] [PATCH 1/2] package/systemd: set machine id file instalation as optional choice

[Arnout Vandecappelle]

On 17/11/2019 15:19, J?r?my ROSEN wrote:
> hmmm, I'm kinda torn on that one..
> 
> The only difference I see betweed no machine-id and an empty machine-id is
> systemd-firstboot and ConditionFirstBoot

 That's exactly the point I think.

 I assumed, however, that ConditionFirstBoot was evaluated by systemd-firstboot,
but that's not the case then?


> if the file is empty or missing and systemd can write to it, systemd will set it
> up (not sure what happens for Arnout's symlink, that's worth testing)
> however, if the file exists but is empty we will skip systemd-firstboot
> 
> for context, systemd-firstboot does the following:
> * set (unconditionnaly) a machine-id

 Are you saying that if systemd-firstboot it not enabled, no machine-id will be
generated?

> * sets the locale (LANG= LC_MESSGES)
> * sets the hostname
> * sets the timezone
> * sets the root password
> 
> systemd-firstboot can use values from its command line, but when launched on the
> target, the point is usually to prompt the user for answers.
> (as a side note, we can call it with --root=$DESTDIR once we have host-systemd)
> 
> So I would tend to consider systemd-firstboot as "an uncommon case" because
> prompting?user on first boot is not something we see often in the embedded space
> 
> The good news is: we already know when systemd-firstboot is used because it's a
> config option of the systemd package.
> 
> ConditionFirstBoot is a bit more useful for us.. it allows to easily run a
> service only at first boot (or skip it on first boot)

 Well, here are a few things you'd typically want to generate on first boot:

- machine id;
- ssh keys;
- various certificates;
- maybe a hashed root password based on a serial number of MAC address;
- maybe a random or hashed hostname;
- register on the phone-home server;
- resize the data partition based on actual size of the eMMC.

 None of them interactively, of course.

 So apparently systemd-firstboot can only do the first one. That's indeed not
very useful.


> we also have a big clue if the system is meant to be read-only via the "remount
> RW" option

 Yeah, but it's just a clue. You can have a writeable machine ID without a
remount RW option in a number of situations:

- custom skeleton
- fstab is overwritten by fs-overlay
- /etc is (bind)-mounted to a writeable partition
- /etc/machine-id is symlinked into a writeable partition
- root is squashfs (so it's not writeable even if RW is on)


> So, putting it all together
> * if we use systemd-firstboot, we don't want a machine-id

 ... at least, not an empty one :-)

> * if we have a read-only rootfs, we want an empty machine-id
> * in other cases, we can deal with both, but it's better to have no machine-id
> * I don't think that the concept of first boot makes any sense with a read-only
> rootfs...

 With readonly *rootfs* it certainly does, but not without any persistent
storage at all.

> 
> Could something like that be enough ? can we trust "remount RW" ?
> maybe "remount RW" should be renamed "create a RW filesystem" and enable various
> tweaks related to RO vs RW

 As written above: no.


 The problem is: we're not a distro. We leave too much freedom for the user to
integrate things in various ways to be able to make assumptions about what is
the right way to do things. So, the only thing we can do is to give a decent
out-of-the-box experience, and let the user figure out how to tweak things -
possibly adding a config option for a common situation that is easily handled in
a generic way. The other thing we can do is to provide documentation about the
proper way to integrate things in different scenarios.

 I'm starting to agree that this option is maybe not that great.

 Actually, come to think of it, maybe it's better to never create the machine-id
at all. What is the effect (with a readonly rootfs) if machine-id doesn't exist?
Does it block booting, does the boot take a little longer, or do we boot with a
different machine-id all the time? And in the latter case, is there a real
problem with that?

 Regards,
 Arnout

> 
> my two cents...
> 
> 
> Le?dim. 17 nov. 2019 ??14:39, Arnout Vandecappelle <arnout@mind.be
> <mailto:arnout@mind.be>> a ?crit?:
> 
>     ?Hi Bartosz,
> 
>     On 17/11/2019 12:33, Bartosz Bilas wrote:
>     > In case of e.g writable systems there is no neccesity to have
>     ? ? ? ? ? ? ? ? ?writeable? ? ? ? ? ? ? ? ? ? necessity
> 
>     > pre-installed empty machine-id file on target because systemd
>     > generates that automatically during system boot.
>     > Also in case of having empty machine-id file we are not able
>     > to use a service with ConditionFirstBoot because systemd recognizes
>     > machine-id file in system therefore we can't detect new system instance
>     boots up.
>     > Set this option as enable by default to keep compatibility with old builds.
> 
>     ?Nice that you take a look at this! I'm immediately going to follow it up with
>     more feature requests though :-)
> 
>     - If there is a writeable persistent partition, but /etc is not writeable, can
>     we create a symlink and will systemd still create it correctly at first boot?
> 
>     - Maybe if BR2_TARGET_GENERIC_REMOUNT_ROOTFS_RW is set, we should default it or
>     even force it to no.
> 
> 
>     ?Regards,
>     ?Arnout
> 
>     >
>     > Signed-off-by: Bartosz Bilas <b.bilas@grinn-global.com
>     <mailto:b.bilas@grinn-global.com>>
>     > ---
>     >? package/systemd/Config.in? | 13 +++++++++++++
>     >? package/systemd/systemd.mk <http://systemd.mk> |? 2 ++
>     >? 2 files changed, 15 insertions(+)
>     >
>     > diff --git a/package/systemd/Config.in b/package/systemd/Config.in
>     > index aef39abe27..fadc1a32c8 100644
>     > --- a/package/systemd/Config.in
>     > +++ b/package/systemd/Config.in
>     > @@ -112,6 +112,19 @@ config BR2_PACKAGE_SYSTEMD_BOOT_EFI_ARCH
>     >? ? ? ?default "x64"? ?if BR2_x86_64
>     >? ? ? ?depends on BR2_PACKAGE_SYSTEMD_BOOT
>     >?
>     > +config BR2_PACKAGE_SYSTEMD_MACHINEID_FILE
>     > +? ? ?bool "Install empty machine id file"
>     > +? ? ?default y
>     > +? ? ?help
>     > +? ? ? ?The /etc/machine-id file contains the unique machine ID
>     > +? ? ? ?of the local system that is set during installation or
>     > +? ? ? ?boot. The machine ID is a single newline-terminated,
>     > +? ? ? ?hexadecimal, 32-character, lowercase ID. When decoded from
>     > +? ? ? ?hexadecimal, this corresponds to a 16-byte/128-bit value.
>     > +? ? ? ?This ID may not be all zeros.
>     > +
>     > +? ? ? ?https://www.freedesktop.org/software/systemd/man/machine-id.html
>     > +
>     >? config BR2_PACKAGE_SYSTEMD_JOURNAL_GATEWAY
>     >? ? ? ?bool "HTTP server for journal events"
>     >? ? ? ?select BR2_PACKAGE_LIBMICROHTTPD
>     > diff --git a/package/systemd/systemd.mk <http://systemd.mk>
>     b/package/systemd/systemd.mk <http://systemd.mk>
>     > index 92490eb86b..fc348fe120 100644
>     > --- a/package/systemd/systemd.mk <http://systemd.mk>
>     > +++ b/package/systemd/systemd.mk <http://systemd.mk>
>     > @@ -461,9 +461,11 @@ define SYSTEMD_INSTALL_INIT_HOOK
>     >? ? ? ? ? ? ?
>     ?$(TARGET_DIR)/etc/systemd/system/multi-user.target.wants/remote-fs.target
>     >? endef
>     >?
>     > +ifeq ($(BR2_PACKAGE_SYSTEMD_MACHINEID_FILE),y)
>     >? define SYSTEMD_INSTALL_MACHINEID_HOOK
>     >? ? ? ?touch $(TARGET_DIR)/etc/machine-id
>     >? endef
>     > +endif
>     >?
>     >? SYSTEMD_POST_INSTALL_TARGET_HOOKS += \
>     >? ? ? ?SYSTEMD_INSTALL_TARGET_CRYPTSETUP \
>     >
>     _______________________________________________
>     buildroot mailing list
>     buildroot at busybox.net <mailto:buildroot@busybox.net>
>     http://lists.busybox.net/mailman/listinfo/buildroot
> 
> 
> 
> -- 
> SMILE? <http://www.smile.eu/>
> 
> 20 rue des Jardins
> 92600 Asni?res-sur-Seine
> 
> 	
> *J?r?my ROSEN*
> Architecte technique
> 
> email?jeremy.rosen at smile.fr <mailto:jeremy.rosen@smile.fr>?
> phone? +33 6 88 25 87 42?
> url?http://www.smile.eu <http://www.smile.eu/>
> 
> Twitter <https://twitter.com/GroupeSmile>?Facebook
> <https://www.facebook.com/smileopensource>?LinkedIn
> <https://www.linkedin.com/company/smile>?Github <https://github.com/Smile-SA>
> 
> 
> D?couvrez l?univers Smile, rendez-vous sur smile.eu
> <https://www.smile.eu/fr/publications/livres-blancs/yocto?utm_source=signature&utm_medium=email&utm_campaign=signature>

[Buildroot] [PATCH 1/2] package/systemd: set machine id file instalation as optional choice

[Jérémy ROSEN]

Argh, each time I simplify a bit, it comes back to bite me :)

Le dim. 17 nov. 2019 ? 17:00, Arnout Vandecappelle <arnout@mind.be> a
?crit :

>
>
> On 17/11/2019 15:19, J?r?my ROSEN wrote:
> > hmmm, I'm kinda torn on that one..
> >
> > The only difference I see betweed no machine-id and an empty machine-id
> is
> > systemd-firstboot and ConditionFirstBoot
>
>  That's exactly the point I think.
>
>  I assumed, however, that ConditionFirstBoot was evaluated by
> systemd-firstboot,
> but that's not the case then?
>
>
>
no, all Condition* are handled by PID1.
systemd-firstboot.service itself relies on ConditionFirstBoot to decide if
the binary needs to be started


> > if the file is empty or missing and systemd can write to it, systemd
> will set it
> > up (not sure what happens for Arnout's symlink, that's worth testing)
> > however, if the file exists but is empty we will skip systemd-firstboot
> >
> > for context, systemd-firstboot does the following:
> > * set (unconditionnaly) a machine-id
>
>  Are you saying that if systemd-firstboot it not enabled, no machine-id
> will be
> generated?
>
> no, it's a bit more complex, and i'd need to check the details.

my understanding is that systemd-firstboot will always override the
machine-id whereas on a normal boot,
the machine-id will be used if available and generated/written if not



> > * sets the locale (LANG= LC_MESSGES)
> > * sets the hostname
> > * sets the timezone
> > * sets the root password
> >
> > systemd-firstboot can use values from its command line, but when
> launched on the
> > target, the point is usually to prompt the user for answers.
> > (as a side note, we can call it with --root=$DESTDIR once we have
> host-systemd)
> >
> > So I would tend to consider systemd-firstboot as "an uncommon case"
> because
> > prompting user on first boot is not something we see often in the
> embedded space
> >
> > The good news is: we already know when systemd-firstboot is used because
> it's a
> > config option of the systemd package.
> >
> > ConditionFirstBoot is a bit more useful for us.. it allows to easily run
> a
> > service only at first boot (or skip it on first boot)
>
>  Well, here are a few things you'd typically want to generate on first
> boot:
>
> - machine id;
> - ssh keys;
> - various certificates;
> - maybe a hashed root password based on a serial number of MAC address;
> - maybe a random or hashed hostname;
> - register on the phone-home server;
> - resize the data partition based on actual size of the eMMC.
>
>  None of them interactively, of course.
>
>  So apparently systemd-firstboot can only do the first one. That's indeed
> not
> very useful.
>
>
> > we also have a big clue if the system is meant to be read-only via the
> "remount
> > RW" option
>
>  Yeah, but it's just a clue. You can have a writeable machine ID without a
> remount RW option in a number of situations:
>
> - custom skeleton
> - fstab is overwritten by fs-overlay
> - /etc is (bind)-mounted to a writeable partition
> - /etc/machine-id is symlinked into a writeable partition
> - root is squashfs (so it's not writeable even if RW is on)
>
>
> > So, putting it all together
> > * if we use systemd-firstboot, we don't want a machine-id
>
>  ... at least, not an empty one :-)
>
> > * if we have a read-only rootfs, we want an empty machine-id
> > * in other cases, we can deal with both, but it's better to have no
> machine-id
> > * I don't think that the concept of first boot makes any sense with a
> read-only
> > rootfs...
>
>  With readonly *rootfs* it certainly does, but not without any persistent
> storage at all.
>
> >
> > Could something like that be enough ? can we trust "remount RW" ?
> > maybe "remount RW" should be renamed "create a RW filesystem" and enable
> various
> > tweaks related to RO vs RW
>
>  As written above: no.
>
>
>  The problem is: we're not a distro. We leave too much freedom for the
> user to
> integrate things in various ways to be able to make assumptions about what
> is
> the right way to do things. So, the only thing we can do is to give a
> decent
> out-of-the-box experience, and let the user figure out how to tweak things
> -
> possibly adding a config option for a common situation that is easily
> handled in
> a generic way. The other thing we can do is to provide documentation about
> the
> proper way to integrate things in different scenarios.
>
>  I'm starting to agree that this option is maybe not that great.
>
>  Actually, come to think of it, maybe it's better to never create the
> machine-id
> at all. What is the effect (with a readonly rootfs) if machine-id doesn't
> exist?
> Does it block booting, does the boot take a little longer, or do we boot
> with a
> different machine-id all the time? And in the latter case, is there a real
> problem with that?
>

on a RO filesystem
* if /etc/machine-id exists and contains a machine-id, systemd will use it
* if it's an empty file, systemd will bind-mount a file with a machine-id
over the file
* if the file does not exist, systemd can't bind mount over the file...
systemd itself should be fine, but other services might not, it's hard to
tell

So the recommended way for a read-only rootfs is to have that empty file,
which is why this is what currently have.
it works both for RW and RO filesystems..


A longer-term solution would be to add a patch upstream to allow to specify
in a systemd configuration file what is
the file to check for first boot instead of /etc/machine-id.

I can look into that, but for the short term, i'd rather break
ConditionFirstBoot than read-only rootfs

so... not sure what to advise at that point. that choice is something a bit
too specialized for a config option
especially if we plan to drop it in the future

so not sure where to go...


>
>  Regards,
>  Arnout
>
> >
> > my two cents...
> >
> >
> > Le dim. 17 nov. 2019 ? 14:39, Arnout Vandecappelle <arnout@mind.be
> > <mailto:arnout@mind.be>> a ?crit :
> >
> >      Hi Bartosz,
> >
> >     On 17/11/2019 12:33, Bartosz Bilas wrote:
> >     > In case of e.g writable systems there is no neccesity to have
> >                      writeable                    necessity
> >
> >     > pre-installed empty machine-id file on target because systemd
> >     > generates that automatically during system boot.
> >     > Also in case of having empty machine-id file we are not able
> >     > to use a service with ConditionFirstBoot because systemd recognizes
> >     > machine-id file in system therefore we can't detect new system
> instance
> >     boots up.
> >     > Set this option as enable by default to keep compatibility with
> old builds.
> >
> >      Nice that you take a look at this! I'm immediately going to follow
> it up with
> >     more feature requests though :-)
> >
> >     - If there is a writeable persistent partition, but /etc is not
> writeable, can
> >     we create a symlink and will systemd still create it correctly at
> first boot?
> >
> >     - Maybe if BR2_TARGET_GENERIC_REMOUNT_ROOTFS_RW is set, we should
> default it or
> >     even force it to no.
> >
> >
> >      Regards,
> >      Arnout
> >
> >     >
> >     > Signed-off-by: Bartosz Bilas <b.bilas@grinn-global.com
> >     <mailto:b.bilas@grinn-global.com>>
> >     > ---
> >     >  package/systemd/Config.in  | 13 +++++++++++++
> >     >  package/systemd/systemd.mk <http://systemd.mk> |  2 ++
> >     >  2 files changed, 15 insertions(+)
> >     >
> >     > diff --git a/package/systemd/Config.in b/package/systemd/Config.in
> >     > index aef39abe27..fadc1a32c8 100644
> >     > --- a/package/systemd/Config.in
> >     > +++ b/package/systemd/Config.in
> >     > @@ -112,6 +112,19 @@ config BR2_PACKAGE_SYSTEMD_BOOT_EFI_ARCH
> >     >       default "x64"   if BR2_x86_64
> >     >       depends on BR2_PACKAGE_SYSTEMD_BOOT
> >     >
> >     > +config BR2_PACKAGE_SYSTEMD_MACHINEID_FILE
> >     > +     bool "Install empty machine id file"
> >     > +     default y
> >     > +     help
> >     > +       The /etc/machine-id file contains the unique machine ID
> >     > +       of the local system that is set during installation or
> >     > +       boot. The machine ID is a single newline-terminated,
> >     > +       hexadecimal, 32-character, lowercase ID. When decoded from
> >     > +       hexadecimal, this corresponds to a 16-byte/128-bit value.
> >     > +       This ID may not be all zeros.
> >     > +
> >     > +
> https://www.freedesktop.org/software/systemd/man/machine-id.html
> >     > +
> >     >  config BR2_PACKAGE_SYSTEMD_JOURNAL_GATEWAY
> >     >       bool "HTTP server for journal events"
> >     >       select BR2_PACKAGE_LIBMICROHTTPD
> >     > diff --git a/package/systemd/systemd.mk <http://systemd.mk>
> >     b/package/systemd/systemd.mk <http://systemd.mk>
> >     > index 92490eb86b..fc348fe120 100644
> >     > --- a/package/systemd/systemd.mk <http://systemd.mk>
> >     > +++ b/package/systemd/systemd.mk <http://systemd.mk>
> >     > @@ -461,9 +461,11 @@ define SYSTEMD_INSTALL_INIT_HOOK
> >     >
> >
>   $(TARGET_DIR)/etc/systemd/system/multi-user.target.wants/remote-fs.target
> >     >  endef
> >     >
> >     > +ifeq ($(BR2_PACKAGE_SYSTEMD_MACHINEID_FILE),y)
> >     >  define SYSTEMD_INSTALL_MACHINEID_HOOK
> >     >       touch $(TARGET_DIR)/etc/machine-id
> >     >  endef
> >     > +endif
> >     >
> >     >  SYSTEMD_POST_INSTALL_TARGET_HOOKS += \
> >     >       SYSTEMD_INSTALL_TARGET_CRYPTSETUP \
> >     >
> >     _______________________________________________
> >     buildroot mailing list
> >     buildroot at busybox.net <mailto:buildroot@busybox.net>
> >     http://lists.busybox.net/mailman/listinfo/buildroot
> >
> >
> >
> > --
> > SMILE  <http://www.smile.eu/>
> >
> > 20 rue des Jardins
> > 92600 Asni?res-sur-Seine
> >
> >
> > *J?r?my ROSEN*
> > Architecte technique
> >
> > email jeremy.rosen at smile.fr <mailto:jeremy.rosen@smile.fr>
> > phone  +33 6 88 25 87 42
> > url http://www.smile.eu <http://www.smile.eu/>
> >
> > Twitter <https://twitter.com/GroupeSmile> Facebook
> > <https://www.facebook.com/smileopensource> LinkedIn
> > <https://www.linkedin.com/company/smile> Github <
> https://github.com/Smile-SA>
> >
> >
> > D?couvrez l?univers Smile, rendez-vous sur smile.eu
> > <
> https://www.smile.eu/fr/publications/livres-blancs/yocto?utm_source=signature&utm_medium=email&utm_campaign=signature
> >
>


-- 
[image: SMILE]  <http://www.smile.eu/>

20 rue des Jardins
92600 Asni?res-sur-Seine
*J?r?my ROSEN*
Architecte technique

[image: email] jeremy.rosen at smile.fr
[image: phone]  +33 6 88 25 87 42
[image: url] http://www.smile.eu

[image: Twitter] <https://twitter.com/GroupeSmile> [image: Facebook]
<https://www.facebook.com/smileopensource> [image: LinkedIn]
<https://www.linkedin.com/company/smile> [image: Github]
<https://github.com/Smile-SA>

[image: D?couvrez l?univers Smile, rendez-vous sur smile.eu]
<https://www.smile.eu/fr/publications/livres-blancs/yocto?utm_source=signature&utm_medium=email&utm_campaign=signature>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20191117/ac2ae46a/attachment.html>

[Buildroot] [PATCH 1/2] package/systemd: set machine id file instalation as optional choice

[Arnout Vandecappelle]

 Hi Je?re?my,

 Thanks for your input!

On 17/11/2019 17:14, J?r?my ROSEN wrote:
> Argh, each time I simplify a bit, it comes back to bite me :)
> 
> Le?dim. 17 nov. 2019 ??17:00, Arnout Vandecappelle <arnout@mind.be
> <mailto:arnout@mind.be>> a ?crit?:
> 
> 
> 
>     On 17/11/2019 15:19, J?r?my ROSEN wrote:
>     > hmmm, I'm kinda torn on that one..
>     >
>     > The only difference I see betweed no machine-id and an empty machine-id is
>     > systemd-firstboot and ConditionFirstBoot
> 
>     ?That's exactly the point I think.
> 
>     ?I assumed, however, that ConditionFirstBoot was evaluated by systemd-firstboot,
>     but that's not the case then?
> 
> 
> 
> no, all Condition* are handled by PID1.?
> systemd-firstboot.service itself relies on ConditionFirstBoot to decide if the
> binary needs to be started

 Of course, that makes a lot of sense if you think about it. I should do more of
that :-)


>     > if the file is empty or missing and systemd can write to it, systemd will
>     set it
>     > up (not sure what happens for Arnout's symlink, that's worth testing)
>     > however, if the file exists but is empty we will skip systemd-firstboot
>     >
>     > for context, systemd-firstboot does the following:
>     > * set (unconditionnaly) a machine-id
> 
>     ?Are you saying that if systemd-firstboot it not enabled, no machine-id will be
>     generated?
> 
> no, it's a bit more complex, and i'd need to check the details.
> 
> my understanding is that systemd-firstboot will always override the machine-id
> whereas on a normal boot,?
> the machine-id will be used if available and generated/written if not

 That also makes sense.

[snip]
>     ?Actually, come to think of it, maybe it's better to never create the machine-id
>     at all. What is the effect (with a readonly rootfs) if machine-id doesn't exist?
>     Does it block booting, does the boot take a little longer, or do we boot with a
>     different machine-id all the time? And in the latter case, is there a real
>     problem with that?
> 
> 
> on a RO filesystem
> * if /etc/machine-id exists and contains a machine-id, systemd will use it
> * if it's an empty file, systemd will bind-mount a file with a machine-id over
> the file

 Where I suppose the machine-id is regenerated on every boot.

> * if the file does not exist, systemd can't bind mount over the file... systemd
> itself should be fine, but other services might not, it's hard to tell

 That's not good...

> 
> So the recommended?way for a read-only rootfs is to have that empty file, which
> is why this is what currently have.
> it works both for RW and RO filesystems..

 Another option would be to make it a symlink to a file in tmpfs, but that
doesn't help because the net effect is the same: machine-id is regenerated on
every boot :-(


> A longer-term solution would be to add a patch upstream to allow to specify in a
> systemd configuration file what is?
> the file to check for first boot instead of /etc/machine-id.

 No, that makes very little sense. If a system has any kind of persistency, then
machine-id should definitely be one of the things that is persisted, so it's a
perfect flag for firstboot.

 Upstream's vision is that /etc should be persistent and empty on factory reset
[1]. But we're far away from having an empty /etc in Buildroot...



> I can look into that, but for the short term, i'd?rather break
> ConditionFirstBoot than read-only rootfs
> 
> so... not sure what to advise at that point. that choice is something a bit too
> specialized for a config option
> especially if we plan to drop it in the future
> 
> so not sure where to go...

 As is often the case: it looks to me that the status quo is the best we can do :-)

 Regards,
 Arnout

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

[snip]

[Buildroot] [PATCH 1/2] package/systemd: set machine id file instalation as optional choice

[Jérémy ROSEN]

>
>
> [snip]
> >      Actually, come to think of it, maybe it's better to never create
> the machine-id
> >     at all. What is the effect (with a readonly rootfs) if machine-id
> doesn't exist?
> >     Does it block booting, does the boot take a little longer, or do we
> boot with a
> >     different machine-id all the time? And in the latter case, is there
> a real
> >     problem with that?
> >
> >
> > on a RO filesystem
> > * if /etc/machine-id exists and contains a machine-id, systemd will use
> it
> > * if it's an empty file, systemd will bind-mount a file with a
> machine-id over
> > the file
>
>  Where I suppose the machine-id is regenerated on every boot.
>
> yes, which is fine, that's the intended behaviour


> > * if the file does not exist, systemd can't bind mount over the file...
> systemd
> > itself should be fine, but other services might not, it's hard to tell
>
>  That's not good...
>
I just tested, and systemd logs an error message that it can't boot in that
case.

more precisely, when systemd starts
* either /etc is readwrite
* or it should have a /etc/machine-id
so we need the file, since our rootfs is read-only when systemd starts
* it's just an error message, everything turns out fine once we remount rw
and we save the machine-id only
* sounds like a bug from upstream... read-only rootfs and read-only rootfs
that become RW are supposed to be supported


>
> >
> > So the recommended way for a read-only rootfs is to have that empty
> file, which
> > is why this is what currently have.
> > it works both for RW and RO filesystems..
>
>  Another option would be to make it a symlink to a file in tmpfs, but that
> doesn't help because the net effect is the same: machine-id is regenerated
> on
> every boot :-(
>
>
regenerated every boot is fine, i'm just not sure in what way a symlink to
a tmpfs would be different/better than what systemd currently does

symlink to a r/w partition makes sense, but that would not work for
ConditionFirstBoot


>
> > A longer-term solution would be to add a patch upstream to allow to
> specify in a
> > systemd configuration file what is
> > the file to check for first boot instead of /etc/machine-id.
>
>  No, that makes very little sense. If a system has any kind of
> persistency, then
> machine-id should definitely be one of the things that is persisted, so
> it's a
> perfect flag for firstboot.
>
> no because it makes sense to have it be a symlink to a RW file... in which
case it exists even in first boot..



>  Upstream's vision is that /etc should be persistent and empty on factory
> reset
> [1]. But we're far away from having an empty /etc in Buildroot...
>
> yeah, but I think the assumption empty /etc == first boot is wrong...
in the real world, the assumption is no /etc/machine-id == first boot makes
more sense, but it doesn't work for us.
No... upstream patch is really the way to go (and i'm already working on it
:P )

>
>
> > I can look into that, but for the short term, i'd rather break
> > ConditionFirstBoot than read-only rootfs
> >
> > so... not sure what to advise at that point. that choice is something a
> bit too
> > specialized for a config option
> > especially if we plan to drop it in the future
> >
> > so not sure where to go...
>
>  As is often the case: it looks to me that the status quo is the best we
> can do :-)
>

it could be slightly improved by removing /etc/machine-id when
systemd-firstboot is selected, but I agree...
Until we can change and configure how to detect first-boot, we are kinda
stuck...


>
>  Regards,
>  Arnout
>
> [1] http://0pointer.net/blog/projects/stateless.html
>
> [snip]
>


-- 
[image: SMILE]  <http://www.smile.eu/>

20 rue des Jardins
92600 Asni?res-sur-Seine
*J?r?my ROSEN*
Architecte technique

[image: email] jeremy.rosen at smile.fr
[image: phone]  +33 6 88 25 87 42
[image: url] http://www.smile.eu

[image: Twitter] <https://twitter.com/GroupeSmile> [image: Facebook]
<https://www.facebook.com/smileopensource> [image: LinkedIn]
<https://www.linkedin.com/company/smile> [image: Github]
<https://github.com/Smile-SA>

[image: D?couvrez l?univers Smile, rendez-vous sur smile.eu]
<https://www.smile.eu/fr/publications/livres-blancs/yocto?utm_source=signature&utm_medium=email&utm_campaign=signature>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20191117/07e9350f/attachment.html>

[Buildroot] [PATCH 1/2] package/systemd: set machine id file instalation as optional choice

[Thomas Petazzoni]

Hello,

On Sun, 17 Nov 2019 17:00:05 +0100
Arnout Vandecappelle <arnout@mind.be> wrote:

> > Could something like that be enough ? can we trust "remount RW" ?
> > maybe "remount RW" should be renamed "create a RW filesystem" and enable various
> > tweaks related to RO vs RW  
> 
>  As written above: no.
> 
>  The problem is: we're not a distro.

Agreed.

> We leave too much freedom for the user to
> integrate things in various ways to be able to make assumptions about what is
> the right way to do things. So, the only thing we can do is to give a decent
> out-of-the-box experience, and let the user figure out how to tweak things -
> possibly adding a config option for a common situation that is easily handled in
> a generic way. The other thing we can do is to provide documentation about the
> proper way to integrate things in different scenarios.
> 
>  I'm starting to agree that this option is maybe not that great.

But I would in fact not come to the same conclusion. Having this empty
machine-id file is useless and causes problems when the filesystem is
R/W. So for the sake of supporting the R/O case (for which we create
this empty machine-id file), we make the R/W experience less good.

So I'd say that the right approach is to not do too much integration by
precisely having the option proposed by Bartosz, with many the tweak
that it should default y if rootfs is really, and default disable
otherwise, but while still being an option that the user can tweak,
because as you rightfully explained, the RW/RO remount option is just a
clue, not a definitive answer on whether /etc is writable or not.

To me, having this option matches the Buildroot way: we are not a
distro, we don't enforce how the system should work, so we provide the
appropriate options, while making sure the option has the most sensible
default values.

Generally speaking, Buildroot kind of supports "out of the box" two use
cases:

 (1) The root filesystem is completely read-write.

 (2) The root filesystem is completely read-only, and all files that need
     to be written are stored in tmpfs, and therefore are volatile.

I.e, we do not have any explicit support for what is I guess a much
more common use case than (2):

 (3) The root filesystem is completely read-only, but there is another
     read-write partition somewhere that stores the information that can
     change but needs to be persistent (user configuration, etc.)

Since we don't have explicit support for (3), there is no way we can
properly support machine-id and ConditionFirstBoot in the case of (2),
because there's nowhere we can store /etc/machine-id.

So the best we can do is in the case of (2), default to creating an
empty /etc/machine-id, while giving the possibility for the user
implementing (3) in its own way, to disable the creation of the empty
/etc/machine-id.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] [PATCH 1/2] package/systemd: set machine id file instalation as optional choice

[Jérémy ROSEN]

As a side-note, I am working with upstream to have a better support of (3)
: https://github.com/systemd/systemd/pull/14059

I am a bit cautious about the new config option because it seems too
"advanced" for a config option (for me, it's something that should be set
in a post-image or overlay) but that's open to discussion.

Please wait a little before applying this patch, if that's the way
buildroot wants to go, so my pull-request above is solved and we might
backport it to ease our transition.

Cheers
J?r?my

Le mar. 19 nov. 2019 ? 09:40, Thomas Petazzoni <thomas.petazzoni@bootlin.com>
a ?crit :

> Hello,
>
> On Sun, 17 Nov 2019 17:00:05 +0100
> Arnout Vandecappelle <arnout@mind.be> wrote:
>
> > > Could something like that be enough ? can we trust "remount RW" ?
> > > maybe "remount RW" should be renamed "create a RW filesystem" and
> enable various
> > > tweaks related to RO vs RW
> >
> >  As written above: no.
> >
> >  The problem is: we're not a distro.
>
> Agreed.
>
> > We leave too much freedom for the user to
> > integrate things in various ways to be able to make assumptions about
> what is
> > the right way to do things. So, the only thing we can do is to give a
> decent
> > out-of-the-box experience, and let the user figure out how to tweak
> things -
> > possibly adding a config option for a common situation that is easily
> handled in
> > a generic way. The other thing we can do is to provide documentation
> about the
> > proper way to integrate things in different scenarios.
> >
> >  I'm starting to agree that this option is maybe not that great.
>
> But I would in fact not come to the same conclusion. Having this empty
> machine-id file is useless and causes problems when the filesystem is
> R/W. So for the sake of supporting the R/O case (for which we create
> this empty machine-id file), we make the R/W experience less good.
>
> So I'd say that the right approach is to not do too much integration by
> precisely having the option proposed by Bartosz, with many the tweak
> that it should default y if rootfs is really, and default disable
> otherwise, but while still being an option that the user can tweak,
> because as you rightfully explained, the RW/RO remount option is just a
> clue, not a definitive answer on whether /etc is writable or not.
>
> To me, having this option matches the Buildroot way: we are not a
> distro, we don't enforce how the system should work, so we provide the
> appropriate options, while making sure the option has the most sensible
> default values.
>
> Generally speaking, Buildroot kind of supports "out of the box" two use
> cases:
>
>  (1) The root filesystem is completely read-write.
>
>  (2) The root filesystem is completely read-only, and all files that need
>      to be written are stored in tmpfs, and therefore are volatile.
>
> I.e, we do not have any explicit support for what is I guess a much
> more common use case than (2):
>
>  (3) The root filesystem is completely read-only, but there is another
>      read-write partition somewhere that stores the information that can
>      change but needs to be persistent (user configuration, etc.)
>
> Since we don't have explicit support for (3), there is no way we can
> properly support machine-id and ConditionFirstBoot in the case of (2),
> because there's nowhere we can store /etc/machine-id.
>
> So the best we can do is in the case of (2), default to creating an
> empty /etc/machine-id, while giving the possibility for the user
> implementing (3) in its own way, to disable the creation of the empty
> /etc/machine-id.
>
> Best regards,
>
> Thomas
> --
> Thomas Petazzoni, CTO, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
>


-- 
[image: SMILE]  <http://www.smile.eu/>

20 rue des Jardins
92600 Asni?res-sur-Seine
*J?r?my ROSEN*
Architecte technique

[image: email] jeremy.rosen at smile.fr
[image: phone]  +33 6 88 25 87 42
[image: url] http://www.smile.eu

[image: Twitter] <https://twitter.com/GroupeSmile> [image: Facebook]
<https://www.facebook.com/smileopensource> [image: LinkedIn]
<https://www.linkedin.com/company/smile> [image: Github]
<https://github.com/Smile-SA>

[image: D?couvrez l?univers Smile, rendez-vous sur smile.eu]
<https://www.smile.eu/fr/publications/livres-blancs/yocto?utm_source=signature&utm_medium=email&utm_campaign=signature>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20191119/4d5e4cd1/attachment.html>

[Buildroot] [PATCH 1/2] package/systemd: set machine id file instalation as optional choice

[Bartosz Bilas]

Hello everyone,

let's reject this patch due to possible upstream solution as Jeremy 
mentioned.

Best
Bartek
On 19.11.2019 11:15, J?r?my ROSEN wrote:
> As a side-note, I am working with upstream to have a better support of 
> (3) : https://github.com/systemd/systemd/pull/14059
>
> I am a bit cautious about the new config option because it seems too 
> "advanced" for a config option (for me, it's something that should be set
> in a post-image or overlay) but that's open to discussion.
>
> Please wait a little before applying this patch, if that's the way 
> buildroot wants to go, so my pull-request above is solved and we might
> backport it to ease our transition.
>
> Cheers
> J?r?my
>
> Le?mar. 19 nov. 2019 ??09:40, Thomas Petazzoni 
> <thomas.petazzoni at bootlin.com <mailto:thomas.petazzoni@bootlin.com>> a 
> ?crit?:
>
>     Hello,
>
>     On Sun, 17 Nov 2019 17:00:05 +0100
>     Arnout Vandecappelle <arnout at mind.be <mailto:arnout@mind.be>> wrote:
>
>     > > Could something like that be enough ? can we trust "remount RW" ?
>     > > maybe "remount RW" should be renamed "create a RW filesystem"
>     and enable various
>     > > tweaks related to RO vs RW
>     >
>     >? As written above: no.
>     >
>     >? The problem is: we're not a distro.
>
>     Agreed.
>
>     > We leave too much freedom for the user to
>     > integrate things in various ways to be able to make assumptions
>     about what is
>     > the right way to do things. So, the only thing we can do is to
>     give a decent
>     > out-of-the-box experience, and let the user figure out how to
>     tweak things -
>     > possibly adding a config option for a common situation that is
>     easily handled in
>     > a generic way. The other thing we can do is to provide
>     documentation about the
>     > proper way to integrate things in different scenarios.
>     >
>     >? I'm starting to agree that this option is maybe not that great.
>
>     But I would in fact not come to the same conclusion. Having this empty
>     machine-id file is useless and causes problems when the filesystem is
>     R/W. So for the sake of supporting the R/O case (for which we create
>     this empty machine-id file), we make the R/W experience less good.
>
>     So I'd say that the right approach is to not do too much
>     integration by
>     precisely having the option proposed by Bartosz, with many the tweak
>     that it should default y if rootfs is really, and default disable
>     otherwise, but while still being an option that the user can tweak,
>     because as you rightfully explained, the RW/RO remount option is
>     just a
>     clue, not a definitive answer on whether /etc is writable or not.
>
>     To me, having this option matches the Buildroot way: we are not a
>     distro, we don't enforce how the system should work, so we provide the
>     appropriate options, while making sure the option has the most
>     sensible
>     default values.
>
>     Generally speaking, Buildroot kind of supports "out of the box"
>     two use
>     cases:
>
>     ?(1) The root filesystem is completely read-write.
>
>     ?(2) The root filesystem is completely read-only, and all files
>     that need
>     ? ? ?to be written are stored in tmpfs, and therefore are volatile.
>
>     I.e, we do not have any explicit support for what is I guess a much
>     more common use case than (2):
>
>     ?(3) The root filesystem is completely read-only, but there is another
>     ? ? ?read-write partition somewhere that stores the information
>     that can
>     ? ? ?change but needs to be persistent (user configuration, etc.)
>
>     Since we don't have explicit support for (3), there is no way we can
>     properly support machine-id and ConditionFirstBoot in the case of (2),
>     because there's nowhere we can store /etc/machine-id.
>
>     So the best we can do is in the case of (2), default to creating an
>     empty /etc/machine-id, while giving the possibility for the user
>     implementing (3) in its own way, to disable the creation of the empty
>     /etc/machine-id.
>
>     Best regards,
>
>     Thomas
>     -- 
>     Thomas Petazzoni, CTO, Bootlin
>     Embedded Linux and Kernel engineering
>     https://bootlin.com
>
>
>
> -- 
> SMILE <http://www.smile.eu/>
>
> 20 rue des Jardins
> 92600 Asni?res-sur-Seine
>
> 	
> *J?r?my ROSEN*
> Architecte technique
>
> email jeremy.rosen at smile.fr <mailto:jeremy.rosen@smile.fr>
> phone? +33 6 88 25 87 42
> url http://www.smile.eu <http://www.smile.eu/>
>
> Twitter <https://twitter.com/GroupeSmile> Facebook 
> <https://www.facebook.com/smileopensource> LinkedIn 
> <https://www.linkedin.com/company/smile> Github 
> <https://github.com/Smile-SA>
>
>
> D?couvrez l?univers Smile, rendez-vous sur smile.eu 
> <https://www.smile.eu/fr/publications/livres-blancs/yocto?utm_source=signature&utm_medium=email&utm_campaign=signature>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20200203/3c4a0a7b/attachment.html>

[Buildroot] [PATCH 1/2] package/systemd: set machine id file instalation as optional choice

[Bartosz Bilas]

Hi everyone,

I had finally a couple of time to double-check that and I agree with 
Jeremy that I was wrong therefore let's reject this patch as it turned 
out as an unthought idea.


Best
Bartek
On 03.02.2020 19:28, Bartosz Bilas wrote:
> Hello everyone,
>
> let's reject this patch due to possible upstream solution as Jeremy 
> mentioned.
>
> Best
> Bartek
> On 19.11.2019 11:15, J?r?my ROSEN wrote:
>> As a side-note, I am working with upstream to have a better support 
>> of (3) : https://github.com/systemd/systemd/pull/14059
>>
>> I am a bit cautious about the new config option because it seems too 
>> "advanced" for a config option (for me, it's something that should be set
>> in a post-image or overlay) but that's open to discussion.
>>
>> Please wait a little before applying this patch, if that's the way 
>> buildroot wants to go, so my pull-request above is solved and we might
>> backport it to ease our transition.
>>
>> Cheers
>> J?r?my
>>
>> Le?mar. 19 nov. 2019 ??09:40, Thomas Petazzoni 
>> <thomas.petazzoni at bootlin.com <mailto:thomas.petazzoni@bootlin.com>> 
>> a ?crit?:
>>
>>     Hello,
>>
>>     On Sun, 17 Nov 2019 17:00:05 +0100
>>     Arnout Vandecappelle <arnout at mind.be <mailto:arnout@mind.be>> wrote:
>>
>>     > > Could something like that be enough ? can we trust "remount RW" ?
>>     > > maybe "remount RW" should be renamed "create a RW filesystem"
>>     and enable various
>>     > > tweaks related to RO vs RW
>>     >
>>     >? As written above: no.
>>     >
>>     >? The problem is: we're not a distro.
>>
>>     Agreed.
>>
>>     > We leave too much freedom for the user to
>>     > integrate things in various ways to be able to make assumptions
>>     about what is
>>     > the right way to do things. So, the only thing we can do is to
>>     give a decent
>>     > out-of-the-box experience, and let the user figure out how to
>>     tweak things -
>>     > possibly adding a config option for a common situation that is
>>     easily handled in
>>     > a generic way. The other thing we can do is to provide
>>     documentation about the
>>     > proper way to integrate things in different scenarios.
>>     >
>>     >? I'm starting to agree that this option is maybe not that great.
>>
>>     But I would in fact not come to the same conclusion. Having this
>>     empty
>>     machine-id file is useless and causes problems when the filesystem is
>>     R/W. So for the sake of supporting the R/O case (for which we create
>>     this empty machine-id file), we make the R/W experience less good.
>>
>>     So I'd say that the right approach is to not do too much
>>     integration by
>>     precisely having the option proposed by Bartosz, with many the tweak
>>     that it should default y if rootfs is really, and default disable
>>     otherwise, but while still being an option that the user can tweak,
>>     because as you rightfully explained, the RW/RO remount option is
>>     just a
>>     clue, not a definitive answer on whether /etc is writable or not.
>>
>>     To me, having this option matches the Buildroot way: we are not a
>>     distro, we don't enforce how the system should work, so we
>>     provide the
>>     appropriate options, while making sure the option has the most
>>     sensible
>>     default values.
>>
>>     Generally speaking, Buildroot kind of supports "out of the box"
>>     two use
>>     cases:
>>
>>     ?(1) The root filesystem is completely read-write.
>>
>>     ?(2) The root filesystem is completely read-only, and all files
>>     that need
>>     ? ? ?to be written are stored in tmpfs, and therefore are volatile.
>>
>>     I.e, we do not have any explicit support for what is I guess a much
>>     more common use case than (2):
>>
>>     ?(3) The root filesystem is completely read-only, but there is
>>     another
>>     ? ? ?read-write partition somewhere that stores the information
>>     that can
>>     ? ? ?change but needs to be persistent (user configuration, etc.)
>>
>>     Since we don't have explicit support for (3), there is no way we can
>>     properly support machine-id and ConditionFirstBoot in the case of
>>     (2),
>>     because there's nowhere we can store /etc/machine-id.
>>
>>     So the best we can do is in the case of (2), default to creating an
>>     empty /etc/machine-id, while giving the possibility for the user
>>     implementing (3) in its own way, to disable the creation of the empty
>>     /etc/machine-id.
>>
>>     Best regards,
>>
>>     Thomas
>>     -- 
>>     Thomas Petazzoni, CTO, Bootlin
>>     Embedded Linux and Kernel engineering
>>     https://bootlin.com
>>
>>
>>
>> -- 
>> SMILE <http://www.smile.eu/>
>>
>> 20 rue des Jardins
>> 92600 Asni?res-sur-Seine
>>
>> 	
>> *J?r?my ROSEN*
>> Architecte technique
>>
>> email jeremy.rosen at smile.fr <mailto:jeremy.rosen@smile.fr>
>> phone? +33 6 88 25 87 42
>> url http://www.smile.eu <http://www.smile.eu/>
>>
>> Twitter <https://twitter.com/GroupeSmile> Facebook 
>> <https://www.facebook.com/smileopensource> LinkedIn 
>> <https://www.linkedin.com/company/smile> Github 
>> <https://github.com/Smile-SA>
>>
>>
>> D?couvrez l?univers Smile, rendez-vous sur smile.eu 
>> <https://www.smile.eu/fr/publications/livres-blancs/yocto?utm_source=signature&utm_medium=email&utm_campaign=signature>
>
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20200203/e21e22b7/attachment-0001.html>

[Buildroot] [PATCH 1/2] package/systemd: set machine id file instalation as optional choice

[Bartosz Bilas]

Nah, sorry guys - I've been mistaken for the email so please ignore the 
previous message then.


Best
Bartek
On 03.02.2020 19:34, Bartosz Bilas wrote:
>
> Hi everyone,
>
> I had finally a couple of time to double-check that and I agree with 
> Jeremy that I was wrong therefore let's reject this patch as it turned 
> out as an unthought idea.
>
>
> Best
> Bartek
> On 03.02.2020 19:28, Bartosz Bilas wrote:
>> Hello everyone,
>>
>> let's reject this patch due to possible upstream solution as Jeremy 
>> mentioned.
>>
>> Best
>> Bartek
>> On 19.11.2019 11:15, J?r?my ROSEN wrote:
>>> As a side-note, I am working with upstream to have a better support 
>>> of (3) : https://github.com/systemd/systemd/pull/14059
>>>
>>> I am a bit cautious about the new config option because it seems too 
>>> "advanced" for a config option (for me, it's something that should 
>>> be set
>>> in a post-image or overlay) but that's open to discussion.
>>>
>>> Please wait a little before applying this patch, if that's the way 
>>> buildroot wants to go, so my pull-request above is solved and we might
>>> backport it to ease our transition.
>>>
>>> Cheers
>>> J?r?my
>>>
>>> Le?mar. 19 nov. 2019 ??09:40, Thomas Petazzoni 
>>> <thomas.petazzoni at bootlin.com <mailto:thomas.petazzoni@bootlin.com>> 
>>> a ?crit?:
>>>
>>>     Hello,
>>>
>>>     On Sun, 17 Nov 2019 17:00:05 +0100
>>>     Arnout Vandecappelle <arnout at mind.be <mailto:arnout@mind.be>> wrote:
>>>
>>>     > > Could something like that be enough ? can we trust "remount
>>>     RW" ?
>>>     > > maybe "remount RW" should be renamed "create a RW
>>>     filesystem" and enable various
>>>     > > tweaks related to RO vs RW
>>>     >
>>>     >? As written above: no.
>>>     >
>>>     >? The problem is: we're not a distro.
>>>
>>>     Agreed.
>>>
>>>     > We leave too much freedom for the user to
>>>     > integrate things in various ways to be able to make
>>>     assumptions about what is
>>>     > the right way to do things. So, the only thing we can do is to
>>>     give a decent
>>>     > out-of-the-box experience, and let the user figure out how to
>>>     tweak things -
>>>     > possibly adding a config option for a common situation that is
>>>     easily handled in
>>>     > a generic way. The other thing we can do is to provide
>>>     documentation about the
>>>     > proper way to integrate things in different scenarios.
>>>     >
>>>     >? I'm starting to agree that this option is maybe not that great.
>>>
>>>     But I would in fact not come to the same conclusion. Having this
>>>     empty
>>>     machine-id file is useless and causes problems when the
>>>     filesystem is
>>>     R/W. So for the sake of supporting the R/O case (for which we create
>>>     this empty machine-id file), we make the R/W experience less good.
>>>
>>>     So I'd say that the right approach is to not do too much
>>>     integration by
>>>     precisely having the option proposed by Bartosz, with many the tweak
>>>     that it should default y if rootfs is really, and default disable
>>>     otherwise, but while still being an option that the user can tweak,
>>>     because as you rightfully explained, the RW/RO remount option is
>>>     just a
>>>     clue, not a definitive answer on whether /etc is writable or not.
>>>
>>>     To me, having this option matches the Buildroot way: we are not a
>>>     distro, we don't enforce how the system should work, so we
>>>     provide the
>>>     appropriate options, while making sure the option has the most
>>>     sensible
>>>     default values.
>>>
>>>     Generally speaking, Buildroot kind of supports "out of the box"
>>>     two use
>>>     cases:
>>>
>>>     ?(1) The root filesystem is completely read-write.
>>>
>>>     ?(2) The root filesystem is completely read-only, and all files
>>>     that need
>>>     ? ? ?to be written are stored in tmpfs, and therefore are volatile.
>>>
>>>     I.e, we do not have any explicit support for what is I guess a much
>>>     more common use case than (2):
>>>
>>>     ?(3) The root filesystem is completely read-only, but there is
>>>     another
>>>     ? ? ?read-write partition somewhere that stores the information
>>>     that can
>>>     ? ? ?change but needs to be persistent (user configuration, etc.)
>>>
>>>     Since we don't have explicit support for (3), there is no way we can
>>>     properly support machine-id and ConditionFirstBoot in the case
>>>     of (2),
>>>     because there's nowhere we can store /etc/machine-id.
>>>
>>>     So the best we can do is in the case of (2), default to creating an
>>>     empty /etc/machine-id, while giving the possibility for the user
>>>     implementing (3) in its own way, to disable the creation of the
>>>     empty
>>>     /etc/machine-id.
>>>
>>>     Best regards,
>>>
>>>     Thomas
>>>     -- 
>>>     Thomas Petazzoni, CTO, Bootlin
>>>     Embedded Linux and Kernel engineering
>>>     https://bootlin.com
>>>
>>>
>>>
>>> -- 
>>> SMILE <http://www.smile.eu/>
>>>
>>> 20 rue des Jardins
>>> 92600 Asni?res-sur-Seine
>>>
>>> 	
>>> *J?r?my ROSEN*
>>> Architecte technique
>>>
>>> email jeremy.rosen at smile.fr <mailto:jeremy.rosen@smile.fr>
>>> phone? +33 6 88 25 87 42
>>> url http://www.smile.eu <http://www.smile.eu/>
>>>
>>> Twitter <https://twitter.com/GroupeSmile> Facebook 
>>> <https://www.facebook.com/smileopensource> LinkedIn 
>>> <https://www.linkedin.com/company/smile> Github 
>>> <https://github.com/Smile-SA>
>>>
>>>
>>> D?couvrez l?univers Smile, rendez-vous sur smile.eu 
>>> <https://www.smile.eu/fr/publications/livres-blancs/yocto?utm_source=signature&utm_medium=email&utm_campaign=signature>
>>
>> _______________________________________________
>> buildroot mailing list
>> buildroot at busybox.net
>> http://lists.busybox.net/mailman/listinfo/buildroot
>
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20200203/40ed1c57/attachment.html>

[Buildroot] [PATCH 1/2] package/systemd: set machine id file instalation as optional choice

[Jérémy ROSEN]

So don't drop your patch ?

I still think that the approach I proposed upstream is the best one but I
am pessimistic about the chances of upsreaming...
I'll ping the issue, but don't hold your breath.

If this is rejected upstream, we might want to keep the patch locally, but
that's a subject to discuss when we reach that point.

Le lun. 3 f?vr. 2020 ? 19:41, Bartosz Bilas <b.bilas@grinn-global.com> a
?crit :

> Nah, sorry guys - I've been mistaken for the email so please ignore the
> previous message then.
>
>
> Best
> Bartek
> On 03.02.2020 19:34, Bartosz Bilas wrote:
>
> Hi everyone,
>
> I had finally a couple of time to double-check that and I agree with
> Jeremy that I was wrong therefore let's reject this patch as it turned out
> as an unthought idea.
>
>
> Best
> Bartek
> On 03.02.2020 19:28, Bartosz Bilas wrote:
>
> Hello everyone,
>
> let's reject this patch due to possible upstream solution as Jeremy
> mentioned.
> Best
> Bartek
> On 19.11.2019 11:15, J?r?my ROSEN wrote:
>
> As a side-note, I am working with upstream to have a better support of (3)
> : https://github.com/systemd/systemd/pull/14059
>
> I am a bit cautious about the new config option because it seems too
> "advanced" for a config option (for me, it's something that should be set
> in a post-image or overlay) but that's open to discussion.
>
> Please wait a little before applying this patch, if that's the way
> buildroot wants to go, so my pull-request above is solved and we might
> backport it to ease our transition.
>
> Cheers
> J?r?my
>
> Le mar. 19 nov. 2019 ? 09:40, Thomas Petazzoni <
> thomas.petazzoni at bootlin.com> a ?crit :
>
>> Hello,
>>
>> On Sun, 17 Nov 2019 17:00:05 +0100
>> Arnout Vandecappelle <arnout@mind.be> wrote:
>>
>> > > Could something like that be enough ? can we trust "remount RW" ?
>> > > maybe "remount RW" should be renamed "create a RW filesystem" and
>> enable various
>> > > tweaks related to RO vs RW
>> >
>> >  As written above: no.
>> >
>> >  The problem is: we're not a distro.
>>
>> Agreed.
>>
>> > We leave too much freedom for the user to
>> > integrate things in various ways to be able to make assumptions about
>> what is
>> > the right way to do things. So, the only thing we can do is to give a
>> decent
>> > out-of-the-box experience, and let the user figure out how to tweak
>> things -
>> > possibly adding a config option for a common situation that is easily
>> handled in
>> > a generic way. The other thing we can do is to provide documentation
>> about the
>> > proper way to integrate things in different scenarios.
>> >
>> >  I'm starting to agree that this option is maybe not that great.
>>
>> But I would in fact not come to the same conclusion. Having this empty
>> machine-id file is useless and causes problems when the filesystem is
>> R/W. So for the sake of supporting the R/O case (for which we create
>> this empty machine-id file), we make the R/W experience less good.
>>
>> So I'd say that the right approach is to not do too much integration by
>> precisely having the option proposed by Bartosz, with many the tweak
>> that it should default y if rootfs is really, and default disable
>> otherwise, but while still being an option that the user can tweak,
>> because as you rightfully explained, the RW/RO remount option is just a
>> clue, not a definitive answer on whether /etc is writable or not.
>>
>> To me, having this option matches the Buildroot way: we are not a
>> distro, we don't enforce how the system should work, so we provide the
>> appropriate options, while making sure the option has the most sensible
>> default values.
>>
>> Generally speaking, Buildroot kind of supports "out of the box" two use
>> cases:
>>
>>  (1) The root filesystem is completely read-write.
>>
>>  (2) The root filesystem is completely read-only, and all files that need
>>      to be written are stored in tmpfs, and therefore are volatile.
>>
>> I.e, we do not have any explicit support for what is I guess a much
>> more common use case than (2):
>>
>>  (3) The root filesystem is completely read-only, but there is another
>>      read-write partition somewhere that stores the information that can
>>      change but needs to be persistent (user configuration, etc.)
>>
>> Since we don't have explicit support for (3), there is no way we can
>> properly support machine-id and ConditionFirstBoot in the case of (2),
>> because there's nowhere we can store /etc/machine-id.
>>
>> So the best we can do is in the case of (2), default to creating an
>> empty /etc/machine-id, while giving the possibility for the user
>> implementing (3) in its own way, to disable the creation of the empty
>> /etc/machine-id.
>>
>> Best regards,
>>
>> Thomas
>> --
>> Thomas Petazzoni, CTO, Bootlin
>> Embedded Linux and Kernel engineering
>> https://bootlin.com
>>
>
>
> --
> [image: SMILE]  <http://www.smile.eu/>
>
> 20 rue des Jardins
> 92600 Asni?res-sur-Seine
> *J?r?my ROSEN*
> Architecte technique
>
> [image: email] jeremy.rosen at smile.fr
> [image: phone]  +33 6 88 25 87 42
> [image: url] http://www.smile.eu
>
> [image: Twitter] <https://twitter.com/GroupeSmile> [image: Facebook]
> <https://www.facebook.com/smileopensource> [image: LinkedIn]
> <https://www.linkedin.com/company/smile> [image: Github]
> <https://github.com/Smile-SA>
>
> [image: D?couvrez l?univers Smile, rendez-vous sur smile.eu]
> <https://www.smile.eu/fr/publications/livres-blancs/yocto?utm_source=signature&utm_medium=email&utm_campaign=signature>
>
>
> _______________________________________________
> buildroot mailing listbuildroot at busybox.nethttp://lists.busybox.net/mailman/listinfo/buildroot
>
>
> _______________________________________________
> buildroot mailing listbuildroot at busybox.nethttp://lists.busybox.net/mailman/listinfo/buildroot
>
>

-- 
[image: SMILE]  <http://www.smile.eu/>

20 rue des Jardins
92600 Asni?res-sur-Seine
*J?r?my ROSEN*
Architecte technique

[image: email] jeremy.rosen at smile.fr
[image: phone]  +33 6 88 25 87 42
[image: url] http://www.smile.eu

[image: Twitter] <https://twitter.com/GroupeSmile> [image: Facebook]
<https://www.facebook.com/smileopensource> [image: LinkedIn]
<https://www.linkedin.com/company/smile> [image: Github]
<https://github.com/Smile-SA>

[image: D?couvrez l?univers Smile, rendez-vous sur smile.eu]
<https://www.smile.eu/fr/publications/livres-blancs/yocto?utm_source=signature&utm_medium=email&utm_campaign=signature>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20200205/d16b4a3f/attachment.html>

Re: [Buildroot] [PATCH 1/2] package/systemd: set machine id file instalation as optional choice

[Thomas Petazzoni]

Hello Bartosz,

On Sun, 17 Nov 2019 12:33:44 +0100
Bartosz Bilas <b.bilas@grinn-global.com> wrote:

> In case of e.g writable systems there is no neccesity to have
> pre-installed empty machine-id file on target because systemd
> generates that automatically during system boot.
> Also in case of having empty machine-id file we are not able
> to use a service with ConditionFirstBoot because systemd recognizes
> machine-id file in system therefore we can't detect new system instance boots up.
> Set this option as enable by default to keep compatibility with old builds.
> 
> Signed-off-by: Bartosz Bilas <b.bilas@grinn-global.com>
> ---
>  package/systemd/Config.in  | 13 +++++++++++++
>  package/systemd/systemd.mk |  2 ++
>  2 files changed, 15 insertions(+)

This series of two patches has been sitting on the mailing list for a
long time. The feedback of Jérémy was not very positive (i.e quite
negative) and you said yourself on this patch "I had finally a couple
of time to double-check that and I agree with Jeremy that I was wrong
therefore let's reject this patch as it turned out as an unthought
idea.", but then you said you were mistaken, Jeremy asked for
clarifications which were never given.

So at this point, I'm going to mark those two patches as Rejected.
However, if you believe there is still something to improve, do not
hesitate to reopen the discussion.

Thanks a lot!

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot