[Buildroot] [PATCH 2/2] package/systemd: set systemd generators instalation as optional choice
Bartosz Bilas
b.bilas at grinn-global.com
Mon Nov 25 16:55:32 UTC 2019
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
> http://lists.busybox.net/mailman/listinfo/buildroot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20191125/d68c75f9/attachment.html>
More information about the buildroot
mailing list