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

Bartosz Bilas b.bilas at grinn-global.com
Mon Feb 3 18:37:30 UTC 2020


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 at grinn-global.com 
> <mailto:b.bilas at 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 at 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 at 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 at grinn-global.com
>>>             <mailto:b.bilas at 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 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
>>>             <mailto: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 at 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 at 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 at 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 at 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>


More information about the buildroot mailing list