init-manager-none.inc: have no init manager

From: Michael Opdenacker <michael.opdenacker@bootlin.com>

This fixes the issue that setting INIT_MANAGER to "none"
produces a system with sysvinit.

As the name suggests, this produces a system without
an init manager (no systemd, no sysvinit, no BusyBox init, no
/etc/inittab). There isn't any login manager either.
The kernel just starts /bin/sh in the console.

Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
---
 meta/conf/distro/include/init-manager-none.inc | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

Hello,

This causes the following error:

https://autobuilder.yoctoproject.org/typhoon/#/builders/47/builds/7035/steps/12/logs/stdio

This is the expected behaviour of the patch but doesn't fit with what
this particular build (qemuarm-oecore) is testing as we can't run
testimage without an init. I'm wondering what should be the proper
course of action here.


On 28/04/2023 11:06:02+0200, Michael Opdenacker via lists.openembedded.org wrote:
> From: Michael Opdenacker <michael.opdenacker@bootlin.com>
> 
> This fixes the issue that setting INIT_MANAGER to "none"
> produces a system with sysvinit.
> 
> As the name suggests, this produces a system without
> an init manager (no systemd, no sysvinit, no BusyBox init, no
> /etc/inittab). There isn't any login manager either.
> The kernel just starts /bin/sh in the console.
> 
> Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
> ---
>  meta/conf/distro/include/init-manager-none.inc | 7 ++++---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/meta/conf/distro/include/init-manager-none.inc b/meta/conf/distro/include/init-manager-none.inc
> index bbedf898f7..56d2b0f406 100644
> --- a/meta/conf/distro/include/init-manager-none.inc
> +++ b/meta/conf/distro/include/init-manager-none.inc
> @@ -1,3 +1,4 @@
> -VIRTUAL-RUNTIME_init_manager ??= "sysvinit"
> -VIRTUAL-RUNTIME_initscripts ??= "initscripts"
> -VIRTUAL-RUNTIME_login_manager ??= "busybox"
> +DISTRO_FEATURES_BACKFILL_CONSIDERED:append = " systemd sysvinit"
> +VIRTUAL-RUNTIME_init_manager ??= ""
> +VIRTUAL-RUNTIME_initscripts ??= ""
> +VIRTUAL-RUNTIME_login_manager ??= ""
> -- 
> 2.34.1
> 

> 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#180524): https://lists.openembedded.org/g/openembedded-core/message/180524
> Mute This Topic: https://lists.openembedded.org/mt/98554799/3617179
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [alexandre.belloni@bootlin.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>

Hi Alex,

On 02.05.23 at 16:14, Alexandre Belloni wrote:
> Hello,
>
> This causes the following error:
>
> https://autobuilder.yoctoproject.org/typhoon/#/builders/47/builds/7035/steps/12/logs/stdio
>
> This is the expected behaviour of the patch but doesn't fit with what
> this particular build (qemuarm-oecore) is testing as we can't run
> testimage without an init. I'm wondering what should be the proper
> course of action here.


Thanks for the report!
Maybe another option is to remove the "none" option, as someone also 
suggested, as it is currently identical to the "sysvinit" option.

Any further thoughts?
Thanks again
Michael.

On Tue, 2023-05-02 at 16:14 +0200, Alexandre Belloni via
lists.yoctoproject.org wrote:
> Hello,
> 
> This causes the following error:
> 
> https://autobuilder.yoctoproject.org/typhoon/#/builders/47/builds/7035/steps/12/logs/stdio
> 
> This is the expected behaviour of the patch but doesn't fit with what
> this particular build (qemuarm-oecore) is testing as we can't run
> testimage without an init. I'm wondering what should be the proper
> course of action here.
> 

INIT_MANAGER didn't used to be a variable and therefore could in theory
be unset. The "none" configuration was designed to cause the system to
fall back to the original behaviour. OE-Core's "nodistro" uses the
fallback.

We could decide just to require this variable to be set to something
but this could potentially conflict with people setting up their init
system "manually" within their own distro.

It is a bit tricky to know what to do in situations like these.
INIT_MANAGER was added to try and help people avoid needing to repeat
certain config fragments.

Cheers,

Richard