| Message ID | 20191117113345.159653-2-b.bilas@grinn-global.com |
|---|---|
| State | Rejected |
| Headers | show |
| Series | None | expand |
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@.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@.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
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@.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@.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
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@.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@.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@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>
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@.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@.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@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> > >
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@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@.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@.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@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@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@busybox.net > http://lists.busybox.net/mailman/listinfo/buildroot
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@.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@.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@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@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@busybox.nethttp://lists.busybox.net/mailman/listinfo/buildroot > >
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@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@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@.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@.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@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@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@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@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>
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@.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@.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 \
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(+)