Re: [gentoo-dev] eselect init

[Sergei Trofimovich]

On Sat, 25 May 2013 11:54:48 +0200
Luca Barbato <lu_zero@g.o> wrote:

> Hi, since the whole discussion got somehow sidetracked on where and if
> to install for everybody the rc system specific files for everybody
> (that should be an implementation detail for the specific dohelper
> IMHO), I'm back to the other part of it: switching the actual init
> implementation.
>
> # WHY (not just edit your bootloader)
>
> Since efi at least some people started to put in the kernel the bootargs
> and we have at least few new options brewing for init, some are
> small impact (bootchar, bb-init-openrc and runit-openrc) some are more
> invasive (runit and systemd).
>
> In those setup changing bootargs requires a kernel rebuild and some
> effort, while the eselect approach stays completely transparent.
>
> For some switch we might not have just to change the init binary bit
> also to do some other changes (e.g. use a different format for inittab)

If you can't change options at boot time it's very simple to get
unbootable system. Just curious, who does such systems and
how root filesystem (+ it's mount options) is expected to be
found there?

I guess EFI allows you to set bootargs via EFI UI.

I'd go for init=/sbin/gentoo-init and make all the messy stuff there.
Otherwise by breaking /sbin/init it would be hard to find proper
name of, say, SYSVs /sbin/init. How would you call it?

> # KEYPOINTS
>
> - /sbin/init (or whatever linux currently calls by default with top
> priority) should be either a symlink to the actual implementation or a
> wrapper such as our gcc one. I like better the latter since it is
> overall safer. The former might or might work since linux has some
> fallback capabilities but hadn't been tested.
>
> - init gets effectively switched only at boot/reboot, eselect init must
> keep track of the current active init and make sure the current init
> configuration is used till the system reboots, if we use the wrapper
> approach, it would pick up what's the new init at boot and that would be
> enough for simple cases, hooks on reboot are still needed for more
> complex ones.
>
> - we could try to not have the changes to the current init systems
> ebuild or reduce them to the bare minimum (e.g. not overwrite /sbin/init)
>
> # FOCUS
>
> My interest is mostly if not all on bb-init-openrc and slightly on
> runit-openrc.
>
> There are enough people involved in systemd and since I still consider
> it a dangerously frail implementation of a bad idea is better if I do
> not touch it at all.
>
> My system with stock openrc gets from linux start to graphical login in
> less than 6s and I'm not using Gnome so I do not have any reason to use
> it beside comparing.
>
> lu
>
>


-- 

  Sergei