Re: RFE: make the init manager an image feature (again)

[Enrico Scholz <enrico.scholz@sigma-chemnitz.de>]

"Burton, Ross" <ross.burton-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
writes:

> "With recent systemd packaging change, the rescue image size grow up
> from 5.9 MiB to 27 MiB because systemd dependencies are hardcoded in
> mandatory packages."
>
> This certainly can happen.  core-image-minimal-initramfs went from 19M
> up to 35M if you turn on systemd with the (unmerged) busybox enabling
> turned on.  Investigating this shows that the cause was busybox
> recommending busybox-syslog which depends on systemd, which isn't
> useful in the initramfs.  My branch adds busybox-syslog to
> BAD_RECOMMENDS and it's back down to 19M.  

I want busybox-syslogd in the rescue image. And an ntp + dhcp client
and http server.  Next might be tools from util-linux which depends on
systemd too.


> When people are building images with and without systemd, how are the
> non-systemd images booting?

Custom /init which executes busybox's /sbin/init finally.


> If sysvinit, what's the rationale for this?

It allows modularization (starting new services without editing /init)
with zero costs (busybox-init is already there).  I need full control
over things like attaching/detecting ubi volumes or sd cards and I feel
much better, when every line of relevant code was written by me ;)


> Will you consider switching to systemd for everything if the disk
> increase was only a new MB, on the grounds of consistent booting
> behaviour?

Definitively not.  There is far too much logic in usual systemd/udev
systems (e.g. accessing block devices and other hardware during udev
scanning) which contradicts with purposes of a rescue system.


> One massive problem with making init system an image time choice with
> packages is what happens when you have a feed with both pn-sysv and
> pn-systemd packages in.

I wrote some ideas here[1]. It starts with moving init script subpackages
into separate 'all-<initsys>' feeds till implementing the BAD_RECOMMENDS
mechanism in the depsolvers.

For me, it would be also okay, when runtime package management gets ignored
at all (rescue system are initramfs images without pkg management) and
making the initmgr in DISTRO_FEATURES selecting the default RRECOMMENDS.
The actual BAD_RECOMMENDATIONS mechanism works perfect in this case; adding
interesting -sysv subpackages manually when creating the rescue image would
be ok for me.


> The alternative is that if sysvinit and systemd are enabled we can't
> do any real systemd enabling.

Why not?  The functions in libsystemd are robust enough so that daemons
are still working in non-systemd systems.



Enrico

Footnotes: 
[1]  http://lists.linuxtogo.org/pipermail/openembedded-core/2013-February/035998.html