[gentoo-dev] eselect init

[gentoo-dev] eselect init

[Luca Barbato]

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)

# 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

Re: [gentoo-dev] eselect init

[Peter Stuge]

Luca Barbato wrote:
> - init gets effectively switched only at boot/reboot

Please not on reboot, because an unclean shutdown shouldn't leave the
system in limbo.

On boot could work, except that it does add more steps (= more
fragility) to the boot process, which I think everyone wants to
avoid.

I would actually expect the change to take effect immediately.


//Peter

Re: [gentoo-dev] eselect init

[Pacho Ramos]

El sáb, 25-05-2013 a las 11:54 +0200, Luca Barbato escribió:
> 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).

I use e4rat and, for that, I need to add 
init=/sbin/e4rat-preload

to my grub.conf, I guess this wouldn't change with this, no? :/

Thanks for the info!

Re: [gentoo-dev] eselect init

[Sergei Trofimovich]

[-- Attachment #1: Type: text/plain, Size: 2819 bytes --]

On Sat, 25 May 2013 11:54:48 +0200
Luca Barbato <lu_zero@gentoo.org> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] eselect init

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 1531 bytes --]

On Sat, 25 May 2013 12:25:03 +0200
Peter Stuge <peter@stuge.se> wrote:

> I would actually expect the change to take effect immediately.

Then how would you be able to shutdown / reboot your system in a clean
way? The premise here is that when you boot with an init system you
must shutdown with that same init system, you can't just start one init
system and expect the other init system to cleanly shut down its
services. Therefore implementing this would either be unclean or way to
complex. 

From all the methods discussed doing it on boot sounds the most sane.

> On boot could work, except that it does add more steps (= more
> fragility) to the boot process, which I think everyone wants to avoid.

If it is implemented properly, it really isn't that fragile as you
would think; it doesn't take much input, so there is barely any
implementation and bug fixing needed and it will work everywhere.

Users that manage to break this will often know how to fix, unless we
messed up from the Portage tree; but well, this mostly boils down to a
proper news item and documentation _before_ bringing this out such that
users are at least aware of this crucial boot process change.

Anyhow, users need to be aware anyway for when they ever decide to try
or switch another init system in the future.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] eselect init

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 832 bytes --]

On Sat, 25 May 2013 13:13:36 +0200
Pacho Ramos <pacho@gentoo.org> wrote:

> I use e4rat and, for that, I need to add 
> init=/sbin/e4rat-preload
> 
> to my grub.conf, I guess this wouldn't change with this, no? :/
> 
> Thanks for the info!

That instead of the default will first load e4rat-preload and only
after that the init symlink / wrapper will be called. 

So, the changes being discussed here will not prevent e4rat-preload
from running, but rather change what would happen after e4rat-preload
kicks off init. It is a transparent change and should not affect
e4rat-preload functionality in a bad way.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] eselect init

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 1913 bytes --]

On Sat, 25 May 2013 14:29:12 +0300
Sergei Trofimovich <slyfox@gentoo.org> wrote:

> If you can't change options at boot time it's very simple to get
> unbootable system.

https://bugs.gentoo.org/show_bug.cgi?id=465236#c34

In above Bug #465236 at Comment #34 the suggestion has been made to
maybe call the wrapper /sbin/einit and leave /sbin/init at a sane
default. That way the user should still be able to boot the Gentoo
default as long as it does not end up being removed from the system.

In other words, changing init=/sbin/einit back to init/sbin/init fixes
things; I don't think it's asked too much to add init=/sbin/einit in
the bootloader or kernel in the alternative init systems documentation.

> Just curious, who does such systems and how root filesystem (+ it's
> mount options) is expected to be found there?

I don't see how this is a problem; the kernel loads what you have
set as init and after that you have root filesystem access, possibly
read only at this point but you don't have to find the root fs here.

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

Not so sure about this, but most people end up hardcoding it in the
kernel; you can do this by setting CONFIG_CMDLINE.

> 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?

Yeah, this is what the /sbin/einit suggestion above tries to resolve.

We shouldn't have our users guess at names here, all they should
know is to add einit if they wish to be able to switch and that
removing it will load the default init system present on Gentoo...

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] eselect init

[hasufell]

Isn't eselect for cases where I might want to reconfigure something or
add configuration values such as for bash-completion, do testing with
java-vm or python implementations during development, switch opengl
implementation depending on the graphics driver loaded and whatnot.

I don't see any of this applying to init system, nor do I see a reason
to randomly switch between those. It's rather something to configure
during installation, so I'd rather expect proper documentation.

But I am not opposing, I just find it weird.

Re: [gentoo-dev] eselect init

[Pacho Ramos]

El sáb, 25-05-2013 a las 14:03 +0200, Tom Wijsman escribió:
> On Sat, 25 May 2013 13:13:36 +0200
> Pacho Ramos <pacho@gentoo.org> wrote:
> 
> > I use e4rat and, for that, I need to add 
> > init=/sbin/e4rat-preload
> > 
> > to my grub.conf, I guess this wouldn't change with this, no? :/
> > 
> > Thanks for the info!
> 
> That instead of the default will first load e4rat-preload and only
> after that the init symlink / wrapper will be called. 
> 
> So, the changes being discussed here will not prevent e4rat-preload
> from running, but rather change what would happen after e4rat-preload
> kicks off init. It is a transparent change and should not affect
> e4rat-preload functionality in a bad way.
> 

Great! :D

Re: [gentoo-dev] eselect init

[Luca Barbato]

On 05/25/2013 01:29 PM, Sergei Trofimovich wrote:
> 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?

You write your bootargs in the kernel, if you really must you can go to
the efi shell and override by hand.

you can surely install an efi ui on top of your efi implementation but
that's unrelated. My current setup works decently the way I mentioned
and I guess more than a single person might use it.

> 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?

/bin/init is my idea (second in the list in linux fallback), otherwise
we can just make the wrapper use a non-taken name and have people
willing to play with it just reroll their kernel/boot system.

lu

Re: [gentoo-dev] eselect init

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 8204 bytes --]

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

> since the whole discussion got somehow sidetracked [SNIP], I'm back
> to the other part of it: switching the actual init implementation.

Thank you very much.

> 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.

When we can edit the bootloader, we really shouldn't neglect this
option. There are specific situations (like you mention EFI) where this
may not be possible, but in that case we can just expect our users to
chroot into their system and rebuild the kernel. These users are likely
more used to do that because in my own experience if you mess part of
EFI up you need to do this anyway; there's one option we forget about
here though, EFI users can build a second smaller minimally adjusted
defconfig kernel that ends up loading the default init system if they
wish to repair their system without chrooting. 

So, please see the /sbin/einit suggestion in Bug 465236 at Comment 34
at https://bugs.gentoo.org/show_bug.cgi?id=465236#c34 which documents a
sane alternative that allows users to load the default init system of
Gentoo through their boot loader if they wish to do. This suggestion
doesn't kill the eselect approach, but goes side-by-side with it; it
effectively just names it /sbin/einit instead of /sbin/init to keep the
default /sbin/init around. Another advantage is that users that don't
want extra complexity as they don't want to compare or switch init
systems will not get extra complexity added to their system.

> 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)

Is there a specific need for this? I see this as possible regardless of
how we end up doing this, or are there certain approaches that would
disallow this?

> - /sbin/init (or whatever linux currently calls by default with top
> priority)

Correct as far as I recall from patching that part of boot in the past.

> should be either a symlink to the actual implementation or a
> wrapper such as our gcc one.

Wrapper sounds more safe to me since you allow more logic to be
incorporated and aren't to restricted in what you can do with it early
on, on the other hand a symlink would be a much more clean approach if
you don't need more logic than just the symlink; although I'm not sure
if the kernel loves a symlink for /sbin/init, haven't looked at that...

> I like better the latter since it is overall safer. The former might
> or might not work since linux has some fallback capabilities but
> hadn't been tested.

+1 I agree we should keep things safe when talking about our boot.

> - init gets effectively switched only at boot/reboot

As stated elsewhere in this ML thread, reboot is probably a bad idea to
pursue; so that only leaves us with the boot option. When talking in
the boot context there is likely no actual switch happening but it
rather just kicks off the right progress instead.

> eselect init
> must keep track of the current active init and make sure the current
> init configuration is used till the system reboots

When we kick off the right init system at boot, we probably don't need
to keep track of it separately; or at least not call eselect for that.

Sounds like we would have two files like 'current_init' and 'boot_init'
and `eselect init ...` would update 'boot_init'. Then, the first `init`
invocation on boot would update 'current_init' with the value of
boot_init; latter `init` invocations can then read out 'current_init',
which is not to be touched by `eselect init ...`.

> 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

Ah, I think this is what I gave more detailed above.

> hooks on reboot are still needed for more complex ones.

Which complex cases would these hooks be needed on?

> - 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)

The /sbin/einit approach that I linked near the start would help here.
 
> # 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.

Can we please keep information that may provoke a comparison off the ML?

I'll give a neutral objective response why the init system doesn't
matter for this, as I'm tired of seeing people sneak in data points
like this. In your case it's intended to be good, but it can catch
other people off guard that don't care to stay on topic.

[[ Please avoid responding to this part of my mail, don't go OT. ]]

I believe that any init system can help you reach the amount of time
that you wish to achieve, after having pursued Arjan van de Ven's "one
second for each phase" [1] (not an actual quote but an idea) approach
long time I am down to a two second boot [2] till TTY login, I type my
user and password and a second later I am in my graphical environment.

On average I can't call myself rich as I'm still a student, so apart
from a small SSD and an average CPU this doesn't require much hardware;
or in other words I do not intent to brag here. In fact, I'm willing to
help anyone who wishes to obtain similar results.

The above is using, as you may guess, systemd because of certain
details (eg. sockets); but that DOESN'T mean that with some simple
hacks the same can't be achieved on OpenRC and your example is close
enough to proof that it would indeed be quite possible to do so.

The difference here is extremely minor anyway; most time is gained by
what you end up killing than by choosing an alternative init system,
as you can see these sockets aren't making up a huge difference at all.

When there are multiple similar tools to accomplish something, it does
not depend on how a certain tool is implemented, but rather on which one
fits you best and how you use it. Look at the text editor you use; give
it to your family, colleagues and friends and see how they struggle.

[[ Please avoid responding to this part of my mail, don't go OT. ]]

Please don't reply; I won't read it, I won't respond to it and it will
not benefit this discussion, its reporter or anyone else participating
in any way. You're free to contact me outside of the ML if you are
interested in optimizing your boot, any other replies go to /dev/null.

I wouldn't mind if you cut my mail in half and /dev/null-ed it too. :)

TL;DR: There's no use in comparing boot times between init systems; I
hope that anyone who continues to discuss in this thread or any future
thread will not delude themselves to useless uneducated flame wars,
whether it is boot time or anything else that you could call "better".
What is "better" anyway? It's better for you, but not for everyone...

 [1]: http://lwn.net/Articles/299483

      LPC: Booting Linux in five seconds

 [2]: http://i.imgur.com/wnod9R6.png

      Bootchart2: Small example of how my system boots these day.

      Yes, small, it doesn't allow you to change the scale at which you
      save. Given the result I'm too bored to fix this any further. 

[[ Please avoid responding to this part of my mail, don't go OT. ]]

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] eselect init

[Luca Barbato]

On 05/25/2013 01:13 PM, Pacho Ramos wrote:
> El sáb, 25-05-2013 a las 11:54 +0200, Luca Barbato escribió:
>> 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).
> 
> I use e4rat and, for that, I need to add 
> init=/sbin/e4rat-preload
> 
> to my grub.conf, I guess this wouldn't change with this, no? :/

mostly you would be able to do

# eselect init addon e4rat

instead.

But the whole eselect init should be an opt-in till we are 100% sure it
covers the usual scenarios.

The basic idea is that you would have a wrapper (shellscript or binary)
that just reads from a known location what to run once and what to run
the following times, something along the lines of

if (switching)
    do_switch
else
    exec $real_init

With all the possible failovers.

lu

Re: [gentoo-dev] eselect init

[Luca Barbato]

On 05/25/2013 02:13 PM, hasufell wrote:
> Isn't eselect for cases where I might want to reconfigure something or
> add configuration values such as for bash-completion, do testing with
> java-vm or python implementations during development, switch opengl
> implementation depending on the graphics driver loaded and whatnot.
> 
> I don't see any of this applying to init system, nor do I see a reason
> to randomly switch between those. It's rather something to configure
> during installation, so I'd rather expect proper documentation.

Beside switching completely init system (since there is this itch to try
new toys here), you also have addons such as benchmarks such bootchart,
fs layout mappers/optimizers such as ureadahead and e4rat.

Some are something you want to run on-off.

All this started because Fabio had enough people pestering him about
systemd and he wanted some simple way so people could try it and get
back once burnt or vice-versa.

I have my uses for it since beside using bb-init to shave some time
spent spawning ephemeral processes on complex runscript, there is also
the runit integration in openrc that would feel bad having it rotting in
a branch w/out making it available and it has the very same issues you
have with systemd.

So having an eselect applet for this kind of purposes makes sense.

lu

Re: [gentoo-dev] eselect init

[Sergei Trofimovich]

[-- Attachment #1: Type: text/plain, Size: 578 bytes --]

> > 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?
> 
> /bin/init is my idea (second in the list in linux fallback), otherwise
> we can just make the wrapper use a non-taken name and have people
> willing to play with it just reroll their kernel/boot system.

Ah, cool then! If it eselect thing implemented; something like news entry
on migration would educate those like me not to be that scared.

-- 

  Sergei

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] eselect init

[Matthew Thode]

[-- Attachment #1: Type: text/plain, Size: 622 bytes --]

On 05/25/13 05:25, Peter Stuge wrote:
> Luca Barbato wrote:
>> - init gets effectively switched only at boot/reboot
> 
> Please not on reboot, because an unclean shutdown shouldn't leave the
> system in limbo.
> 
> On boot could work, except that it does add more steps (= more
> fragility) to the boot process, which I think everyone wants to
> avoid.
> 
> I would actually expect the change to take effect immediately.
> 
> 
> //Peter
> 
the final action before / is remouted ro at shutdown would make sense to
me.  It's either that or first action at boot.

-- 
-- Matthew Thode (prometheanfire)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] eselect init

[J. Roeleveld]

On Sat, May 25, 2013 15:38, Tom Wijsman wrote:
> On Sat, 25 May 2013 11:54:48 +0200
> Luca Barbato <lu_zero@gentoo.org> wrote:
>
> <SNIPPED>
> there's one option we forget about
> here though, EFI users can build a second smaller minimally adjusted
> defconfig kernel that ends up loading the default init system if they
> wish to repair their system without chrooting.

Good suggestion, especially as I am trying out EFI-boot on one of my
machines with intention to keep it on EFI if it works.

> So, please see the /sbin/einit suggestion in Bug 465236 at Comment 34
> at https://bugs.gentoo.org/show_bug.cgi?id=465236#c34 which documents a
> sane alternative that allows users to load the default init system of
> Gentoo through their boot loader if they wish to do. This suggestion
> doesn't kill the eselect approach, but goes side-by-side with it; it
> effectively just names it /sbin/einit instead of /sbin/init to keep the
> default /sbin/init around. Another advantage is that users that don't
> want extra complexity as they don't want to compare or switch init
> systems will not get extra complexity added to their system.

I was thinking of a "default" option in the "eselect init" part that would
remove "init=/sbin/einit" from the kernel boot parameters.
Not sure how that would be best achieved as a lot (most?) users will have
more then one boot-option in their grub(2)/lilo config.

>> - /sbin/init (or whatever linux currently calls by default with top
>> priority)
>
> Correct as far as I recall from patching that part of boot in the past.

I don't have "init=" set on my machines and it seems to start /sbin/init.
So that should be correct.

>> should be either a symlink to the actual implementation or a
>> wrapper such as our gcc one.
>
> Wrapper sounds more safe to me since you allow more logic to be
> incorporated and aren't to restricted in what you can do with it early
> on, on the other hand a symlink would be a much more clean approach if
> you don't need more logic than just the symlink; although I'm not sure
> if the kernel loves a symlink for /sbin/init, haven't looked at that...

+1 for wrapper, from my understanding, symlinks for init-systems can't be
altered on a running system without risking strange behaviour.

>> eselect init
>> must keep track of the current active init and make sure the current
>> init configuration is used till the system reboots
>
> When we kick off the right init system at boot, we probably don't need
> to keep track of it separately; or at least not call eselect for that.
>
> Sounds like we would have two files like 'current_init' and 'boot_init'
> and `eselect init ...` would update 'boot_init'. Then, the first `init`
> invocation on boot would update 'current_init' with the value of
> boot_init; latter `init` invocations can then read out 'current_init',
> which is not to be touched by `eselect init ...`.

With a case-statement in the wrapper script to handle the different
init-systems?
How will the stop/start part of services/init-scripts/... be done?
I am assuming that should be for the user to keep in mind, but will it be
possible to add something that will make init.d-scripts not work when
systemd is running and unit-files not work when systemd is not running?

From what I understand, the tools for the different init-systems will end
up being installed simultaneously.

>> hooks on reboot are still needed for more complex ones.
>
> Which complex cases would these hooks be needed on?

I think one of these would be the stopping/starting of services (see above)

>> - 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)
>
> The /sbin/einit approach that I linked near the start would help here.
>
>> # 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.
>
> Can we please keep information that may provoke a comparison off the ML?
>
> I'll give a neutral objective response why the init system doesn't
> matter for this, as I'm tired of seeing people sneak in data points
> like this. In your case it's intended to be good, but it can catch
> other people off guard that don't care to stay on topic.
>
> [[ Please avoid responding to this part of my mail, don't go OT. ]]

<SNIPPED part about boot times>
I agree with the general statement here.

[[ Below is my ONLY remark on that, please feel free to mentally paste it
as a response any email trying to explain why it's important to reduce the
boottime ]]

Boot times can be optimized for most init-systems.
On most of my machines, I really don't care if the boot time is 2 seconds
or 2 minutes. They get started once and then they stay on till they are
not needed anymore. As long as boot-time isn't too much longer then it
takes me to get my coffee from the kitchen, it does not matter :)

--
Joost Roeleveld

Re: [gentoo-dev] eselect init

[Chí-Thanh Christopher Nguyễn]

Sergei Trofimovich schrieb:
> I guess EFI allows you to set bootargs via EFI UI.

If you have an EFI shell, then you can pass additional kernel command line
parameters via that. Passing parameters via the UI is not possible with any
of the UEFI systems that I have come across.


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] eselect init

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 3951 bytes --]

On Sat, 25 May 2013 21:09:47 +0200
"J. Roeleveld" <joost@antarean.org> wrote:

> I was thinking of a "default" option in the "eselect init" part that
> would remove "init=/sbin/einit" from the kernel boot parameters.

With the different boot loaders, it's not easy to do this consistently
everywhere; lilo != grub != grub2 != .config with EFI. While you can
support all syntaxes around there, you also need to take into account
that there are multiple entries and not all entries relate to Gentoo.

Or in the EFI use case the user may have an entry that explicitly has a
different init value or no init value at all. It's also not only about
removing init= but also about adding it again. I probably forget
crucial details, but you can guess the complexity this brings.

> Not sure how that would be best achieved as a lot (most?) users will
> have more then one boot-option in their grub(2)/lilo config.

Seems I skipped this paragraph, I've expanded the thoughts behind this
above for more completeness; I don't think this should be achieved.

> I don't have "init=" set on my machines and it seems to
> start /sbin/init. So that should be correct.

Ah yeah, a quick `ps axjf | grep bin/[i]nit` indeed confirms that.
 
> +1 for wrapper, from my understanding, symlinks for init-systems
> can't be altered on a running system without risking strange
> behaviour.

Exactly...

 # shutdown -h now

The system is going down for system halt NOW!s/1) (Sat May 25 21:25:41
2013): Excess arguments.
 
> >> eselect init
> >> must keep track of the current active init and make sure the
> >> current init configuration is used till the system reboots
> >
> > When we kick off the right init system at boot, [SNIP]
> 
> With a case-statement in the wrapper script to handle the different
> init-systems?

I think so.

> How will the stop/start part of services/init-scripts/... be done?

Not sure what you mean here; if you keep init function the same as the
init you boot with, this should continue to work.

> I am assuming that should be for the user to keep in mind, but will
> it be possible to add something that will make init.d-scripts not
> work when systemd is running and unit-files not work when systemd is
> not running?

They currently just bail out with bogus errors as far as I am aware.

 # /etc/init.d/ntpd start
ntpd             | * WARNING: ntpd is already starting
 # /etc/init.d/ntpd stop
ntpd             | * ERROR: ntpd stopped by something else
 
> From what I understand, the tools for the different init-systems will
> end up being installed simultaneously.

Correct, I don't think it makes sense to switch between things that
aren't installed; eselect historically only lists options that are
installed, and I think it should be kept this way.

> >> hooks on reboot are still needed for more complex ones.
> >
> > Which complex cases would these hooks be needed on?
> 
> I think one of these would be the stopping/starting of services (see
> above)

No, if you keep the init system the same as the one you boot with there
should be no problems.

> [[ Below is my ONLY remark on that, please feel free to mentally
> paste it as a response any email trying to explain why it's important
> to reduce the boottime ]]

My intention was not to advocate optimizing boot times; as a kernel
maintainer / developer I need to test new releases, run git bisects, do
Nouveau reclocking work. I really need this, the average person that
keeps his PC running, not so much; I care for it because I can't wait 2
minutes, not because I think it's shiny to have such a short boot...

PS: I'm also a mobile laptop user that no longer has a battery. :/

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] eselect init

[Alex Xu]

[-- Attachment #1: Type: text/plain, Size: 1022 bytes --]

On 25/05/13 03:55 PM, Tom Wijsman wrote:
>> > I don't have "init=" set on my machines and it seems to
>> > start /sbin/init. So that should be correct.
> Ah yeah, a quick `ps axjf | grep bin/[i]nit` indeed confirms that.
>  

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/init/main.c?id=v3.9#n820

> 	/*
> 	 * We try each of these until one succeeds.
> 	 *
> 	 * The Bourne shell can be used instead of init if we are
> 	 * trying to recover a really broken machine.
> 	 */
> 	if (execute_command) {
> 		if (!run_init_process(execute_command))
> 			return 0;
> 		printk(KERN_WARNING "Failed to execute %s.  Attempting "
> 					"defaults...\n", execute_command);
> 	}
> 	if (!run_init_process("/sbin/init") ||
> 	    !run_init_process("/etc/init") ||
> 	    !run_init_process("/bin/init") ||
> 	    !run_init_process("/bin/sh"))
> 		return 0;
> 
> 	panic("No init found.  Try passing init= option to kernel. "
> 	      "See Linux Documentation/init.txt for guidance.");


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] eselect init

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 976 bytes --]

On Sat, 25 May 2013 16:07:51 -0400
Alex Xu <alex_y_xu@yahoo.ca> wrote:

> On 25/05/13 03:55 PM, Tom Wijsman wrote:
> >> > I don't have "init=" set on my machines and it seems to
> >> > start /sbin/init. So that should be correct.
> > Ah yeah, a quick `ps axjf | grep bin/[i]nit` indeed confirms that.
> >  
> 
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/init/main.c?id=v3.9#n820

One quote level further I said "correct as far as I recall from
patching that part of boot in the past."; though, the above command I
gave is more reliable than looking into main.c. While /sbin/init is
listed first there that doesn't guarantee that it's effectively in use,
though we know by now that it is. Anyhow, thanks for sharing context! :)

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] eselect init

[Walter Dnes]

On Sat, May 25, 2013 at 01:57:39PM +0200, Tom Wijsman wrote
> On Sat, 25 May 2013 12:25:03 +0200
> Peter Stuge <peter@stuge.se> wrote:
> 
> > I would actually expect the change to take effect immediately.
> 
> Then how would you be able to shutdown / reboot your system in a clean
> way? The premise here is that when you boot with an init system you
> must shutdown with that same init system, you can't just start one init
> system and expect the other init system to cleanly shut down its
> services. Therefore implementing this would either be unclean or way to
> complex. 
> 
> From all the methods discussed doing it on boot sounds the most sane.

  It has to be done *VERY* early at boot, or else we're back to the
problem you described above.  It's almost like a brain surgeon operating
on himself.  Here are a couple of "outside the box" ideas that haven't
been mentioned yet...

1) boot into single mode before doing the changeover.  Both grub and
lilo support single mode boot as per...
http://www.gentoo-wiki.info/TIP_Booting_into_single_user_mode

2) have the setup/switchover mechanism built into the Gentoo minimal
install ISO.  The advantage here is that if the system ends up no longer
bootable off the harddrive, you can still boot from the ISO, chroot into
the system on the harddrive, and send emails to the gentoo-user list
asking for help <G>.

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] eselect init

[Peter Stuge]

[-- Attachment #1: Type: text/plain, Size: 1214 bytes --]

Tom Wijsman wrote:
> > I would actually expect the change to take effect immediately.
> 
> Then how would you be able to shutdown / reboot your system in a clean
> way? The premise here is that when you boot with an init system you
> must shutdown with that same init system, you can't just start one init
> system and expect the other init system to cleanly shut down its
> services.

Taking effect immediately of course does not mean that if I booted
using systemd and switched to openrc that systemd will be killed.
That idea makes absolutely no sense, it simply can not work. In
theory systemd could support execl() sysvinit and vice versa, but
I find that unlikely. The "take effect immediately" I believe that
you understood me to mean is simply impossible.

By take effect I mean that the filesystem should be modified in such
a way that the next boot will use what I selected. No further action
which could fail should be required beyond the eselect command.

Unless the eselect command has successfully modified the filesystem I
can't really know that my system will boot with what I have selected,
ie. eselect does not provide any useful feedback, because it can not.


//Peter

[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]

Re: [gentoo-dev] eselect init

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 3161 bytes --]

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

> - /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.

Increased complexity is never safer. And a wrapper means the additional
complexity gets there every boot. And considering how the discussion
goes, the wrapper will grow openrc-size in a few months...

Symlinks are simple. They're filesystem feature, they're handled
by kernel. The worst thing that could happen is symlink target
disappearing -- but then it's:

a) our responsibility to make sure to call eselect-init (if applies)
when uninstalling an init system,

b) something that would fail anyway if user did that by hand.

Linux fallback mechanism is *good enough*. You may think that fallback
to sysvinit is good but it's not. *If* I have my system set up to boot
X, at some point the config for Y will get seriously outdated.

I use systemd for a few months now, and last time I checked openrc
boots somehow. But considering the general complexity of it, I wouldn't
be much surprised if it failed in funny ways (like not being able to
handle automounts properly), caused cruft on the filesystem or even
caused *damage*.

And since you've been failing long at keeping init.d scripts simple
and reasonable, the damage potential is not something purely
theoretical.

That said, switching /sbin/init is the reasonable way. If it fails,
Linux runs /bin/sh. EOT. You broke, you fix, any way you like. Without
unexpectedly switching init system to something else just because it
was around.

> - 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.

Pointless and overcomplex. If an init system actually fails to work
when /sbin/init doesn't point to it, it is seriously broken by design.
And because of that breakage, we keep stuff like 'telinit' or 'reboot'
intact, and because of it systemd has 'pass-through' mode when linked
to /sbin/init.

> - 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)

Which means the kernel fallback will be dangerously active
as I explained before. Just don't do it.

> # 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.

You've been able to keep this thread on topic very long. Good job!

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

Re: [gentoo-dev] eselect init

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 1403 bytes --]

On Sat, 25 May 2013 21:52:28 -0400
"Walter Dnes" <waltdnes@waltdnes.org> wrote:

> On Sat, May 25, 2013 at 01:57:39PM +0200, Tom Wijsman wrote
> It has to be done *VERY* early at boot, or else we're back to the
> problem you described above.

Not sure what you mean with very early, you don't really have control
over this anyway; the earliest point at which you can reliably do this
is to turning init itself into a wrapper.

> It's almost like a brain surgeon operating on himself.

That's if externally you turn it into a symlink, not with a wrapper.

> 1) boot into single mode before doing the changeover.  Both grub and
> lilo support single mode boot as per...
> http://www.gentoo-wiki.info/TIP_Booting_into_single_user_mode

And EFI? This sounds a bit of an overkill. What's wrong with a wrapper?

> 2) have the setup/switchover mechanism built into the Gentoo minimal
> install ISO.  The advantage here is that if the system ends up no
> longer bootable off the harddrive, you can still boot from the ISO,
> chroot into the system on the harddrive, and send emails to the
> gentoo-user list asking for help <G>.

Users can already use eselect in their chroot.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] eselect init

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 1310 bytes --]

On Sun, 26 May 2013 04:02:56 +0200
Peter Stuge <peter@stuge.se> wrote:

> By take effect I mean that the filesystem should be modified in such
> a way that the next boot will use what I selected. No further action
> which could fail should be required beyond the eselect command.
> 
> Unless the eselect command has successfully modified the filesystem I
> can't really know that my system will boot with what I have selected,
> ie. eselect does not provide any useful feedback, because it can not.

That's exactly what I've described in another mail in another subthread.

http://thread.gmane.org/gmane.linux.gentoo.devel/85778/focus=85789

Snippet of what I said:

> Sounds like we would have two files like 'current_init' and
> 'boot_init' and `eselect init ...` would update 'boot_init'. Then,
> the first `init` invocation on boot would update 'current_init' with
> the value of 'boot_init'; latter `init` invocations can then read out
> 'current_init', which is not to be touched by `eselect init ...`.

This assumes that you would be working with a wrapper, not a symlink.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] eselect init

[Robert David]

On Sun, 26 May 2013 08:43:32 +0200
Michał Górny <mgorny@gentoo.org> wrote:

> On Sat, 25 May 2013 11:54:48 +0200
> Luca Barbato <lu_zero@gentoo.org> wrote:
> 
> > - /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.
> 
> Increased complexity is never safer. And a wrapper means the
> additional complexity gets there every boot. And considering how the
> discussion goes, the wrapper will grow openrc-size in a few months...
> 
> Symlinks are simple. They're filesystem feature, they're handled
> by kernel. The worst thing that could happen is symlink target
> disappearing -- but then it's:
> 
> a) our responsibility to make sure to call eselect-init (if applies)
> when uninstalling an init system,
> 
> b) something that would fail anyway if user did that by hand.
> 
> Linux fallback mechanism is *good enough*. You may think that fallback
> to sysvinit is good but it's not. *If* I have my system set up to boot
> X, at some point the config for Y will get seriously outdated.
> 
> I use systemd for a few months now, and last time I checked openrc
> boots somehow. But considering the general complexity of it, I
> wouldn't be much surprised if it failed in funny ways (like not being
> able to handle automounts properly), caused cruft on the filesystem
> or even caused *damage*.
> 
> And since you've been failing long at keeping init.d scripts simple
> and reasonable, the damage potential is not something purely
> theoretical.
> 
> That said, switching /sbin/init is the reasonable way. If it fails,
> Linux runs /bin/sh. EOT. You broke, you fix, any way you like. Without
> unexpectedly switching init system to something else just because it
> was around.

I agree with this. But changing symlinks is not as easy on running
system (since it can cause inconsistence during rebooot). I think that
safest way not using wrapper is to stop all services and keep only
mounted /, than change things (symlinks,configuration update) and
reboot. 

Thus this "eselect init" will let the user confirm and then trigger
reboot. I do not think that users will change init all the time, thus
make it better safe and more complex in this change is better than
check and wrap in all the boots.

Otherwise interesting is preinit handler in OpenWrt:
http://wiki.openwrt.org/doc/techref/process.boot
http://wiki.openwrt.org/doc/howto/notuci.config#etcpreinit
http://wiki.openwrt.org/doc/techref/preinit_mount

Robert.

> 
> > - 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.
> 
> Pointless and overcomplex. If an init system actually fails to work
> when /sbin/init doesn't point to it, it is seriously broken by design.
> And because of that breakage, we keep stuff like 'telinit' or 'reboot'
> intact, and because of it systemd has 'pass-through' mode when linked
> to /sbin/init.
> 
> > - 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)
> 
> Which means the kernel fallback will be dangerously active
> as I explained before. Just don't do it.
> 
> > # 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.
> 
> You've been able to keep this thread on topic very long. Good job!
> 

Re: [gentoo-dev] eselect init

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 3332 bytes --]

On Sun, 26 May 2013 10:58:23 +0200
Robert David <robert.david.public@gmail.com> wrote:

> On Sun, 26 May 2013 08:43:32 +0200
> Michał Górny <mgorny@gentoo.org> wrote:
> 
> > On Sat, 25 May 2013 11:54:48 +0200
> > Luca Barbato <lu_zero@gentoo.org> wrote:
> > 
> > > - /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.
> > 
> > Increased complexity is never safer. And a wrapper means the
> > additional complexity gets there every boot. And considering how the
> > discussion goes, the wrapper will grow openrc-size in a few months...
> > 
> > Symlinks are simple. They're filesystem feature, they're handled
> > by kernel. The worst thing that could happen is symlink target
> > disappearing -- but then it's:
> > 
> > a) our responsibility to make sure to call eselect-init (if applies)
> > when uninstalling an init system,
> > 
> > b) something that would fail anyway if user did that by hand.
> > 
> > Linux fallback mechanism is *good enough*. You may think that fallback
> > to sysvinit is good but it's not. *If* I have my system set up to boot
> > X, at some point the config for Y will get seriously outdated.
> > 
> > I use systemd for a few months now, and last time I checked openrc
> > boots somehow. But considering the general complexity of it, I
> > wouldn't be much surprised if it failed in funny ways (like not being
> > able to handle automounts properly), caused cruft on the filesystem
> > or even caused *damage*.
> > 
> > And since you've been failing long at keeping init.d scripts simple
> > and reasonable, the damage potential is not something purely
> > theoretical.
> > 
> > That said, switching /sbin/init is the reasonable way. If it fails,
> > Linux runs /bin/sh. EOT. You broke, you fix, any way you like. Without
> > unexpectedly switching init system to something else just because it
> > was around.
> 
> I agree with this. But changing symlinks is not as easy on running
> system (since it can cause inconsistence during rebooot).

It is *easy*.

  ln -s /sbin/newinit /sbin/init.new
  mv /sbin/init.new /sbin/init

Easy and atomic. The inconsistency potential is similar to one given by
init upgrades. Yet we don't do anything magical to defer init upgrade
until reboot, and that's why the upgrades go smoothly.

> I think that safest way not using wrapper is to stop all services
> and keep only mounted /, than change things (symlinks,configuration
> update) and reboot. 

This can be done two ways.

One is hacking into init (RC) reboot procedure. It's fragile, it needs
to be fit into the right moment and I'm not sure if all inits will
handle this without actually needing to patch the code. And in the end,
the init gets replaced before init stops working anyway.

The other is going beside init and directly into the reboot. This
either requires kernel hacking (please don't!) or hacking the reboot
procedure in init code. And of course remounting R/W, then writing,
remounting back...

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

Re: [gentoo-dev] eselect init

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 1652 bytes --]

On Sun, 26 May 2013 10:58:23 +0200
Robert David <robert.david.public@gmail.com> wrote:

> > Increased complexity is never safer. And a wrapper means the
> > additional complexity gets there every boot. And considering how
> > the discussion goes, the wrapper will grow openrc-size in a few
> > months..
>
> I agree with this. But changing symlinks is not as easy on running
> system (since it can cause inconsistence during rebooot). I think that
> safest way not using wrapper is to stop all services and keep only
> mounted /, than change things (symlinks,configuration update) and
> reboot. 
> 
> Thus this "eselect init" will let the user confirm and then trigger
> reboot. I do not think that users will change init all the time, thus
> make it better safe and more complex in this change is better than
> check and wrap in all the boots.
> 
> Otherwise interesting is preinit handler in OpenWrt:
> http://wiki.openwrt.org/doc/techref/process.boot
> http://wiki.openwrt.org/doc/howto/notuci.config#etcpreinit
> http://wiki.openwrt.org/doc/techref/preinit_mount

In other words, if you go for the symlink approach you're just moving
complexity to your system instead of into the boot; I don't see why a
wrapper would grow to openrc size, that's just a bold exaggeration.

I'd rather have a clean wrapper that just works than an unclean way to
cover the reboot madness that comes along; forcing a reboot, really?

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] eselect init

[Robert David]

On Sun, 26 May 2013 11:20:25 +0200
Michał Górny <mgorny@gentoo.org> wrote:

> On Sun, 26 May 2013 10:58:23 +0200
> Robert David <robert.david.public@gmail.com> wrote:
> 
> > On Sun, 26 May 2013 08:43:32 +0200
> > Michał Górny <mgorny@gentoo.org> wrote:
> > 
> > > On Sat, 25 May 2013 11:54:48 +0200
> > > Luca Barbato <lu_zero@gentoo.org> wrote:
> > > 
> > > > - /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.
> > > 
> > > Increased complexity is never safer. And a wrapper means the
> > > additional complexity gets there every boot. And considering how
> > > the discussion goes, the wrapper will grow openrc-size in a few
> > > months...
> > > 
> > > Symlinks are simple. They're filesystem feature, they're handled
> > > by kernel. The worst thing that could happen is symlink target
> > > disappearing -- but then it's:
> > > 
> > > a) our responsibility to make sure to call eselect-init (if
> > > applies) when uninstalling an init system,
> > > 
> > > b) something that would fail anyway if user did that by hand.
> > > 
> > > Linux fallback mechanism is *good enough*. You may think that
> > > fallback to sysvinit is good but it's not. *If* I have my system
> > > set up to boot X, at some point the config for Y will get
> > > seriously outdated.
> > > 
> > > I use systemd for a few months now, and last time I checked openrc
> > > boots somehow. But considering the general complexity of it, I
> > > wouldn't be much surprised if it failed in funny ways (like not
> > > being able to handle automounts properly), caused cruft on the
> > > filesystem or even caused *damage*.
> > > 
> > > And since you've been failing long at keeping init.d scripts
> > > simple and reasonable, the damage potential is not something
> > > purely theoretical.
> > > 
> > > That said, switching /sbin/init is the reasonable way. If it
> > > fails, Linux runs /bin/sh. EOT. You broke, you fix, any way you
> > > like. Without unexpectedly switching init system to something
> > > else just because it was around.
> > 
> > I agree with this. But changing symlinks is not as easy on running
> > system (since it can cause inconsistence during rebooot).
> 
> It is *easy*.
> 
>   ln -s /sbin/newinit /sbin/init.new
>   mv /sbin/init.new /sbin/init
> 
> Easy and atomic. The inconsistency potential is similar to one given
> by init upgrades. Yet we don't do anything magical to defer init
> upgrade until reboot, and that's why the upgrades go smoothly.

You are right. Even though, it is highly appreciated to inform user on
urgent reboot. 

> 
> > I think that safest way not using wrapper is to stop all services
> > and keep only mounted /, than change things (symlinks,configuration
> > update) and reboot. 
> 
> This can be done two ways.
> 
> One is hacking into init (RC) reboot procedure. It's fragile, it needs
> to be fit into the right moment and I'm not sure if all inits will
> handle this without actually needing to patch the code. And in the
> end, the init gets replaced before init stops working anyway.
> 
> The other is going beside init and directly into the reboot. This
> either requires kernel hacking (please don't!) or hacking the reboot
> procedure in init code. And of course remounting R/W, then writing,
> remounting back...
> 

I did not say it will be easy. Still I think there is space to
investigate deeply how to handle that more cleanly (eg: onetime late
shutdonw initscript/unit). No one will be hacking kernel:)

Robert.

Re: [gentoo-dev] eselect init

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 2299 bytes --]

On Sun, 26 May 2013 11:20:25 +0200
Michał Górny <mgorny@gentoo.org> wrote:

> It is *easy*.
> 
>   ln -s /sbin/newinit /sbin/init.new
>   mv /sbin/init.new /sbin/init
>
> Easy and atomic. The inconsistency potential is similar to one given
> by init upgrades. Yet we don't do anything magical to defer init
> upgrade until reboot, and that's why the upgrades go smoothly.

Easy isn't always good. It's not atomic since you can't reboot and
because of that I wouldn't call it smooth either.

> > I think that safest way not using wrapper is to stop all services
> > and keep only mounted /, than change things (symlinks,configuration
> > update) and reboot. 
> 
> This can be done two ways.
> 
> One is hacking into init (RC) reboot procedure. It's fragile, it needs
> to be fit into the right moment and I'm not sure if all inits will
> handle this without actually needing to patch the code. And in the
> end, the init gets replaced before init stops working anyway.

You're making things way more complex than a wrapper would do. I'm not
a fan of using the words "hacking", "fragile" and "not sure" for
selling an approach; so, why were you suggesting the symlink approach?

> The other is going beside init and directly into the reboot. This
> either requires kernel hacking (please don't!)

Yes, please don't, it's against our general objectives.

http://www.gentoo.org/proj/en/kernel/maintenance.xml#doc_chap3

Furthermore, even if you would consider this then you can't be
guaranteed that everyone uses genpatches; and I don't think we would
want this in the eclass either, its users will very likely object.

> or hacking the reboot procedure in init code. And of course
> remounting R/W, then writing, remounting back...

I don't think patching them is a reliable approach; it steps away from
being loosely coupled and therefore makes it harder to understand, you
are changing multiple things at once and introduce a maintenance burden.

With a wrapper, you don't have a problem with any of those...

Loose coupling, high cohesion.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] eselect init

[Luca Barbato]

On 5/26/13 8:43 AM, Michał Górny wrote:
> On Sat, 25 May 2013 11:54:48 +0200
> Luca Barbato <lu_zero@gentoo.org> wrote:
>
>> - /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.
>
> Increased complexity is never safer. And a wrapper means the additional
> complexity gets there every boot. And considering how the discussion
> goes, the wrapper will grow openrc-size in a few months...

Openrc is small, but the wrapper really needs to know which is which and 
worst case switch inittab.

> Symlinks are simple. They're filesystem feature, they're handled
> by kernel. The worst thing that could happen is symlink target
> disappearing -- but then it's:
>
> a) our responsibility to make sure to call eselect-init (if applies)
> when uninstalling an init system,
>
> b) something that would fail anyway if user did that by hand.
>
> Linux fallback mechanism is *good enough*. You may think that fallback
> to sysvinit is good but it's not. *If* I have my system set up to boot
> X, at some point the config for Y will get seriously outdated.

Have you tested it? Do you know what is the reaction of do_exec on a 
dangling symlink?

> I use systemd for a few months now, and last time I checked openrc
> boots somehow. But considering the general complexity of it, I wouldn't
> be much surprised if it failed in funny ways (like not being able to
> handle automounts properly), caused cruft on the filesystem or even
> caused *damage*.

openrc is *simpler* much *simpler* than systemd, stop with that.

> And since you've been failing long at keeping init.d scripts simple
> and reasonable, the damage potential is not something purely
> theoretical.

wc -l is a good answer to your concern. Some scripts have to be 
simplified, that's a given (e.g. Fabio pointed the lvm one can be 
improved a lot) but it isn't the case for most of them.

> Pointless and overcomplex. If an init system actually fails to work
> when /sbin/init doesn't point to it, it is seriously broken by design.
> And because of that breakage, we keep stuff like 'telinit' or 'reboot'
> intact, and because of it systemd has 'pass-through' mode when linked
> to /sbin/init.

Check your facts, systemd either understands a flavour of inittab or the 
other or none at all.

> Which means the kernel fallback will be dangerously active
> as I explained before. Just don't do it.

It is not dangerous beside for those that have an inittab with rm -fR /

lu

Re: [gentoo-dev] eselect init

[Robert David]

On Sun, 26 May 2013 11:21:25 +0200
Tom Wijsman <TomWij@gentoo.org> wrote:

> On Sun, 26 May 2013 10:58:23 +0200
> Robert David <robert.david.public@gmail.com> wrote:
> 
> > > Increased complexity is never safer. And a wrapper means the
> > > additional complexity gets there every boot. And considering how
> > > the discussion goes, the wrapper will grow openrc-size in a few
> > > months..
> >
> > I agree with this. But changing symlinks is not as easy on running
> > system (since it can cause inconsistence during rebooot). I think
> > that safest way not using wrapper is to stop all services and keep
> > only mounted /, than change things (symlinks,configuration update)
> > and reboot. 
> > 
> > Thus this "eselect init" will let the user confirm and then trigger
> > reboot. I do not think that users will change init all the time,
> > thus make it better safe and more complex in this change is better
> > than check and wrap in all the boots.
> > 
> > Otherwise interesting is preinit handler in OpenWrt:
> > http://wiki.openwrt.org/doc/techref/process.boot
> > http://wiki.openwrt.org/doc/howto/notuci.config#etcpreinit
> > http://wiki.openwrt.org/doc/techref/preinit_mount
> 
> In other words, if you go for the symlink approach you're just moving
> complexity to your system instead of into the boot; I don't see why a
> wrapper would grow to openrc size, that's just a bold exaggeration.

Newer say that wrapper will grow openrc size, and also dont know why it
would be bad. The point is somewhere else. I really dont know how many
user will switch inits and how many of them will do this regularly.
But the wrapper will be executed every boot. So even a tiny mistake
can produce booting problems even for those who did not wanted to
change anything in init process. On the other hand mistake in some
system process will affect only those who would actually switching. It
is only calculation of possible risks.

I also did not say it must be done the reboot way I mentioned, this is
only and different point what can be though about. 

> 
> I'd rather have a clean wrapper that just works than an unclean way to
> cover the reboot madness that comes along; forcing a reboot, really?
> 

I do not see point not forcing reboot when I'm switching init, or let
say suggesting. When you update your kernel config, rebuild and
install you also can stay working, but you have to be prepared to have
nonworking modules that was not inserted before.

Re: [gentoo-dev] eselect init

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1578 bytes --]

On Sun, 26 May 2013 11:45:38 +0200
Tom Wijsman <TomWij@gentoo.org> wrote:

> On Sun, 26 May 2013 11:20:25 +0200
> Michał Górny <mgorny@gentoo.org> wrote:
> 
> > It is *easy*.
> > 
> >   ln -s /sbin/newinit /sbin/init.new
> >   mv /sbin/init.new /sbin/init
> >
> > Easy and atomic. The inconsistency potential is similar to one given
> > by init upgrades. Yet we don't do anything magical to defer init
> > upgrade until reboot, and that's why the upgrades go smoothly.
> 
> Easy isn't always good. It's not atomic since you can't reboot and
> because of that I wouldn't call it smooth either.

Can't you? How come?

> > > I think that safest way not using wrapper is to stop all services
> > > and keep only mounted /, than change things (symlinks,configuration
> > > update) and reboot. 
> > 
> > This can be done two ways.
> > 
> > One is hacking into init (RC) reboot procedure. It's fragile, it needs
> > to be fit into the right moment and I'm not sure if all inits will
> > handle this without actually needing to patch the code. And in the
> > end, the init gets replaced before init stops working anyway.
> 
> You're making things way more complex than a wrapper would do. I'm not
> a fan of using the words "hacking", "fragile" and "not sure" for
> selling an approach; so, why were you suggesting the symlink approach?

Don't mix the two mails. I am showing how fragile the solution
suggested by Robert is. While you seem to be replying to every mail
possible to repeatedly advocate your idea.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

Re: [gentoo-dev] eselect init

[Rich Freeman]

On Sun, May 26, 2013 at 6:01 AM, Robert David
<robert.david.public@gmail.com> wrote:
> Newer say that wrapper will grow openrc size, and also dont know why it
> would be bad. The point is somewhere else. I really dont know how many
> user will switch inits and how many of them will do this regularly.
> But the wrapper will be executed every boot. So even a tiny mistake
> can produce booting problems even for those who did not wanted to
> change anything in init process. On the other hand mistake in some
> system process will affect only those who would actually switching. It
> is only calculation of possible risks.

You can have your cake and eat it too.  Just don't call the wrapper
init.  Somebody else already suggested leaving the init
implementations alone and stick the wrapper in a new binary that would
need to be enabled specifically in the boot/kernel configuration.

So if grub points to /sbin/einit then it runs the wrapper.  If it just
points to openrc/systemd then it directly executes them and bypasses
the wrapper.  That means that this whole thing only impacts those who
install it, which is the best way to implement something experimental
in the first place.

Granted, I don't know the limitations of the EFI bootloaders that are
out there, but this still seems like something better solved via grub
configuration.  When I implemented systemd in one of my VMs I just
added a grub line to boot back to openrc.

Rich

Re: [gentoo-dev] eselect init

[Chí-Thanh Christopher Nguyễn]

Rich Freeman schrieb:
> Granted, I don't know the limitations of the EFI bootloaders that are
> out there, but this still seems like something better solved via grub
> configuration.  When I implemented systemd in one of my VMs I just
> added a grub line to boot back to openrc.

EFI stub kernels just need init=/sbin/<wrappername> in CONFIG_CMDLINE in
order to use the wrapper.
However, in case of breakage in the wrapper, you would need to boot a
fallback kernel or access the EFI shell (not all UEFI implementations allow
the latter).


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] eselect init

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 1895 bytes --]

On Sun, 26 May 2013 11:55:24 +0200
Luca Barbato <lu_zero@gentoo.org> wrote:

> Openrc is small, but the wrapper really needs to know which is which

It doesn't need to, it just needs to kick off the right init process.

If you think it does need to, please elaborate.

> and worst case switch inittab.

You could keep this kind of logic outside the wrapper, specific to the
init system; such that the wrapper and therefore the shared part of the
boot regardless of init system stays as small as possible.

This could be even something you could let the eselect script change,
the inittab is only needed at boot time as far as I can recall.

> openrc is *simpler* much *simpler* than systemd, stop with that.

Simpler is not necessarily better, stop with flames you don't back up;
and if you do back them up, then please keep it outside of the ML.

You're contributing to sidetracking your own discussion.

> > And since you've been failing long at keeping init.d scripts simple
> > and reasonable, the damage potential is not something purely
> > theoretical.
> 
> wc -l is a good answer to your concern. Some scripts have to be 
> simplified, that's a given (e.g. Fabio pointed the lvm one can be 
> improved a lot) but it isn't the case for most of them.

If we're really going to have this discussion and you really care
about wc -l, maybe we should compress init scripts and service units;
perhaps we could then combine them into one file to spare inodes too.

Joke aside; the other reason, maintainability, is a good one.

> It is not dangerous beside for those that have an inittab with rm
> -fR /

Root preservation should make this safe.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] eselect init

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 5524 bytes --]

On Sun, 26 May 2013 11:55:24 +0200
Luca Barbato <lu_zero@gentoo.org> wrote:

> On 5/26/13 8:43 AM, Michał Górny wrote:
> > On Sat, 25 May 2013 11:54:48 +0200
> > Luca Barbato <lu_zero@gentoo.org> wrote:
> >
> >> - /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.
> >
> > Increased complexity is never safer. And a wrapper means the additional
> > complexity gets there every boot. And considering how the discussion
> > goes, the wrapper will grow openrc-size in a few months...
> 
> Openrc is small, but the wrapper really needs to know which is which and 
> worst case switch inittab.

Switch inittab? Now you added really dangerous behavior to the wrapper
code. I can hardly even express this in words.

You are telling me that a wrapper, a thing that gets executed *every*
boot needs to do some random magic to know which init system was in use
and which one is supposed to be in use, and then conditionally move
around configuration files necessary for it to run. This is just
*INSANE*.

Did anyone notice already that moving stuff around actually requires
rootfs mounted R/W? Which means the wrapper needs to repeat a fair bit
of init/RC work.

And what will happen if moving the files fail? What if half of
configuration belongs to old init, and half to new? And it all happens
automagically on boot, on an incomplete system without any console
started, without Internet connection established and without any
serious mean of help.

> > Symlinks are simple. They're filesystem feature, they're handled
> > by kernel. The worst thing that could happen is symlink target
> > disappearing -- but then it's:
> >
> > a) our responsibility to make sure to call eselect-init (if applies)
> > when uninstalling an init system,
> >
> > b) something that would fail anyway if user did that by hand.
> >
> > Linux fallback mechanism is *good enough*. You may think that fallback
> > to sysvinit is good but it's not. *If* I have my system set up to boot
> > X, at some point the config for Y will get seriously outdated.
> 
> Have you tested it? Do you know what is the reaction of do_exec on a 
> dangling symlink?

And did you? You keep repeating this and jumping straight to developing
work-arounds without even waiting for an answer. And I think William
has already spoken that the code supports it.

In any case, I've just tested it. Replaced /sbin/init with a dangling
symlink, rebooted with init=/sbin/init and the kernel ran /bin/sh
as a fallback.

> > I use systemd for a few months now, and last time I checked openrc
> > boots somehow. But considering the general complexity of it, I wouldn't
> > be much surprised if it failed in funny ways (like not being able to
> > handle automounts properly), caused cruft on the filesystem or even
> > caused *damage*.
> 
> openrc is *simpler* much *simpler* than systemd, stop with that.

OpenRC relies on a few layers of various tools plus a lot of init
scripts written by different people. Those init scripts include tasks
such as parsing configuration files (well, more of grepping them)
and manipulating runtime files. The complexity of OpenRC is the sum
of all that.

To make this point cleaner to you: what if the fallback ran systemd
instead? As in, init gets broken somehow and kernel falls back to
starting systemd on your unprepared OpenRC system. Is this a behavior
you'd like?

What I'm telling is: if user uses A as init system (and wanted to switch
to B), last thing he'd expect is C being started. Configuration for
OpenRC may be long unmaintained, may start services which are not
supposed to be started anymore and so on.

> > And since you've been failing long at keeping init.d scripts simple
> > and reasonable, the damage potential is not something purely
> > theoretical.
> 
> wc -l is a good answer to your concern. Some scripts have to be 
> simplified, that's a given (e.g. Fabio pointed the lvm one can be 
> improved a lot) but it isn't the case for most of them.

We're not talking about percentages here. A *single* fragile script is
enough to cause trouble. Ten good ones won't revert it.

> > Pointless and overcomplex. If an init system actually fails to work
> > when /sbin/init doesn't point to it, it is seriously broken by design.
> > And because of that breakage, we keep stuff like 'telinit' or 'reboot'
> > intact, and because of it systemd has 'pass-through' mode when linked
> > to /sbin/init.
> 
> Check your facts, systemd either understands a flavour of inittab or the 
> other or none at all.

What are you talking about now? I was just saying that *if* you
link /sbin/init to systemd, and you're running sysvinit, 'init foo'
will be passed through to telinit.

But now I see that I was wrong and it actually happened when
'systemctl' was symlinked to 'init'. Nevermind then.

In any case, keeping all the tools like 'telinit' should be *enough* to
keep the current init running and rebooting.

> > Which means the kernel fallback will be dangerously active
> > as I explained before. Just don't do it.
> 
> It is not dangerous beside for those that have an inittab with rm -fR /

n/c

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

Re: [gentoo-dev] eselect init

[hasufell]

On 05/26/2013 12:11 PM, Rich Freeman wrote:
> That means that this whole thing only impacts those who
> install it, which is the best way to implement something experimental
> in the first place.
> 

+1

I and probably a lot of other people have zero interest in this
approach, so we should not be bothered with testing/configuring/using it.

Re: [gentoo-dev] eselect init

[Luca Barbato]

On 5/26/13 12:57 PM, Michał Górny wrote:
> On Sun, 26 May 2013 11:55:24 +0200
> Luca Barbato <lu_zero@gentoo.org> wrote:
>
>> On 5/26/13 8:43 AM, Michał Górny wrote:
>>> On Sat, 25 May 2013 11:54:48 +0200
>>> Luca Barbato <lu_zero@gentoo.org> wrote:
>>>
>>>> - /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.
>>>
>>> Increased complexity is never safer. And a wrapper means the additional
>>> complexity gets there every boot. And considering how the discussion
>>> goes, the wrapper will grow openrc-size in a few months...
>>
>> Openrc is small, but the wrapper really needs to know which is which and
>> worst case switch inittab.
>
> Switch inittab? Now you added really dangerous behavior to the wrapper
> code. I can hardly even express this in words.

I need it for my purpose, bb-init syntax isn't the same as sysv.

> You are telling me that a wrapper, a thing that gets executed *every*
> boot needs to do some random magic to know which init system was in use
> and which one is supposed to be in use, and then conditionally move
> around configuration files necessary for it to run. This is just
> *INSANE*.

I like to think it normal and the wrapper doesn't need to run every time 
but only when a switch had been requested. And only if you prefer doing 
the switch at boot time instead than at shutdown.

> Did anyone notice already that moving stuff around actually requires
> rootfs mounted R/W? Which means the wrapper needs to repeat a fair bit
> of init/RC work.

Noticed and known issue, I merely stated which are the options on the 
plate, keep in mind that init addons people use and we distribute do 
even more evil stuff.

> And what will happen if moving the files fail? What if half of
> configuration belongs to old init, and half to new? And it all happens
> automagically on boot, on an incomplete system without any console
> started, without Internet connection established and without any
> serious mean of help.

You can:

- consider rolling back
- drop to a shell

Nothing so terrible.

> And did you? You keep repeating this and jumping straight to developing
> work-arounds without even waiting for an answer. And I think William
> has already spoken that the code supports it.

I read the code up to do_exec, given for me it would require have a 
roundtrip to the efi shell I was hoping those proposing that would do 
that basic homework =)

> In any case, I've just tested it. Replaced /sbin/init with a dangling
> symlink, rebooted with init=/sbin/init and the kernel ran /bin/sh
> as a fallback.

That's all I wanted everybody knows, thanks for helping.

> OpenRC relies on a few layers of various tools plus a lot of init
> scripts written by different people. Those init scripts include tasks
> such as parsing configuration files (well, more of grepping them)
> and manipulating runtime files. The complexity of OpenRC is the sum
> of all that.

I read it as "as complex as the user wants".

> To make this point cleaner to you: what if the fallback ran systemd
> instead? As in, init gets broken somehow and kernel falls back to
> starting systemd on your unprepared OpenRC system. Is this a behavior
> you'd like?

I would expect any sane init would get me at least to their single mode.

> What I'm telling is: if user uses A as init system (and wanted to switch
> to B), last thing he'd expect is C being started. Configuration for
> OpenRC may be long unmaintained, may start services which are not
> supposed to be started anymore and so on.

The safest would be dropping to a shell in your scenario.

As I stated from start the "switch on boot" would work so the wrapper 
checks a switch had been requested, it knows the current init, that must 
work since worked the previous boot, the next init, that supposedly 
should work, does the pivoting, shuffling and such and the next boot it 
just hands over to the current init.

The wrapper could even install and uninstall itself.

Again, my object of interest is being able to use bb-init and runit.

> We're not talking about percentages here. A *single* fragile script is
> enough to cause trouble. Ten good ones won't revert it.

A single fragile script can be fixed I guess, which is the one you have 
in mind that is concerning?

> What are you talking about now? I was just saying that *if* you
> link /sbin/init to systemd, and you're running sysvinit, 'init foo'
> will be passed through to telinit.
>
> But now I see that I was wrong and it actually happened when
> 'systemctl' was symlinked to 'init'. Nevermind then.
>
> In any case, keeping all the tools like 'telinit' should be *enough* to
> keep the current init running and rebooting.

You are focused on systemd, I'm focused on bb-init among the rest, it 
uses a different syntax for the inittab, so if you want to switch from 
one or another you either prepare a least-action script that switch the 
inittab on reboot or a first-action script that does that on boot.

For your needs probably just pivoting a symlink should work almost fine, 
as long your stay sysvinit compatible, yet doing that as early init or 
as post kill-all should work better even in your case.

lu

Re: [gentoo-dev] eselect init

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 2109 bytes --]

On Sun, 26 May 2013 12:09:21 +0200
Michał Górny <mgorny@gentoo.org> wrote:

> > Easy isn't always good. It's not atomic since you can't reboot and
> > because of that I wouldn't call it smooth either.
> 
> Can't you? How come?

Because it expects the init system you boot with to be present.

> > > > I think that safest way not using wrapper is to stop all
> > > > services and keep only mounted /, than change things
> > > > (symlinks,configuration update) and reboot. 
> > > 
> > > This can be done two ways.
> > > 
> > > One is hacking into init (RC) reboot procedure. It's fragile, it
> > > needs to be fit into the right moment and I'm not sure if all
> > > inits will handle this without actually needing to patch the
> > > code. And in the end, the init gets replaced before init stops
> > > working anyway.
> > 
> > You're making things way more complex than a wrapper would do. I'm
> > not a fan of using the words "hacking", "fragile" and "not sure" for
> > selling an approach; so, why were you suggesting the symlink
> > approach?
> 
> Don't mix the two mails.

Don't read it as mixed, it is not; I take it that you agree with me as
you choose not to answer to it. If you meant to advocate your own
solution, expanding the other solutions is going to make us forget
about what you were suggesting; you're creating your own mixture.

> I am showing how fragile the solution suggested by Robert is. While
> you seem to be replying to every mail possible to repeatedly advocate
> your idea.

And I am showing how fragile your expansions to Robert's solution are;
thanks for clarifying you meant to point out its fragile, that was not
entirely clear from your response and I assumed another intention.

We are on the same line here, in fact you have replied more in this sub
thread than I did. The wrapper is not my idea; despites my advocation...

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] eselect init

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 2724 bytes --]

On Sun, 26 May 2013 12:57:42 +0200
Michał Górny <mgorny@gentoo.org> wrote:

> Switch inittab? Now you added really dangerous behavior to the wrapper
> code. I can hardly even express this in words.

It doesn't need to be in the wrapper, inittab is something read at boot
only as far as I am aware and therefore eselect can do it.

> You are telling me that a wrapper, a thing that gets executed *every*
> boot needs to do some random magic to know which init system was in
> use and which one is supposed to be in use, and then conditionally
> move around configuration files necessary for it to run. This is just
> *INSANE*.
>
> Did anyone notice already that moving stuff around actually requires
> rootfs mounted R/W? Which means the wrapper needs to repeat a fair bit
> of init/RC work.

The wrapper only needs to read stuff, I see no reason for it to write
stuff. It needs to read which init it needs to kick off, nothing more
than that; if more is needed, please elaborate in full detail.
 
> And what will happen if moving the files fail?

Which files? Since eselect would move them, we would be aware that it
failed and could possibly rollback.

> What if half of configuration belongs to old init, and half to new?

Given a rollback, I don't see this happen; unless the rollback fails...

> And it all happens automagically on boot, on an incomplete system
> without any console started, without Internet connection established
> and without any serious mean of help.

Barely anything needs to happen on boot, stop adding complexity; the
wrapper is meant to be simple, not another init system on its own.

People are having way to different ideas about the wrapper, this is not
good; I think people should start to express their ideas in documents,
same with the symlink solutions. These "everything in the wrapper,
everything on reboot" assumptions are running out of hand.

> > > I use systemd for a few months now, and last time I checked openrc
> > > boots somehow. But considering the general complexity of it, I
> > > wouldn't be much surprised if it failed in funny ways (like not
> > > being able to handle automounts properly), caused cruft on the
> > > filesystem or even caused *damage*.
> > 
> > openrc is *simpler* much *simpler* than systemd, stop with that.
> 
> [SNIP]
> 
> To make this point cleaner to you: what if the fallback ran systemd
> instead? 
> 
> [SNIP]

Why should the fallback be different from what stage3 provides?

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] eselect init

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 675 bytes --]

On Sun, 26 May 2013 13:45:43 +0200
Tom Wijsman <TomWij@gentoo.org> wrote:

> On Sun, 26 May 2013 12:09:21 +0200
> Michał Górny <mgorny@gentoo.org> wrote:
> 
> > > Easy isn't always good. It's not atomic since you can't reboot and
> > > because of that I wouldn't call it smooth either.
> > 
> > Can't you? How come?
> 
> Because it expects the init system you boot with to be present.

And it is present. It's just the symlink what differs. The symlink
should be used just to boot the init and for nothing more. The booted
init should be able to find itself.

If it isn't, it's the init's what needs to be fixed. Really.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

Re: [gentoo-dev] eselect init

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 3946 bytes --]

On Sun, 26 May 2013 13:40:03 +0200
Luca Barbato <lu_zero@gentoo.org> wrote:

> On 5/26/13 12:57 PM, Michał Górny wrote:
> > Switch inittab? Now you added really dangerous behavior to the wrapper
> > code. I can hardly even express this in words.
> 
> I need it for my purpose, bb-init syntax isn't the same as sysv.

Then you need to use a different file. Feel free to rename either
inittab but don't even think of switching files like this.

> > You are telling me that a wrapper, a thing that gets executed *every*
> > boot needs to do some random magic to know which init system was in use
> > and which one is supposed to be in use, and then conditionally move
> > around configuration files necessary for it to run. This is just
> > *INSANE*.
> 
> I like to think it normal and the wrapper doesn't need to run every time 
> but only when a switch had been requested. And only if you prefer doing 
> the switch at boot time instead than at shutdown.

Well, that makes it a bit less destructive. Though I still don't like
the idea.

> > And what will happen if moving the files fail? What if half of
> > configuration belongs to old init, and half to new? And it all happens
> > automagically on boot, on an incomplete system without any console
> > started, without Internet connection established and without any
> > serious mean of help.
> 
> You can:
> 
> - consider rolling back
> - drop to a shell
> 
> Nothing so terrible.

Sounds like an initramfs...

> > What I'm telling is: if user uses A as init system (and wanted to switch
> > to B), last thing he'd expect is C being started. Configuration for
> > OpenRC may be long unmaintained, may start services which are not
> > supposed to be started anymore and so on.
> 
> The safest would be dropping to a shell in your scenario.
> 
> As I stated from start the "switch on boot" would work so the wrapper 
> checks a switch had been requested, it knows the current init, that must 
> work since worked the previous boot, the next init, that supposedly 
> should work, does the pivoting, shuffling and such and the next boot it 
> just hands over to the current init.

It all depends on how it is implemented. If we decide not to
touch /sbin/init, then sysvinit will be the effective fallback at some
earlier or later point, depending on what will fail. This is what I
really dislike.

> > We're not talking about percentages here. A *single* fragile script is
> > enough to cause trouble. Ten good ones won't revert it.
> 
> A single fragile script can be fixed I guess, which is the one you have 
> in mind that is concerning?

You could've asked me that when I was still using OpenRC. I don't
really want to grep the 40 scripts right now, and I don't think I have
the worse cases installed here.

> > What are you talking about now? I was just saying that *if* you
> > link /sbin/init to systemd, and you're running sysvinit, 'init foo'
> > will be passed through to telinit.
> >
> > But now I see that I was wrong and it actually happened when
> > 'systemctl' was symlinked to 'init'. Nevermind then.
> >
> > In any case, keeping all the tools like 'telinit' should be *enough* to
> > keep the current init running and rebooting.
> 
> You are focused on systemd, I'm focused on bb-init among the rest, it 
> uses a different syntax for the inittab, so if you want to switch from 
> one or another you either prepare a least-action script that switch the 
> inittab on reboot or a first-action script that does that on boot.
> 
> For your needs probably just pivoting a symlink should work almost fine, 
> as long your stay sysvinit compatible, yet doing that as early init or 
> as post kill-all should work better even in your case.

Well, you're transforming a simple idea with potentially relatively
wide audience into a horror story with a single user.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

Re: [gentoo-dev] eselect init

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 2993 bytes --]

On Sun, 26 May 2013 12:01:19 +0200
Robert David <robert.david.public@gmail.com> wrote:

> Newer say that wrapper will grow openrc size, and also dont know why
> it would be bad.

That's what I'd like to know from him, I was quoting both of you,

> I really dont know how many user will switch inits and how many of
> them will do this regularly.

Users that would like to compare things, users that are bothered by one
init system and try to try an alternative one; developers that want to
test both init scripts and service units and thus need to change often,
people that would want a specific init system but haven't found out how
to switch properly to it yet. I think there are more than a hand full.

> But the wrapper will be executed every boot. So even a tiny mistake
> can produce booting problems even for those who did not wanted to
> change anything in init process.

One would properly test the wrapper, perhaps even have multiple members
of arch teams test it, before bringing this out to the user base; it's
a very critical matter and we can indeed not afford a mistake here.
That being said, once the wrapper is in place and works; I don't think
we need to touch it often, it's just a wrapper after all. Do other
wrappers, desktop files and files of similar nature we use around
Gentoo change often; I think not.

> On the other hand mistake in some system process will affect only
> those who would actually switching. It is only calculation of
> possible risks.

If you do risk assessment, you should count in all risks; that
therefore also means to take maintainability into account. See my other
mail about what it takes to step away from a loosely coupled approach.

> I also did not say it must be done the reboot way I mentioned, this is
> only and different point what can be though about. 

And we're thinking it through, I don't see why you mention this; I can
understand that you don't necessarily stand behind it though, that's OK.

> > 
> > I'd rather have a clean wrapper that just works than an unclean way
> > to cover the reboot madness that comes along; forcing a reboot,
> > really?
> > 
> 
> I do not see point not forcing reboot when I'm switching init, or let
> say suggesting. When you update your kernel config, rebuild and
> install you also can stay working, but you have to be prepared to have
> nonworking modules that was not inserted before.

My point was that with a wrapper you don't need to force this; the
modules problem is irrelevant to this discussion, I don't see any
problem in that light with the approaches we are discussing here.

PS: If this message ends up in a separate thread, it's because I'm
forwarding it from my Sent mail because there was no reply-to present.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] eselect init

[Luca Barbato]

On 5/26/13 2:08 PM, Michał Górny wrote:
> You could've asked me that when I was still using OpenRC. I don't
> really want to grep the 40 scripts right now, and I don't think I have
> the worse cases installed here.

Worth investigation, not by you, but those that loathe systemd should 
have a look and see if they could fix some.

>> For your needs probably just pivoting a symlink should work almost fine,
>> as long your stay sysvinit compatible, yet doing that as early init or
>> as post kill-all should work better even in your case.
>
> Well, you're transforming a simple idea with potentially relatively
> wide audience into a horror story with a single user.

Hopefully not =) I just stated what's the problem and the possible 
solutions. As said from start I want the whole thing to be an opt-in and 
to cause the least amount of disruption on current setups.

Patching sysvinit and bb-init to accept a "-c <filename>" would make the 
whole thing much simpler if we pick a wrapper solution for my most 
complex case.

lu

Re: [gentoo-dev] eselect init

[J. Roeleveld]

On Sat, May 25, 2013 21:55, Tom Wijsman wrote:
> On Sat, 25 May 2013 21:09:47 +0200
> "J. Roeleveld" <joost@antarean.org> wrote:
>
>> How will the stop/start part of services/init-scripts/... be done?
>
> Not sure what you mean here; if you keep init function the same as the
> init you boot with, this should continue to work.

As an example. Lets say I want to test a new init-system. To do this, I
follow the (still to be written) guide on "eselect init" and boot into
new-and-shiny-init-system.

I am still used to stopping/starting services using "/etc/init.d/<service>
start/stop"
And using the "rc" command to add/remove services from the runlevel(s).

If I then, accidentally, type "/etc/init.d/xyz start" when "xyz" hasn't
been started by any means yet. What will happen?
I would assume that openrc will try to start "xyz"?
This is, I believe, something that could cause issues as dependencies
might also try to start and I then have a service running not managed by
the "new-and-shiny-init-system" that I was testing.

>> I am assuming that should be for the user to keep in mind, but will
>> it be possible to add something that will make init.d-scripts not
>> work when systemd is running and unit-files not work when systemd is
>> not running?
>
> They currently just bail out with bogus errors as far as I am aware.
>
>  # /etc/init.d/ntpd start
> ntpd             | * WARNING: ntpd is already starting
>  # /etc/init.d/ntpd stop
> ntpd             | * ERROR: ntpd stopped by something else

See above, what about if "ntpd" wasn't running yet?

>> >> hooks on reboot are still needed for more complex ones.
>> >
>> > Which complex cases would these hooks be needed on?
>>
>> I think one of these would be the stopping/starting of services (see
>> above)
>
> No, if you keep the init system the same as the one you boot with there
> should be no problems.

See above, what about trying to start services using the method of the
not-running init?

>> [[ Below is my ONLY remark on that, please feel free to mentally
>> paste it as a response any email trying to explain why it's important
>> to reduce the boottime ]]
>
> My intention was not to advocate optimizing boot times;

I know, that bit was meant generic, not just as a reply to you.

> as a kernel
> maintainer / developer I need to test new releases, run git bisects, do
> Nouveau reclocking work. I really need this, the average person that
> keeps his PC running, not so much; I care for it because I can't wait 2
> minutes, not because I think it's shiny to have such a short boot...
>
> PS: I'm also a mobile laptop user that no longer has a battery. :/

I believe you can still use hibernate there? :)

--
Joost

Re: [gentoo-dev] eselect init

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1612 bytes --]

On Sat, 25 May 2013 21:55:20 +0200
Tom Wijsman <TomWij@gentoo.org> wrote:

> On Sat, 25 May 2013 21:09:47 +0200
> "J. Roeleveld" <joost@antarean.org> wrote:
> 
> > +1 for wrapper, from my understanding, symlinks for init-systems
> > can't be altered on a running system without risking strange
> > behaviour.
> 
> Exactly...
> 
>  # shutdown -h now
> 
> The system is going down for system halt NOW!s/1) (Sat May 25 21:25:41
> 2013): Excess arguments.

I don't know what is the state of your system when testing this but on
my system /sbin/telinit is a symlink to /sbin/init. So replacing
the latter also replaces telinit with something unexpected.

Of course, the solution is to make telinit point to the real sysvinit
executable. Not sure how well it will reboot then, however. It may be
necessary to also change 'halt' to use 'telinit' if it uses 'init'
directly.

> > I am assuming that should be for the user to keep in mind, but will
> > it be possible to add something that will make init.d-scripts not
> > work when systemd is running and unit-files not work when systemd is
> > not running?
> 
> They currently just bail out with bogus errors as far as I am aware.
> 
>  # /etc/init.d/ntpd start
> ntpd             | * WARNING: ntpd is already starting
>  # /etc/init.d/ntpd stop
> ntpd             | * ERROR: ntpd stopped by something else

I think we fixed this already... well, not exactly this because openrc
used to try to actually start stuff. I would consider this a regression
since it had explanatory error messages.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

Re: [gentoo-dev] eselect init

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 1361 bytes --]

On Sun, 26 May 2013 14:59:28 +0200
"J. Roeleveld" <joost@antarean.org> wrote:

> As an example. Lets say I want to test a new init-system. [SNIP] 
> If I then, accidentally, type "/etc/init.d/xyz start" when "xyz"
> hasn't been started by any means yet. What will happen?
> I would assume that openrc will try to start "xyz"?

As I said before:

> > They currently just bail out with bogus errors as far as I am aware.
> >
> >  # /etc/init.d/ntpd start
> > ntpd             | * WARNING: ntpd is already starting
> >  # /etc/init.d/ntpd stop
> > ntpd             | * ERROR: ntpd stopped by something else
> 
> See above, what about if "ntpd" wasn't running yet?

ntpd isn't running on my system and wasn't when I did that.

> > No, if you keep the init system the same as the one you boot with
> > there should be no problems.
> 
> See above, what about trying to start services using the method of the
> not-running init?

The same, feel free to emerge systemd and try to start a service; I
expect this to bail out since its dependencies aren't started, for its
dependencies to start the init system itself should be in use.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] eselect init

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 1631 bytes --]

On Sun, 26 May 2013 15:15:26 +0200
Michał Górny <mgorny@gentoo.org> wrote:

> Cc: TomWij@gentoo.org

Please don't CC me, this causes duplicate mails; one of both does not
include reply-to. Nobody else that has responded to me did this before.

Unless you can give me an awesome procmail rule to process these... :)

> I don't know what is the state of your system when testing this but on
> my system /sbin/telinit is a symlink to /sbin/init. So replacing
> the latter also replaces telinit with something unexpected.

I did something like `mv /sbin/init{,.bak} ; mv systemd /sbin/init`

> Of course, the solution is to make telinit point to the real sysvinit
> executable. Not sure how well it will reboot then, however. It may be
> necessary to also change 'halt' to use 'telinit' if it uses 'init'
> directly.

Currently I use `systemctl reboot` and `systemctl poweroff`, I
actually have no idea how to make telinit work again with systemd.

> >  # /etc/init.d/ntpd start
> > ntpd             | * WARNING: ntpd is already starting
> >  # /etc/init.d/ntpd stop
> > ntpd             | * ERROR: ntpd stopped by something else
> 
> I think we fixed this already... well, not exactly this because openrc
> used to try to actually start stuff. I would consider this a
> regression since it had explanatory error messages.

The stop error is reasonable I think, the start error is indeed odd.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] eselect init

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 25/05/13 03:08 PM, Matthew Thode wrote:
> On 05/25/13 05:25, Peter Stuge wrote:
>> Luca Barbato wrote:
>>> - init gets effectively switched only at boot/reboot
>> 
>> Please not on reboot, because an unclean shutdown shouldn't leave
>> the system in limbo.
>> 
>> On boot could work, except that it does add more steps (= more 
>> fragility) to the boot process, which I think everyone wants to 
>> avoid.
>> 
>> I would actually expect the change to take effect immediately.
>> 
>> 
>> //Peter
>> 
> the final action before / is remouted ro at shutdown would make
> sense to me.  It's either that or first action at boot.
> 

First action at boot, without an initramfs, is too late isn't it?  The
kernel has already launched init at this point.  Also, relying on
something at shutdown is going to be problematic too -- openrc and
systemd (and whatever others) all need the functionality to do this
built into their "scripts", and cases of dirty shutdowns are not going
to be handled well.

The only way I can think of that this is going to work, every time,
reliably, is if it was done within an initramfs and therefore prior to
the start of actual init (ie, initramfs would read a config file to
determine what init-selector to run, calls the init-selector actions,
and then exec's that init -- that config file could be
eselect-controlled or just edited)

And that brings back in the whole initramfs-required flamewar....


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlGiGIMACgkQ2ugaI38ACPBw+gD6A6F5DF6fTFYibbpBjueg1rw1
SL/zUYRomTXDrfhqbDUA/3YxUCAeXrX8dDAlQKbomWnVCG9gKrZObOF5lFo/MXZs
=GXEk
-----END PGP SIGNATURE-----

Re: [gentoo-dev] eselect init

[Rich Freeman]

On Sun, May 26, 2013 at 10:07 AM, Tom Wijsman <TomWij@gentoo.org> wrote:
> On Sun, 26 May 2013 15:15:26 +0200
> Michał Górny <mgorny@gentoo.org> wrote:
>
>> Cc: TomWij@gentoo.org
>
> Please don't CC me, this causes duplicate mails; one of both does not
> include reply-to. Nobody else that has responded to me did this before.
>
> Unless you can give me an awesome procmail rule to process these... :)
>

:0 Wh: msgid.lock
| formail -D 8192 msgid.cache

:0 a:
.duplicates/new

(or /dev/null as you prefer)

I'm sure it isn't perfect, but I've been running it for years.
Between lists and aliases I'd be buried in dups otherwise.

Apologies for the OT, but I figured this was useful, and you did ask...

Rich

Re: [gentoo-dev] eselect init

[Luca Barbato]

On 5/26/13 1:58 PM, Tom Wijsman wrote:
> On Sun, 26 May 2013 12:57:42 +0200
> Michał Górny <mgorny@gentoo.org> wrote:
>
>> Switch inittab? Now you added really dangerous behavior to the wrapper
>> code. I can hardly even express this in words.
>
> It doesn't need to be in the wrapper, inittab is something read at boot
> only as far as I am aware and therefore eselect can do it.

Apparently it is read when you switch runlevel as well.

lu

Re: [gentoo-dev] eselect init

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 26/05/13 08:59 AM, J. Roeleveld wrote:
> On Sat, May 25, 2013 21:55, Tom Wijsman wrote:
>> On Sat, 25 May 2013 21:09:47 +0200 "J. Roeleveld"
>> <joost@antarean.org> wrote:
>> 
>>> How will the stop/start part of services/init-scripts/... be
>>> done?
>> 
>> Not sure what you mean here; if you keep init function the same
>> as the init you boot with, this should continue to work.
> 
> As an example. Lets say I want to test a new init-system. To do
> this, I follow the (still to be written) guide on "eselect init"
> and boot into new-and-shiny-init-system.
> 
> I am still used to stopping/starting services using
> "/etc/init.d/<service> start/stop" And using the "rc" command to
> add/remove services from the runlevel(s).
> 
> If I then, accidentally, type "/etc/init.d/xyz start" when "xyz"
> hasn't been started by any means yet. What will happen? I would
> assume that openrc will try to start "xyz"? This is, I believe,
> something that could cause issues as dependencies might also try to
> start and I then have a service running not managed by the
> "new-and-shiny-init-system" that I was testing.

Point #1 - openrc isn't init -- 'eselect init' or w/e is not
necessarily going to be the same as 'eselect rc-system'.  It's
unlikely that you'll want to use another rc system if using systemd
for your init, but that doesn't mean you can't.

Point #2 - yes, this can be an issue and I believe it's already being
worked on separately; WilliamH has mentioned issues like this more
than once on irc, at least, although I don't know if he's implemented
any solution(s).

This bit should go into a separate thread or bug, and not be
considered part of the overall 'eselect init' solution imo.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlGiIiQACgkQ2ugaI38ACPA7dwD/Y6IJo+/j2Ho4p1bM8mGMt7E8
ZglL7SvNS7g/90K6n1gA/37F0u5v2gzIoSTVi6uEmyhcPMW/2I2vr+YRv0rALO8S
=PuVY
-----END PGP SIGNATURE-----

Re: [gentoo-dev] eselect init

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 26/05/13 07:40 AM, Luca Barbato wrote:
> On 5/26/13 12:57 PM, Michał Górny wrote:
>> You are telling me that a wrapper, a thing that gets executed
>> *every* boot needs to do some random magic to know which init
>> system was in use and which one is supposed to be in use, and
>> then conditionally move around configuration files necessary for
>> it to run. This is just *INSANE*.
> 
> I like to think it normal and the wrapper doesn't need to run every
> time but only when a switch had been requested. And only if you
> prefer doing the switch at boot time instead than at shutdown.
> 

The way it's being proposed (and please correct me if i'm wrong), the
wrapper is a direct replacement binary (small C program) for all init
systems, and would based on some configuration file or whatnot
determine and exec the init system it's supposed to -- and make any
other necessary changes too, such as switching /etc/inittab)

I don't know (outside of a script in the initramfs) how this would
otherwise be handled to cover all cases.  I am curious though, if you
see a way to do this otherwise, what the implementation would look like?


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlGiIxAACgkQ2ugaI38ACPDrbAD/exZAI4utNuOBAMzdkeYj8JgB
lmeOg+G892g4yYMa6cIBALEQMH3bliQ0hF3HEtJezdbzG4/XkaEdGIjM+gscxF79
=9J3a
-----END PGP SIGNATURE-----

Re: [gentoo-dev] eselect init

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 1073 bytes --]

On Sun, 26 May 2013 16:52:27 +0200
Luca Barbato <lu_zero@gentoo.org> wrote:

> On 5/26/13 1:58 PM, Tom Wijsman wrote:
> > On Sun, 26 May 2013 12:57:42 +0200
> > Michał Górny <mgorny@gentoo.org> wrote:
> >
> > > Switch inittab? Now you added really dangerous behavior to the
> > > wrapper code. I can hardly even express this in words.
> >
> > It doesn't need to be in the wrapper, inittab is something read at
> > boot only as far as I am aware and therefore eselect can do it.
> 
> Apparently it is read when you switch runlevel as well.

Ouch, that indeed makes it impossible for eselect to do this and makes
the wrapper more complex; unless there is a sane way to on reboot, but
then we would be implementing this in too many places. I think some of
the other suggestions made here also don't take this into account.

Thanks for mentioning.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] eselect init

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 335 bytes --]

On Sun, May 26, 2013 at 11:55:24AM +0200, Luca Barbato wrote:
> Openrc is small, but the wrapper really needs to know which is which and 
> worst case switch inittab.

Please explain why this wrapper would need to switch inittab. Inittab is
only used by sysvinit and has no uses in any other init system.

Thanks,

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] eselect init

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 587 bytes --]

On Sun, May 26, 2013 at 11:41:06AM -0500, William Hubbs wrote:
> On Sun, May 26, 2013 at 11:55:24AM +0200, Luca Barbato wrote:
> > Openrc is small, but the wrapper really needs to know which is which and 
> > worst case switch inittab.
> 
> Please explain why this wrapper would need to switch inittab. Inittab is
> only used by sysvinit and has no uses in any other init system.

Ok, sorry, I was wrong in my previous msg, now I see that bb-init has
its own inittab with a different format.

How about patching bb-init so that it can handle a sysvinit inittab?

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] eselect init

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 843 bytes --]

On Sun, 26 May 2013 11:48:30 -0500
William Hubbs <williamh@gentoo.org> wrote:

> On Sun, May 26, 2013 at 11:41:06AM -0500, William Hubbs wrote:
> > On Sun, May 26, 2013 at 11:55:24AM +0200, Luca Barbato wrote:
> > > Openrc is small, but the wrapper really needs to know which is which and 
> > > worst case switch inittab.
> > 
> > Please explain why this wrapper would need to switch inittab. Inittab is
> > only used by sysvinit and has no uses in any other init system.
> 
> Ok, sorry, I was wrong in my previous msg, now I see that bb-init has
> its own inittab with a different format.
> 
> How about patching bb-init so that it can handle a sysvinit inittab?

Er, isn't that too far to diverge from upstream? If we're to patch
something, I'd rather patch it to use a different path.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

Re: [gentoo-dev] eselect init

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1229 bytes --]

On Sun, May 26, 2013 at 06:55:45PM +0200, Michał Górny wrote:
> On Sun, 26 May 2013 11:48:30 -0500
> William Hubbs <williamh@gentoo.org> wrote:
> 
> > On Sun, May 26, 2013 at 11:41:06AM -0500, William Hubbs wrote:
> > > On Sun, May 26, 2013 at 11:55:24AM +0200, Luca Barbato wrote:
> > > > Openrc is small, but the wrapper really needs to know which is which and 
> > > > worst case switch inittab.
> > > 
> > > Please explain why this wrapper would need to switch inittab. Inittab is
> > > only used by sysvinit and has no uses in any other init system.
> > 
> > Ok, sorry, I was wrong in my previous msg, now I see that bb-init has
> > its own inittab with a different format.
> > 
> > How about patching bb-init so that it can handle a sysvinit inittab?
> 
> Er, isn't that too far to diverge from upstream? If we're to patch
> something, I'd rather patch it to use a different path.

From what I just read, the difference is that busybox init ignores the
runlevels specified in sysvinit inittab.

I guess it isn't an error for the runlevels to be there, it just doesn't
do anything with them.

Luca,

If that's the only difference, do we really need to modify the inittab
at all?

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] eselect init

[Luca Barbato]

On 5/27/13 12:58 AM, William Hubbs wrote:
> From what I just read, the difference is that busybox init ignores the
> runlevels specified in sysvinit inittab.

Nope, it interprets the numbers in a different way.

> If that's the only difference, do we really need to modify the inittab
> at all?

Yes, I tested it first and got the whole system unworkable, one single 
mode later I baked something to get at least the minimal functionality, 
supporting our xdm script properly required some more effort I hadn't 
time to pour that day.

lu

Re: [gentoo-dev] eselect init

[Luca Barbato]

On 5/26/13 4:13 PM, Ian Stakenvicius wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 25/05/13 03:08 PM, Matthew Thode wrote:
>> On 05/25/13 05:25, Peter Stuge wrote:
>>> Luca Barbato wrote:
>>>> - init gets effectively switched only at boot/reboot
>>>
>>> Please not on reboot, because an unclean shutdown shouldn't leave
>>> the system in limbo.
>>>
>>> On boot could work, except that it does add more steps (= more
>>> fragility) to the boot process, which I think everyone wants to
>>> avoid.
>>>
>>> I would actually expect the change to take effect immediately.
>>>
>>>
>>> //Peter
>>>
>> the final action before / is remouted ro at shutdown would make
>> sense to me.  It's either that or first action at boot.
>>
>
> First action at boot, without an initramfs, is too late isn't it?

bootchart2 shows that is quite possible and working fine for it =)

The current mode to switch init manually for my use-case is to drop to 
single user, do your stuff, reboot or reload init if the init or the 
operating system supports it.

Drop to single user is quite the same as rebooting anyway.

lu

[gentoo-dev] Switchup-mode and boottime selector? Was: eselect init

[Duncan]

Ian Stakenvicius posted on Sun, 26 May 2013 10:58:24 -0400 as excerpted:

> On 26/05/13 07:40 AM, Luca Barbato wrote:
>> On 5/26/13 12:57 PM, Michał Górny wrote:
>>> You are telling me that a wrapper, a thing that gets executed *every*
>>> boot needs to do some random magic to know which init system was in
>>> use and which one is supposed to be in use, and then conditionally
>>> move around configuration files necessary for it to run. This is just
>>> *INSANE*.
>> 
>> I like to think it normal and the wrapper doesn't need to run every
>> time but only when a switch had been requested. And only if you prefer
>> doing the switch at boot time instead than at shutdown.
>> 
>> 
> The way it's being proposed (and please correct me if i'm wrong), the
> wrapper is a direct replacement binary (small C program) for all init
> systems, and would based on some configuration file or whatnot determine
> and exec the init system it's supposed to -- and make any other
> necessary changes too, such as switching /etc/inittab)
> 
> I don't know (outside of a script in the initramfs) how this would
> otherwise be handled to cover all cases.  I am curious though, if you
> see a way to do this otherwise, what the implementation would look like?

Here's an idea I've not seen proposed yet.

Make the wrapper function something like a cross between a simple 
bootloader and traditional single-user-mode.

Normal mode, like the bootloader for many users, would be a default 
choice with (configurable) either a timeout of a couple seconds, or (say 
shift) key-held-down detection, thus no boot delay as if the key isn't 
down at the moment of detection, boot proceeds using the existing config.

In the event of an init switchup, the user either sets an option before 
shutdown (much like the run-once defaults of grub, etc, set pre-
shutdown), or selects switchup mode with the appropriate boot-time 
trigger (using the above mentioned timeout or key-down sensing).

The special switchup mode would then operate much like single-user in 
terms of available functionality and the fact that it's a special mode 
used for system maintenance, but would (normally, with a drop-to-shell 
option as well) be rather more guided, presumably using a menu, again 
much like a bootloader, except that it's PID-1 instead of pre-kernel.

Critical point #1 is that much like single-user mode, switchup mode would 
NOT run normally, but would be specifically selected, with either a 
reboot or simply starting the new init system at switchup mode exit.

That gives switchup mode a lot more flexibility in terms of what's 
allowed, since it's no longer in the time-critical every-boot path, and 
because it's its own mode, it can mount / rw to make changes as 
necessary, with either a reboot to start the selected init-system or 
simply starting it normally, at switchup mode exit.  And if anything goes 
wrong, simply select switchup mode at the next boot once again, and 
either revert to previous, for fix it.

Critical point #2 is that the actual normal-mode wrapper would be very 
small both in terms of boot-time and code, thus both easy to debug, and 
not increasing boot time by much at all, particularly in key-down-
detection mode where there'd be no timeout delay to tick down.  A small 
binary that simply either runs the timout or detects key-down, before 
execing the normal init, is all that would run in a normal bootup.  The 
complex functionality would only be invoked if switchup mode is chosen, 
as entirely separate functionality execed place of the normal init it 
would have otherwise execed.

Meanwhile, switchup mode (again, a separate binary execed only if chosen 
from the tiny one designed to run inline at each boot) would have a menu 
with options to invoke scripts for each of the init-system choices 
offered, and a further fall-back to shell option.

Each init-system package would then depend (perhaps conditionally based 
on an init-switcher USE flag) on the init-switcher package, and would 
ship one gentoo specific file, the switcher script, thus putting each 
switcher script under the control of the gentoo maintainers for that init-
system package, who could set it up to be as simple or as complex as 
necessary for their init system.  Those who needed a rw root to switch 
out various files could arrange for their switcher script to handle that, 
while those who could do without, possibly handling things later with 
their own native init-service, could do without the rw root bit.  
Similarly, switchup mode exit-time behavior, presumably either simply 
triggering a reboot, or starting the selected init-system directly, would 
be entirely under the control of the individual init-system package 
maintainers, via the switch-script they maintain.

As a first bonus, even people who aren't interested in more than one init-
system might find setting the init-switcher USE flag useful, especially 
on EFI systems, since it would give them the advantages of switchup mode, 
namely a drop to shell option as yet another alternative to single user 
mode, AND perhaps even MORE importantly, access to a more or less 
automated init-system restore option, triggered via selection of the same 
switcher script that would otherwise be run to switch between init-
systems.  Again, the contents of that init-system-specific switcher-
script would be entirely under the control of the gentoo maintainers for 
that package, so they could do whatever fancy working-condition checks 
and restores from backup that they wanted.

As a second bonus, switchup mode would be extremely flexible and 
extensible via these scripts, and I'd envision people writing extension 
scripts for all sorts of additional functionality.  Backups while the 
system is quiesced?  Hook for boot-chart and similar modes?  A fast-boot 
special media-player mode?  Something else exotic in mind?  No problem!  
Hack up a special purpose switchup-mode script for it, and "the world's 
your oyster!"
 
-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Switchup-mode and boottime selector? Was: eselect init

[Alex Xu]

[-- Attachment #1: Type: text/plain, Size: 714 bytes --]

Funny. This is starting to sound familiar... almost like some other
software that runs at boot, every boot. Hm, what was the name...

Oh, a *bootloader*! Something that *loads* different *boot* configurations!

But seriously. For people that can install a bootloader, is there really
any "reconfiguration" needed to reboot into a different init system?
Just add configuration items as needed for different init systems. We've
never automatically added bootloader options if sys-kernel/* is updated;
why start now?

For those who are on EFI with direct load of Linux, either install a
bootloader or use efibootmgr or similar to add entries into the native
boot selector (really another bootloader).


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Switchup-mode and boottime selector? Was: eselect init

[Walter Dnes]

On Mon, May 27, 2013 at 10:36:41AM +0000, Duncan wrote

> Here's an idea I've not seen proposed yet.
> 
> Make the wrapper function something like a cross between a simple 
> bootloader and traditional single-user-mode.
> 
> Normal mode, like the bootloader for many users, would be a default 
> choice with (configurable) either a timeout of a couple seconds, or (say 
> shift) key-held-down detection, thus no boot delay as if the key isn't 
> down at the moment of detection, boot proceeds using the existing config.
> 
> In the event of an init switchup, the user either sets an option before 
> shutdown (much like the run-once defaults of grub, etc, set pre-
> shutdown), or selects switchup mode with the appropriate boot-time 
> trigger (using the above mentioned timeout or key-down sensing).

  That is still adding unnecessary complexity to the systems, and an
additional possible point of failure.

> The special switchup mode would then operate much like single-user in 
> terms of available functionality and the fact that it's a special mode 
> used for system maintenance, but would (normally, with a drop-to-shell 
> option as well) be rather more guided, presumably using a menu, again 
> much like a bootloader, except that it's PID-1 instead of pre-kernel.

  What does this accomplish that could not be accomplished by...
* placing a switcher script in /sbin
* booting to single-user mode, and running the switcher script

> Critical point #1 is that much like single-user mode, switchup mode
> would NOT run normally, but would be specifically selected, with
> either a reboot or simply starting the new init system at switchup
> mode exit.

  It waddles like single-user mode
  It quacks  like single-user mode
  It flies   like single-user mode
  It *IS*         single-user mode

  Why bother re-inventing the wheel.  Use single-user mode, already.

> Critical point #2 is that the actual normal-mode wrapper would be very 
> small both in terms of boot-time and code, thus both easy to debug, and 
> not increasing boot time by much at all, particularly in key-down-
> detection mode where there'd be no timeout delay to tick down.  A small 
> binary that simply either runs the timout or detects key-down, before 
> execing the normal init, is all that would run in a normal bootup.  The 
> complex functionality would only be invoked if switchup mode is chosen, 
> as entirely separate functionality execed place of the normal init it 
> would have otherwise execed.
> 
> Meanwhile, switchup mode (again, a separate binary execed only if chosen 
> from the tiny one designed to run inline at each boot) would have a menu 
> with options to invoke scripts for each of the init-system choices 
> offered, and a further fall-back to shell option.
> 
> Each init-system package would then depend (perhaps conditionally based 
> on an init-switcher USE flag) on the init-switcher package, and would 
> ship one gentoo specific file, the switcher script, thus putting each 
> switcher script under the control of the gentoo maintainers for that init-
> system package, who could set it up to be as simple or as complex as 
> necessary for their init system.  Those who needed a rw root to switch 
> out various files could arrange for their switcher script to handle that, 
> while those who could do without, possibly handling things later with 
> their own native init-service, could do without the rw root bit.  
> Similarly, switchup mode exit-time behavior, presumably either simply 
> triggering a reboot, or starting the selected init-system directly, would 
> be entirely under the control of the individual init-system package 
> maintainers, via the switch-script they maintain.

  I repeat, all this can be handled in single-user mode right now.

> As a first bonus, even people who aren't interested in more than one init-
> system might find setting the init-switcher USE flag useful, especially 
> on EFI systems, since it would give them the advantages of switchup mode, 
> namely a drop to shell option as yet another alternative to single user 
> mode,

  Oh boy... a second single-user mode.

> AND perhaps even MORE importantly, access to a more or less automated
> init-system restore option, triggered via selection of the same
> switcher script that would otherwise be run to switch between init-
> systems.  Again, the contents of that init-system-specific switcher-
> script would be entirely under the control of the gentoo maintainers
> for that package, so they could do whatever fancy working-condition
> checks and restores from backup that they wanted.

  What you're talking about is rescue-CD functionality.  I don't know if
it's possible, but it would be very nice as a standalone rescue CD
(actually USB stick nowadays).  If so, I would much rather prefer it on
as rescue CD/USB-stick than as a boot option.  If a system is really
screwed up, you can't even assume that it'll boot to single-mode from
the hard drive.

> As a second bonus, switchup mode would be extremely flexible and 
> extensible via these scripts, and I'd envision people writing extension 
> scripts for all sorts of additional functionality.  Backups while the 
> system is quiesced?  Hook for boot-chart and similar modes?  A fast-boot 
> special media-player mode?  Something else exotic in mind?  No problem!  
> Hack up a special purpose switchup-mode script for it, and "the world's 
> your oyster!"

  I think you've just re-invented the bootloader (lilo/grub).  It can
boot Gentoo, Fedora, BSD, any special-purpose kernel you wish, and even
Windows 7 for that matter.

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

[gentoo-dev] Separate boot/root already [WAS: eselect init]

[Walter Dnes]

On Mon, May 27, 2013 at 01:47:49AM +0200, Luca Barbato wrote

> Yes, I tested it first and got the whole system unworkable, one
> single mode later I baked something to get at least the minimal
> functionality, supporting our xdm script properly required some more
> effort I hadn't time to pour that day.

  People "who want to try something different" in distros, without
irrevocably switching over, normally have a separate partition.  This is
beginning to look like the simplest, least error-prone approach, even
if it is heavy-ganded.

  Out of sheer curiosity... is "bb-init" based on busybox?  If so, a
separate partition would also prevent standard utilities from stomping
all over their busybox symlink equivalants.  Add another entry to the
grub/lilo menu, and boot from that.

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] eselect init

[Luca Barbato]

On 5/26/13 4:58 PM, Ian Stakenvicius wrote:
> The way it's being proposed (and please correct me if i'm wrong), the
> wrapper is a direct replacement binary (small C program) for all init
> systems, and would based on some configuration file or whatnot
> determine and exec the init system it's supposed to -- and make any
> other necessary changes too, such as switching /etc/inittab)

The really minimal wrapper would be something like

#!/bin/sh

INIT=/bin/init

if [[ -e /etc/switch-init ]]; then
     . /etc/switch-init
fi

exec ${INIT}

With switch-init doing stuff needed, including remounting the rootfs rw 
if there are stuff to be changed and if we want stick to symlinks it 
could replace itself by a symlink.

Yes, it would be that simple.

lu

Re: [gentoo-dev] eselect init

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1412 bytes --]

On Tue, 28 May 2013 05:55:39 +0200
Luca Barbato <lu_zero@gentoo.org> wrote:

> On 5/26/13 4:58 PM, Ian Stakenvicius wrote:
> > The way it's being proposed (and please correct me if i'm wrong), the
> > wrapper is a direct replacement binary (small C program) for all init
> > systems, and would based on some configuration file or whatnot
> > determine and exec the init system it's supposed to -- and make any
> > other necessary changes too, such as switching /etc/inittab)
> 
> The really minimal wrapper would be something like
> 
> #!/bin/sh
> 
> INIT=/bin/init
> 
> if [[ -e /etc/switch-init ]]; then
>      . /etc/switch-init
> fi
> 
> exec ${INIT}
> 
> With switch-init doing stuff needed, including remounting the rootfs rw 
> if there are stuff to be changed and if we want stick to symlinks it 
> could replace itself by a symlink.
> 
> Yes, it would be that simple.

And you actually make the boot depend on:

1) valid /bin/sh,

2) valid /etc/switch-init which would not interfere with boot process.

With switch-init being executed as a shell script, it can do anything.
And I wouldn't be surprised if you made it do various things you'd like
to be done. Not to mention what would happen if it gets corrupted into
binary mess and shell tries to execute that.

There's no fallback that could handle shell failures, you know.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

Re: [gentoo-dev] eselect init

[Luca Barbato]

On 5/28/13 6:19 AM, Michał Górny wrote:
> And you actually make the boot depend on:
>
> 1) valid /bin/sh

If it doesn't exist you have a few order of magnitude bigger problem.

> 2) valid /etc/switch-init which would not interfere with boot process.

I guess if you want to switch init system you need that =)

> With switch-init being executed as a shell script, it can do anything.

Yes and that's the beauty of it.

> And I wouldn't be surprised if you made it do various things you'd like
> to be done.

I would be surprised if I'd make it do various things I won't like to be 
done, surely a possibility, albeit unlikely.

> Not to mention what would happen if it gets corrupted into
> binary mess and shell tries to execute that.

Having your rootfs corrupted is quite bad, even horrible if an ephemeral 
file gets corrupted through reboot.

> There's no fallback that could handle shell failures, you know.

I guess your knowledge of shell needs to be expanded, beside that it is 
easier to write an example using shell pseudocode to explain how it 
could work.


That said, here a friendly suggestion: try to be less destructive in 
your comments and fix your mailer. Both can be annoying in the long run.

lu

[gentoo-dev] Re: Switchup-mode and boottime selector? Was: eselect init

[Duncan]

Walter Dnes posted on Mon, 27 May 2013 18:40:21 -0400 as excerpted:

>   What does this accomplish that could not be accomplished by...
> * placing a switcher script in /sbin
> * booting to single-user mode, and running the switcher script

FWIW I agree with you.

In part my post was to make it obvious that's really what we'll end up 
doing if we want any sort of robustness at all.  Otherwise there's simply 
too much that can go wrong.

But assuming people DO insist on traveling that road, there's only one 
way to do it robustly; thru some sort of single-user-mode by that name or 
something else.  And if it's going to be done, let's quit wasting time on 
all the too horribly brittle to think about if not simply broken methods 
that I've seen discussed, and get to it with something that really is 
proven to work, a single-user-mode of some sort, with scripts to simplify 
the already simple and potentially break those doing something complex, 
sure, but if anything's going to work, that'd be it.  And if even that 
can't be made to work or is found not to be worth the hassle, well...

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: Switchup-mode and boottime selector? Was: eselect init

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 2119 bytes --]

On Tue, 28 May 2013 09:56:49 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> wrote:

> In part my post was to make it obvious that's really what we'll end
> up doing if we want any sort of robustness at all.

How much robustness do we really want?

http://engineerblogs.org/2011/04/can-a-design-be-too-robust/

> Otherwise there's simply too much that can go wrong.

You can't have too much go right, that's an unrealistic goal.

> But assuming people DO insist on traveling that road, there's only
> one way to do it robustly; thru some sort of single-user-mode by that
> name or something else.

Why reimplement something that exists? Can we reuse single user mode?
Why do we need single user mode at all?

If you're changing something as important as the init system, one should
be prepared to have an system rescue medium available to correct the
system if needed; although that is not necessarily needed if you use a
wrapper with init=/sbin/einit as you can then just drop that kernel
parameter and use the default again.

> And if it's going to be done, let's quit wasting time on all the too
> horribly brittle to think about if not simply broken methods that
> I've seen discussed,

A comparison between methods goes further than just calling the other
methods broken; this doesn't make me see your method as better, but
rather as just another method, perhaps even a broken method.

> and get to it with something that really is proven to work, a
> single-user-mode of some sort, with scripts to simplify the already
> simple and potentially break those doing something complex, sure, but
> if anything's going to work, that'd be it.  And if even that can't be
> made to work or is found not to be worth the hassle, well...

You're making a lot of statements like this but don't back them up.

Why would this work best for this situation? What's wrong with the rest?

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] eselect init

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 28/05/13 12:43 AM, Luca Barbato wrote:
> On 5/28/13 6:19 AM, Michał Górny wrote:
>> And you actually make the boot depend on:
>> 
>> 1) valid /bin/sh
> 
> If it doesn't exist you have a few order of magnitude bigger 
> problem.
> 
>> 2) valid /etc/switch-init which would not interfere with boot 
>> process.
> 
> I guess if you want to switch init system you need that =)
> 
>> With switch-init being executed as a shell script, it can do 
>> anything.
> 
> Yes and that's the beauty of it.
> 
>> And I wouldn't be surprised if you made it do various things 
>> you'd like to be done.
> 
> I would be surprised if I'd make it do various things I won't like 
> to be done, surely a possibility, albeit unlikely.
> 


OK -- so, given how very simple this wrapper is, and likewise how
simple the switcher script would probably be to write, what's the goal
of this whole thread, exactly?  It doesn't sound like this is
something complicated that we'd need to actually provide via an ebuild
or integrating patches in other init-system ebuilds anymore...





-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlGkn9kACgkQ2ugaI38ACPD1bwD+IaoJ0yM2nyTt8vhICF+nzhQN
CjnLL3yU1LV9qWmwbfUA/jwO4RiTTFKHzoKLn0NHZV2ZqO1y2dbXfzWyuoxz17Lc
=oVXb
-----END PGP SIGNATURE-----

Re: [gentoo-dev] eselect init

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 28/05/13 12:43 AM, Luca Barbato wrote:



OK -- so, given how very simple this wrapper is, and likewise how
simple the switcher script would probably be to write, what's the goal
of this whole thread, exactly?  It doesn't sound like this is
something complicated that we'd need to actually provide via an ebuild
or integrating patches in other init-system ebuilds anymore...





-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlGkn9QACgkQ2ugaI38ACPDo5gD/aObV6+JWdkb+qK4jR0ukh1p5
M3ITzlLVjayvAV6pixwA/2KdUeXK1xcHESVfXLcD1b7+iE75+SOKsQBZz/9S78lO
=4NET
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Separate boot/root already [WAS: eselect init]

[Luca Barbato]

On 05/28/2013 01:45 AM, Walter Dnes wrote:
>   Out of sheer curiosity... is "bb-init" based on busybox?  If so, a

it IS busybox =)

> separate partition would also prevent standard utilities from stomping
> all over their busybox symlink equivalants.  Add another entry to the
> grub/lilo menu, and boot from that.

You don't need symlinks, you have a startscript that runs busybox ash,
then it will use all its applets, init included.

This way about all the openrc shell scripts is executed by the same
interpreter and sed/grep and such are just function calls and not
slightly more pricy fork+exec.

Doing this way you get a quite fast boot and depending on your needs you
can leverage more busybox applets to replace even more programs (e.g.
dhcpcd).

That would be the theoretical fastest boot possible short of integrating
start-stop-daemon in busybox.

lu

[gentoo-dev] Re: Switchup-mode and boottime selector? Was: eselect init

[Duncan]

Tom Wijsman posted on Tue, 28 May 2013 13:56:19 +0200 as excerpted:

> You're making a lot of statements like this but don't back them up.
> 
> Why would this work best for this situation? What's wrong with the rest?

While as long as it stays out of my way enough so I don't have to worry 
about it, I don't particularly care (to the point I debated simply not 
replying), your post did make me aware of the fact that I was claiming 
negatives on the other methods without backing up the claims... because 
from here they were evident, and others had made them well enough I 
didn't need to.

However, I guess if I claim something I owe it to my readers to be 
prepared to back it up, so...

As I've read the thread, there seem to be four issues with most of the 
other methods discussed, three related, one separate.

1) Changing an initsystem with the system up and running in normal state 
risks not being able to shut down properly.  While some init-systems may 
either not have that problem or be able to work around it in a trivial 
way, getting something robust enough to work reliably across all of them, 
in all sorts of weird site configurations, will be... challenging, to say 
the least.

2) Doing it at shutdown has problems of its own, including the incomplete 
switch crash scenario as well as having to do it late enough in the 
process that the operational-switch issues of #1 aren't triggered.

The two problems above lead to the idea of not actually doing the change 
on a running system, but rather, simply using a trigger mechanism to 
trigger it at next boot.  I didn't see it specifically stated what that 
would be, but at least here I envisioned it as comparable to the .fsck 
(whatever it's named) file dropped in root to trigger an fsck at the next 
boot, only in this case it would trigger the init-system switch.

3) Except... any switch has to occur VERY early in the boot process, 
before the existing init-system has already gotten us into the 
operational-switch situation of #1 that we were trying to avoid.  
Effectively, our switcher must be called as init either by the kernel 
itself or by the initr*, where it can do its thing before calling the 
normal init-system it might have just switched to.

3b) Except... at that point root isn't writable, and a robust solution to 
get it writable in ordered to actually make the switch permanent, that 
works on all the strange root-on-whatever systems out there, AND works 
with at least systemd and openrc and bb-init (with extensibility to 
others), AND inserts extremely minimal delay and code into the routine 
"no changes, just boot the same way you did last time" case, AND doesn't 
take control away from the individual init-system package maintainers, 
AND doesn't impose a huge burden on individual init-system package 
maintainers, AND fills ALL these requirements suitably robustly that it 
works well to say at least two-nines reliability...

No wonder someone mentioned that it looked like a case for an initr*... 
but on gentoo anyway, requiring that has at least political problems of 
its own.

It's beginning to look rather like a Sisyphean task... Which it might 
actually be.

But it occurred to me that we actually do have a demonstrated workable 
and long used in actual practice exception to the normal boot case as 
precedent, where such maintenance tasks traditionally occur, single user 
mode.  Then I began thinking how that fit the requirements and use case 
as outlined, including the (semi-?)automated bit.

Which is how I came to post the idea of the sub-thread starter.  Not to 
rehash everything I wrote there, but it seems to me to have the best 
chance at doing what is otherwise looking to be a Sisyphean task.  With 
the extremely minimal two-case-only code inserted between kernel/initr* 
and the selected init-system at boot, it fills the quick and simple 
normal-case boot requirement.  All the rest of the code is out of the 
way.  The rest of the code then runs as a semi-automated single-user-mode 
equivalent.  And having even that minimal normal-boot-mode insert under 
control of a USE flag allows people to get even that out of the way if 
they're not interested.

Meanwhile, it's worth pointing out explicitly that by choosing this 
insertion point, root must already be at least mounted and accessible in 
read-only mode, whether by kernel command-line, initr*, or whatever, or 
the direct init invocation we're replacing wouldn't work.  Thus, the 
whole issue of possibly initr* userspace or kernel commandline getting 
exotic root-on-whatever even mountable in the first place, is already 
taken care of, yet real-init hasn't yet executed, so we don't have to 
worry about messing with an already functioning init-system, thus leaving 
it no way to "climb down".

4) Finally, the fact that each init-system package gets to control its 
own switcher-mode script keeps control of it with the init-system package 
maintainers, allowing them to choose as complex or simple a script as 
they need/wish, reasonably addressing the whole maintainer control 
problem so evident in another current thread.


Beyond that, the idea is extremely flexible and extensible, as mentioned.

And one final point I didn't mention in the initial proposal, that I can 
add here.  Presumably, the init-switcher package would include a library 
function that could be invoked by the individual switcher scripts, that 
would re-mount root rw, to handle any write-needed changes such as 
switching out inittab for bb-init as well as to make the init-system 
choice permanent, plus another to remount ro again before either reboot 
or handing off to the chosen init-system, as deemed appropriate.  These 
would be issues likely to need addressed by all/most init-switcher 
scripts, so a common solution is reasonable.  Of course if the individual 
script didn't need that or was an extension to some other purpose, the 
functions need not be called.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: Switchup-mode and boottime selector? Was: eselect init

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 2231 bytes --]

On Wed, 29 May 2013 00:36:58 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> wrote:

> 3b) Except... at that point root isn't writable

Let me stop you here. Does it need to be writable at that point?

We're reading the path of the init file to boot from a file, we start
the executable at that path; no writes are involved here.

The only problem left here is that some init systems need a specific
version of the inittab file, although this can likely be changed in
late shutdown as the only exception to this approach.

It sounds very feasible for init systems that are an exception to just
being able to switch init alone or have conflicting files to fix up
whatever is inconsistent; either by scheduling changes till when the
disk is writable, or by doing it on shutdown...

> But it occurred to me that we actually do have a demonstrated
> workable and long used in actual practice exception to the normal
> boot case as precedent, where such maintenance tasks traditionally
> occur, single user mode.

Iff nothing else is feasible enough, this makes a lot of sense to me.

> [initr* SNIP]

Having an initr* as a requirement for being able to switch init system
is maybe a bit too much to ask; same as above, iff nothing else ...

> 4) Finally, the fact that each init-system package gets to control
> its own switcher-mode script keeps control of it with the init-system
> package maintainers, allowing them to choose as complex or simple a
> script as they need/wish, reasonably addressing the whole maintainer
> control problem so evident in another current thread.

We should avoid maintenance burden where we can; we can't also force
things upon them, as you can see in other ML threads here. Init systems
are quite necessary in Gentoo, let's not risk losing their maintainers.

That being said; if there are exceptions to the approach we end up
taking, we need to put these somewhere. It kind of depends on how we
will integrate the init system approach in the Portage tree.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Re: Switchup-mode and boottime selector? Was: eselect init

[Walter Dnes]

On Wed, May 29, 2013 at 10:52:49AM +0200, Tom Wijsman wrote
> On Wed, 29 May 2013 00:36:58 +0000 (UTC)
> Duncan <1i5t5.duncan@cox.net> wrote:
> 
> > 3b) Except... at that point root isn't writable
> 
> Let me stop you here. Does it need to be writable at that point?
> 
> We're reading the path of the init file to boot from a file, we start
> the executable at that path; no writes are involved here.
> 
> The only problem left here is that some init systems need a specific
> version of the inittab file, although this can likely be changed in
> late shutdown as the only exception to this approach.

  In order for a different init system to come up, some file(s)
somewhere *MUST* be different, no ifs/ands/ors/buts.  The problem with
an eselect approach is that it's like asking a brain surgeon to operate
on himself.  The proper procedure is to have another brain surgeon
operate on him while the patient is under anesthesia.

> It sounds very feasible for init systems that are an exception to just
> being able to switch init alone or have conflicting files to fix up
> whatever is inconsistent; either by scheduling changes till when the
> disk is writable, or by doing it on shutdown...
> 
> > But it occurred to me that we actually do have a demonstrated
> > workable and long used in actual practice exception to the normal
> > boot case as precedent, where such maintenance tasks traditionally
> > occur, single user mode.
> 
> Iff nothing else is feasible enough, this makes a lot of sense to me.

  There are a couple of other possible approaches...

1) If the 2 systems can achieve peacefull co-existance (i.e. no
identically-named files with different contents) then simply have 2 boot
entries in /etc/lilo.conf (or grub equivalant)...

append = "init=/etc/foo"
append = "init=/etc/bar"

...and select whichever one you want from the boot menu.  This guarantees
a) the system shuts down properly with the old init
b) the system starts up properly with the new init
c) if the new files are incorrect/unbootable, you can simply reboot to
the old version and try to figure out what went wrong

> > [initr* SNIP]
> 
> Having an initr* as a requirement for being able to switch init system
> is maybe a bit too much to ask; same as above, iff nothing else ...

2) We already have such a solution; it's called the Gentoo minimal
install ISO.  If the 2 init systems conflict over identically-named
files, I strongly recommend that the changes be done while booted from a
gentoo minimal install ISO.  This guarantees
a) the system shuts down properly with the old init
b) the system starts up properly with the new init
c) if the new files are incorrect/unbootable, you can simply chroot into
the machine and send pleas for help to the Gentoo user mailing list ;)

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] Re: Switchup-mode and boottime selector? Was: eselect init

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 2322 bytes --]

On Wed, 29 May 2013 14:15:54 -0400
"Walter Dnes" <waltdnes@waltdnes.org> wrote:

> In order for a different init system to come up, some file(s)
> somewhere *MUST* be different, no ifs/ands/ors/buts.

How true is this in general? It is usually only a change of the init
parameter. As far as I heard there is only one exception, /etc/inittab
being different between just two init systems; if you know more
exceptions, feel free to list them. So, please prove your statement.

> The problem with an eselect approach is that it's like asking a brain
> surgeon to operate on himself.

eselect and wrappers don't operate on themselves, please elaborate.

> The proper procedure is to have another brain surgeon operate on him
> while the patient is under anesthesia.

Actually no, we're going a step further. The eselect doesn't touch the
wrapper, but only its config; it's like actually changing brain memory.

> There are a couple of other possible approaches...
> 
> 1) If the 2 systems can achieve peacefull co-existance (i.e. no
> identically-named files with different contents) then simply have 2
> boot entries in /etc/lilo.conf (or grub equivalant)...
> 
> [SNIP to shorten mail]

Users can already do this, this isn't a solution.

We want to make this easier towards the user, therefore doing heavy
discussion to exhaust all the alternatives and maybe someone's
interested in implementing one of them that appears most feasible.

> > Having an initr* as a requirement for being able to switch init
> > system is maybe a bit too much to ask; same as above, iff nothing
> > else ...
> 
> 2) We already have such a solution; it's called the Gentoo minimal
> install ISO.

I agree, I have mine always available; yet some people are consistent
in coming up with solutions for when all hell breaks lose.

> If the 2 init systems conflict over identically-named
> files, I strongly recommend that the changes be done while booted
> from a gentoo minimal install ISO.
>
> [SNIP to shorten mail]

Again: Users can already do this, this isn't a solution. See above...

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Re: Switchup-mode and boottime selector? Was: eselect init

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 998 bytes --]

On Wed, May 29, 2013 at 09:56:00PM +0200, Tom Wijsman wrote:
> > There are a couple of other possible approaches...
> > 
> > 1) If the 2 systems can achieve peacefull co-existance (i.e. no
> > identically-named files with different contents) then simply have 2
> > boot entries in /etc/lilo.conf (or grub equivalant)...
> > 
> > [SNIP to shorten mail]
> 
> Users can already do this, this isn't a solution.
> 
> We want to make this easier towards the user, therefore doing heavy
> discussion to exhaust all the alternatives and maybe someone's
> interested in implementing one of them that appears most feasible.

Since users can already do this, why are we bothering with re-inventing
the wheel? How does running an eselect init command make it easier for
the user than telling them to edit their boot loader config file?

Gentoo users are expected to build their kernel and write their boot
loader config file initially, so why are we trying to dumb this down?

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: Switchup-mode and boottime selector? Was: eselect init

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 1050 bytes --]

On Wed, 29 May 2013 15:55:23 -0500
William Hubbs <williamh@gentoo.org> wrote:

> > We want to make this easier towards the user, therefore doing heavy
> > discussion to exhaust all the alternatives and maybe someone's
> > interested in implementing one of them that appears most feasible.
> 
> Since users can already do this, why are we bothering with
> re-inventing the wheel? How does running an eselect init command make
> it easier for the user than telling them to edit their boot loader
> config file?
>
> Gentoo users are expected to build their kernel and write their boot
> loader config file initially, so why are we trying to dumb this down?

For the same reason we have all the other eselect modules.

http://www.gentoo.org/proj/en/eselect/

Ironically, that project description even mentions init system... :)

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Re: Switchup-mode and boottime selector? Was: eselect init

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1330 bytes --]

On Thu, May 30, 2013 at 02:06:42AM +0200, Tom Wijsman wrote:
> On Wed, 29 May 2013 15:55:23 -0500
> William Hubbs <williamh@gentoo.org> wrote:
> 
> > > We want to make this easier towards the user, therefore doing heavy
> > > discussion to exhaust all the alternatives and maybe someone's
> > > interested in implementing one of them that appears most feasible.
> > 
> > Since users can already do this, why are we bothering with
> > re-inventing the wheel? How does running an eselect init command make
> > it easier for the user than telling them to edit their boot loader
> > config file?
> >
> > Gentoo users are expected to build their kernel and write their boot
> > loader config file initially, so why are we trying to dumb this down?
> 
> For the same reason we have all the other eselect modules.
 
We could probably also turn gcc-config into an eselect module if we
want to use that argument.

> http://www.gentoo.org/proj/en/eselect/
> 
> Ironically, that project description even mentions init system... :)

Yes, but the init system module that project refers to is already there.
Check out eselect rc. It has nothing to do with switching init systems.
It appears to be a wrapper around rc-update and a couple of other things
to manage init scripts and runlevels.

Thanks,

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-dev] Re: Switchup-mode and boottime selector? Was: eselect init

[Duncan]

William Hubbs posted on Wed, 29 May 2013 19:22:32 -0500 as excerpted:

> We could probably also turn gcc-config into an eselect module if we want
> to use that argument.

IIRC it actually was, at one point.  The eselect gcc module even allowed 
separate configs for 32-bit and 64-bit on at least amd64/multilib.

However, the gentoo dev, Jeremy Huddleston IIRC (tho I used to get him 
and another dev with I believe the same initials mixed up, so I might 
have gotten the wrong one), that developed and maintained the package 
moved on (IIRC to Apple... looks like he's still there if I'm googling 
the same one?), and nobody cared to take it up so it rotted until it was 
masked and I guess eventually removed.

Since then I guess nobody's dared (or simply didn't have the prioritized 
time if they dared) mess with the existing gcc-config enough to try to 
turn it into an eselect module again.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: Switchup-mode and boottime selector? Was: eselect init

[Walter Dnes]

On Wed, May 29, 2013 at 09:56:00PM +0200, Tom Wijsman wrote

> "Walter Dnes" <waltdnes@waltdnes.org> wrote:
> 
> > In order for a different init system to come up, some file(s)
> > somewhere *MUST* be different, no ifs/ands/ors/buts.
> 
> How true is this in general? It is usually only a change of the init
> parameter.

  Where is the init parameter changed?  Even if it's only the "append"
line in /etc/lilo.conf, my above statement still holds true.  If you've
got two identical machines with byte-identical hard drives, they can not
boot two different OS's or init systems.

> > The problem with an eselect approach is that it's like asking a brain
> > surgeon to operate on himself.
> 
> eselect and wrappers don't operate on themselves, please elaborate.

  The operating system is changing itself.

> > [SNIP to shorten mail]
> 
> Users can already do this, this isn't a solution.

> > [SNIP to shorten mail]
> 
> Again: Users can already do this, this isn't a solution. See above...

  If users can already do it themselves, then why this entire thread?
Why do we need eselect/whatever?

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] Re: Switchup-mode and boottime selector? Was: eselect init

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 1368 bytes --]

On Wed, 29 May 2013 22:52:58 -0400
"Walter Dnes" <waltdnes@waltdnes.org> wrote:

> > > In order for a different init system to come up, some file(s)
> > > somewhere *MUST* be different, no ifs/ands/ors/buts.
> > 
> > How true is this in general? It is usually only a change of the init
> > parameter.
> 
> Where is the init parameter changed?

Wherever it needs to be changed.

> [... SNIP] byte-identical hard drives [SNIP ...]

You either change it at boot time or on the hard drive.

> > > The problem with an eselect approach is that it's like asking a
> > > brain surgeon to operate on himself.
> > 
> > eselect and wrappers don't operate on themselves, please elaborate.
> 
> The operating system is changing itself.

The world is changing itself.
 
> > > [SNIP to shorten mail]
> > 
> > Users can already do this, this isn't a solution.
> 
>   If users can already do it themselves, then why this entire thread?
> Why do we need eselect/whatever?

For the same reason we have all the other eselect modules.

http://www.gentoo.org/proj/en/eselect/

Ironically, that project description even mentions init system... :)

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Re: Switchup-mode and boottime selector? Was: eselect init

[Luca Barbato]

On 05/29/2013 10:55 PM, William Hubbs wrote:
> On Wed, May 29, 2013 at 09:56:00PM +0200, Tom Wijsman wrote:
>>> There are a couple of other possible approaches...
>>>
>>> 1) If the 2 systems can achieve peacefull co-existance (i.e. no
>>> identically-named files with different contents) then simply have 2
>>> boot entries in /etc/lilo.conf (or grub equivalant)...
>>>
>>> [SNIP to shorten mail]
>>
>> Users can already do this, this isn't a solution.
>>
>> We want to make this easier towards the user, therefore doing heavy
>> discussion to exhaust all the alternatives and maybe someone's
>> interested in implementing one of them that appears most feasible.
> 
> Since users can already do this, why are we bothering with re-inventing
> the wheel? How does running an eselect init command make it easier for
> the user than telling them to edit their boot loader config file?

Because to me and many other EFI users is quite annoying having to
rebuild the kernel or do something ugly such as editing a binary file.

Because it isn't just editing a file or rebuilding the kernel but also
have a short trip in single mode to switch back and forth inittab.

Because addons such as bootchart2 or e4rat would be much simpler to use
through eselect init than doing the whole bootloader or kernel-rebuild
dance.

> Gentoo users are expected to build their kernel and write their boot
> loader config file initially, so why are we trying to dumb this down?

Because usually we aren't linux from scratch and we try to automate as
much as we could, leaving the options there to be selected =)

lu

Re: [gentoo-dev] Re: Switchup-mode and boottime selector? Was: eselect init

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 486 bytes --]

On Wed, 29 May 2013 22:52:58 -0400
"Walter Dnes" <waltdnes@waltdnes.org> wrote:
>   If users can already do it themselves, then why this entire thread?
> Why do we need eselect/whatever?

The big argument in favour of eselect is that when the procedure for
switching things changes, there's no need to worry about users doing
the old thing.

(That, and if eselect doesn't have it, there will be something far
worse showing up on the forums anyway...)

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: Switchup-mode and boottime selector? Was: eselect init

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 927 bytes --]

On Wed, 29 May 2013 19:22:32 -0500
William Hubbs <williamh@gentoo.org> wrote:

> > For the same reason we have all the other eselect modules.
>  
> We could probably also turn gcc-config into an eselect module if we
> want to use that argument.

Looking at Duncan's reply, that has already happened in the past.

Really, think about it, why do we have all those eselect modules at all?
Why be inconsistent and not introduce one here? Why keep them around?

Well, the answer is simple:

Remember that eselect init is optional and an opt-in by emerging it,
this is in no way suggested anywhere to become a default on all systems.

If you don't want it, fine, but that doesn't stop us from pursuing it...

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Re: Switchup-mode and boottime selector? Was: eselect init

[Dale]

[-- Attachment #1: Type: text/plain, Size: 767 bytes --]

Tom Wijsman wrote:
> For the same reason we have all the other eselect modules. http://www.gentoo.org/proj/en/eselect/
Ironically, that project description even mentions init system... :)

As someone else pointed out, not the same thing.  Quoting:

William Hubbs wrote:

> Yes, but the init system module that project refers to is already there.
> Check out eselect rc. It has nothing to do with switching init systems.
> It appears to be a wrapper around rc-update and a couple of other things
> to manage init scripts and runlevels.
>
> Thanks,
>
> William
>

In case you missed the post, thought I would provide it to clear up the
matter.

Dale

:-)  :-)

-- 
I am only responsible for what I said ... Not for what you understood or
how you interpreted my words!


[-- Attachment #2: Type: text/html, Size: 1408 bytes --]

Re: [gentoo-dev] Re: Switchup-mode and boottime selector? Was: eselect init

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 336 bytes --]

On Wed, 29 May 2013 19:22:32 -0500
William Hubbs <williamh@gentoo.org> wrote:
> We could probably also turn gcc-config into an eselect module if we
> want to use that argument.

Someone did, but unfortunately gcc-config is a big pile of poorly
understood voodoo, so eclectic gcc ended up being abandoned.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: Switchup-mode and boottime selector? Was: eselect init

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 30/05/13 02:46 AM, Ciaran McCreesh wrote:
> On Wed, 29 May 2013 19:22:32 -0500 William Hubbs
> <williamh@gentoo.org> wrote:
>> We could probably also turn gcc-config into an eselect module if
>> we want to use that argument.
> 
> Someone did, but unfortunately gcc-config is a big pile of poorly 
> understood voodoo, so eclectic gcc ended up being abandoned.
> 

The eselect-gcc wrapper was almost an alias though, wasn't it?  ie, it
just called gcc-config underneath?

Is there interest in reviving this?  All of our documentation has
discussed using gcc-config directly for so long, i'm not sure if
there'd be that much adoption...



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlGnWh4ACgkQ2ugaI38ACPDikgEAmMoqnaQK7INQvVWWN65DdP2q
xQDyGr6X6CR59aZzV8sA/3EBjOBPTH4+SKOUjA4ar0ghlItSCrmWCBjNJdPhIwiQ
=d1d+
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: Switchup-mode and boottime selector? Was: eselect init

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 296 bytes --]

On Thu, May 30, 2013 at 08:35:22AM +0200, Tom Wijsman wrote:
> Remember that eselect init is optional and an opt-in by emerging it,
> this is in no way suggested anywhere to become a default on all systems.
 
 Ok, that's cool then, I just would hate to see it become a default.

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: Switchup-mode and boottime selector? Was: eselect init

[Ciaran McCreesh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, 30 May 2013 09:54:38 -0400
Ian Stakenvicius <axs@gentoo.org> wrote:
> On 30/05/13 02:46 AM, Ciaran McCreesh wrote:
> > On Wed, 29 May 2013 19:22:32 -0500 William Hubbs
> > <williamh@gentoo.org> wrote:
> >> We could probably also turn gcc-config into an eselect module if
> >> we want to use that argument.
> > 
> > Someone did, but unfortunately gcc-config is a big pile of poorly 
> > understood voodoo, so eclectic gcc ended up being abandoned.
> > 
> 
> The eselect-gcc wrapper was almost an alias though, wasn't it?  ie, it
> just called gcc-config underneath?

At least one of the eselect gcc implementations was "from scratch".

> Is there interest in reviving this?  All of our documentation has
> discussed using gcc-config directly for so long, i'm not sure if
> there'd be that much adoption...

It would be good, in the name of consistency. It would also be a great
opportunity to fix Gentoo's unique inability to have multiple libstdc++
versions usable simultaneously.

- -- 
Ciaran McCreesh
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iEYEARECAAYFAlGoQYgACgkQ96zL6DUtXhH69QCgseYybgvnYUyTJNBCrnQvyf3t
XbkAnik/suBWNyQp6D919WqGmWc+3EeG
=msFd
-----END PGP SIGNATURE-----

[gentoo-dev] Re: eselect init

[Steven J. Long]

On Sat, May 25, 2013 at 11:54:48AM +0200, Luca Barbato wrote:
> 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.

That's not an argument for using a symlink switcher or the equivalent
across the board, by any means.

Firstly, we should be recommending people install Gentoo with enough
flexibility to configure and use their system how they choose. In the UEFI
arena, why not simply recommend something like rEFIt instead of making
everyone go through a load of development effort, to restrict us all to a
crippled use-case?

NOTE: If you still wish to pursue a fixed config, then it's easy enough to
build it with init=/sbin/einit since presumably you want that setup for your
users.

So even for the restricted corner-case of a Gentoo install without a
bootloader this is not needed. In fact it would be better done using the
existing mechanism.

All I'm saying is: can we please stop trying to reinvent the kernel, which 
accepts a bootloader parameter from initramfs as well, and focus instead on
the difficult part: making sure the system is in a fit state to switch in
the first place.

That's where the development effort is needed, if you are to provide a
mechanism to switch. The symlink and hooks etc is a total dead-end, imo.
It's simply reinventing the wheel using octagons instead of circles.

There's nothing to stop systemd being the default init, should you want to put
the install together like that. Because let's be honest: someone has to put this
install together, irrespective of how incapable the end-user is of editing a
file by themselves. And just because the user can do it simply, that's no reason
to make our method to do it any more complex (I've never heard such a bizarre
argument.) Just edit the file via script.

If we're on a crippled EFI setup, or the user has specified to use the boot wrapper,
then we're simply editing a file for the wrapper to read instead. It's trivial.

FOCUS on getting the system safe to switch. Not on reinventing init/main.c, badly.

-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

[gentoo-dev] Re: eselect init

[Steven J. Long]

> In the UEFI arena, why not simply recommend something like rEFIt

sorry should have been rEFInd: http://www.rodsbooks.com/refind/ as discussed
recently on gentoo-user@.

-- 

Re: [gentoo-dev] Re: eselect init

[Luca Barbato]

On 06/01/2013 11:23 AM, Steven J. Long wrote:
> That's not an argument for using a symlink switcher or the
> equivalent across the board, by any means.

Your opinion.

> Firstly, we should be recommending people install Gentoo with enough 
> flexibility to configure and use their system how they choose. In the
> UEFI arena, why not simply recommend something like rEFIt instead of
> making everyone go through a load of development effort, to restrict
> us all to a crippled use-case?

Beside rEFIt being deprecated and rEFInd being in early stage of
development (thus working great on some platforms and not working at all
on some other) and with a good chunk of documentation to read before
being able of deploying it?

> NOTE: If you still wish to pursue a fixed config, then it's easy
> enough to build it with init=/sbin/einit since presumably you want
> that setup for your users.

Had been considered

> All I'm saying is: can we please stop trying to reinvent the kernel,
> which accepts a bootloader parameter from initramfs as well, and
> focus instead on the difficult part: making sure the system is in a
> fit state to switch in the first place.

...

> That's where the development effort is needed, if you are to provide
> a mechanism to switch. The symlink and hooks etc is a total dead-end,
> imo. It's simply reinventing the wheel using octagons instead of
> circles.

IMHO you hadn't read enough about it.

> There's nothing to stop systemd being the default init, should you
> want to put the install together like that. Because let's be honest:
> someone has to put this install together, irrespective of how
> incapable the end-user is of editing a file by themselves. And just
> because the user can do it simply, that's no reason to make our
> method to do it any more complex (I've never heard such a bizarre 
> argument.) Just edit the file via script.

I do not care about systemd.

> FOCUS on getting the system safe to switch. Not on reinventing
> init/main.c, badly.

You should read the whole thread before commenting like this that late.

lu

[gentoo-dev] Re: Re: eselect init

[Steven J. Long]

On Sun, Jun 02, 2013 at 11:15:37AM +0200, Luca Barbato wrote:
> On 06/01/2013 11:23 AM, Steven J. Long wrote:
> > That's not an argument for using a symlink switcher or the
> > equivalent across the board, by any means.
> 
> Your opinion.

That's not an argument for it either.
 
> > Firstly, we should be recommending people install Gentoo with enough 
> > flexibility to configure and use their system how they choose. In the
> > UEFI arena, why not simply recommend something like rEFIt instead of
> > making everyone go through a load of development effort, to restrict
> > us all to a crippled use-case?
> 
> Beside rEFIt being deprecated and rEFInd being in early stage of
> development (thus working great on some platforms and not working at all
> on some other) and with a good chunk of documentation to read before
> being able of deploying it?

The typical thing Gentoo users get told is "this is a new thing, it will
take some time to work out, bear with us" as their production servers go
tits-up around them. So in this case too, work with upstream to implement
better solutions you, and the wider ecosystem, can all use.

And in the meantime:
 
> > NOTE: If you still wish to pursue a fixed config, then it's easy
> > enough to build it with init=/sbin/einit since presumably you want
> > that setup for your users.
> 
> Had been considered

And STILL the best interim solution till your EFI setup has a bootloader.

"Your opinion" of rejection is just that: your opinion.

You're free to work on whatever you want. You just haven't made any
case for why the rest of the ecosystem should be crippled to allow for a
use-case that would be better served by an existing, far more robust
solution.

> > All I'm saying is: can we please stop trying to reinvent the kernel,
> > which accepts a bootloader parameter from initramfs as well, and
> > focus instead on the difficult part: making sure the system is in a
> > fit state to switch in the first place.
> 
> ...
> 
> > That's where the development effort is needed, if you are to provide
> > a mechanism to switch. The symlink and hooks etc is a total dead-end,
> > imo. It's simply reinventing the wheel using octagons instead of
> > circles.
> 
> IMHO you hadn't read enough about it.

Believe me I've read lots. And you _still_ are not presenting any arguments.

There are 6 options to hook in an init, and to fallback in case of error,
already.
 
> > There's nothing to stop systemd being the default init, should you
> > want to put the install together like that. Because let's be honest:
> > someone has to put this install together, irrespective of how
> > incapable the end-user is of editing a file by themselves. And just
> > because the user can do it simply, that's no reason to make our
> > method to do it any more complex (I've never heard such a bizarre 
> > argument.) Just edit the file via script.
> 
> I do not care about systemd.

Then it can be runit or whatever else takes your fancy. You are ignoring
the point of that paragraph though: someone has to put the install together.

Or it isn't a Gentoo install.

So given that you're putting it together, or it's an automated script
to do the same, you can hook in an init wrapper or alternative wherever you
want, without needing anything from anyone else.

> > FOCUS on getting the system safe to switch. Not on reinventing
> > init/main.c, badly.
> 
> You should read the whole thread before commenting like this that late.

I have actually. I responded to WilliamH a while back, CC'ed to him since he
prefers that, but the mail didn't get through to the list. It was marked
TLDNR so no doubt it hit a filter somewhere, and I didn't see the point in
reiterating it.

I've seen two weeks of discussion about how to reimplement init/main.c
with "ooh it needs to be early in init" and "what about fallbacks", interleaved
with less and less discussion of the actual problem: making sure the system is
safe to switch in the first place; sine qua non.

Wrt to the first, funnily enough the kernel developers have been here before,
just like they had with ethN and wlanN. It's a basic requirement for developing
an OS that you be able to switch init and fallback to other options.

You should consider the points made, and whether you really need to implement
this part of the setup at all. Your premise is still flawed, however long
you've been discussing the implications of working round it. Stuff happens.

Honestly, my goal is a saving of time so people can focus on making the
eselect module work properly, and be of real value to an end-user who wants
to switch init.

The whole symlink/boot/fallback thing is simply a waste of technical effort.
And blanket "your opinion" and "you didn't comment a week ago, so I don't
have to deal with the substance of your points" don't change that.

Please, make a better case next time.

-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

Re: [gentoo-dev] Re: Re: eselect init

[Fabio Erculiani]

On Sun, Jun 2, 2013 at 8:20 PM, Steven J. Long
<slong@rathaus.eclipse.co.uk> wrote:
>

[...]

> The whole symlink/boot/fallback thing is simply a waste of technical effort.
> And blanket "your opinion" and "you didn't comment a week ago, so I don't
> have to deal with the substance of your points" don't change that.

Waste? We have multiple use cases for that as stated in several places
(here, bugzilla, IRC, etc).
If such use cases are of no interest for you, then you shouldn't be bothered.

>
> Please, make a better case next time.
>
> --
> #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
>



-- 
Fabio Erculiani

Re: [gentoo-dev] Re: Re: eselect init

[Luca Barbato]

On 06/02/2013 08:20 PM, Steven J. Long wrote:
> On Sun, Jun 02, 2013 at 11:15:37AM +0200, Luca Barbato wrote:
>> On 06/01/2013 11:23 AM, Steven J. Long wrote:
>>> That's not an argument for using a symlink switcher or the
>>> equivalent across the board, by any means.
>>
>> Your opinion.
> 
> That's not an argument for it either.

Had been explained in the thread, please read it.

>>> Firstly, we should be recommending people install Gentoo with enough 
>>> flexibility to configure and use their system how they choose. In the
>>> UEFI arena, why not simply recommend something like rEFIt instead of
>>> making everyone go through a load of development effort, to restrict
>>> us all to a crippled use-case?
>>
>> Beside rEFIt being deprecated and rEFInd being in early stage of
>> development (thus working great on some platforms and not working at all
>> on some other) and with a good chunk of documentation to read before
>> being able of deploying it?
> 
> The typical thing Gentoo users get told is "this is a new thing, it will
> take some time to work out, bear with us" as their production servers go
> tits-up around them. So in this case too, work with upstream to implement
> better solutions you, and the wider ecosystem, can all use.

I'm afraid you never used those nor you are in one of those situation in
which you have less options.

> And STILL the best interim solution till your EFI setup has a bootloader.

Again you should read the whole thread, please do, the whole eselect
init stuff should stay opt-in for the time being so all this discussion
is close to pointless.

Consider this email a friendly warning, please do not pollute the Gentoo
media with pointless email when you had been already politely told that
your concern had been addressed in the previous email in the thread.

> You're free to work on whatever you want. You just haven't made any
> case for why the rest of the ecosystem should be crippled to allow for a
> use-case that would be better served by an existing, far more robust
> solution.

Had it been the case we wouldn't had spent some weeks picking our brains
on it.

> Then it can be runit or whatever else takes your fancy. You are ignoring
> the point of that paragraph though: someone has to put the install together.
> 
> Or it isn't a Gentoo install.

And you seem to miss the point that all you are telling had been
discussed, taken in consideration and in some part agreed with already...

> Wrt to the first, funnily enough the kernel developers have been here before,
> just like they had with ethN and wlanN. It's a basic requirement for developing
> an OS that you be able to switch init and fallback to other options.

Again you didn't ready or you forgot. I said already I don't care about
systemd many times, yet you failed to remember that.
My specific use-case would require a trip to single mode and a second
reboot, the way I want to do spares that.

On an EFI-stub only system it would require at least a kernel rebuild or
a trip to the efi shell if available.

> Honestly, my goal is a saving of time so people can focus on making the
> eselect module work properly, and be of real value to an end-user who wants
> to switch init.

To not make this a waste of time here a summary of the whole thing:

- eselect init will be opt-in for the time being, people can be left on
their own tools if the want it
- the default init will stay sysvinit. Discussion ongoing if is better
to have it installed in a secondary fallback path is open (e.g. /bin/init).
- I still need to send patches to busybox and sysvinit upstream to add a
command line switch to locate the inittab.
- people wanting to switch init or enable/disable init addons using
eselect init might have to refer to /sbin/einit or such custom path
(assuming we fail to come to an agreement regarding /bin/init)

The wrapper in /sbin/init is mostly needed to get to the point of a
clean reboot.

The first time you boot on a new system it is executed picking the new
init and just that.

For addons such as bootchart2 and e4rat it would do slightly more.

Assuming upstream doesn't accept custom paths for the inittab, for my
specific usecase I might bake something that would remount r/w and pivot
the inittabs.

Anybody willing to do something more extreme could even consider having
/sbin/init as a symlink and have the boot-time configuration switch the
symlink, thus making the whole script run just a single boot per switch.

Not necessary but surely feasible.

lu

Re: [gentoo-dev] Re: Re: eselect init

[Walter Dnes]

On Mon, Jun 03, 2013 at 12:35:29AM +0200, Luca Barbato wrote

> - eselect init will be opt-in ***FOR THE TIME BEING***, people can
> be left on their own tools if the want it

  This statement should bring the same reaction as the posting that udev
source was being rolled into the systemd tarball.  It implies that
eselect init will eventually become mandatory.

  Your situation is a special use-case, i.e. a developer who wants to
switch between a "production" init system, and a "test" init system,
possibly multiple times a day.  You're a developer, you know which files
to change, put together your own scripts, and run them as necessary.
Set up your own overlay and write your own eselect init ebuild.  No
problem.  But why should this eventually be a part of mainstream Gentoo?

  BTW, I'm a bigger fan of busybox than most Gentoo users.  Remember the
announcement of systemd/udev tarball integration, and supposed
deprecation of a separate /usr?  I was the ****-disturber who started up
the https://wiki.gentoo.org/wiki/Mdev wiki page on how to replace udev
with mdev.  I also did a page on automounting at...
https://wiki.gentoo.org/wiki/Mdev/Automount_USB/automount  Having said
that, I don't see how busybox development justifies an additional layer
of complexity for everybody's bootup.

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] Re: Re: eselect init

[Rich Freeman]

On Sun, Jun 2, 2013 at 8:37 PM, Walter Dnes <waltdnes@waltdnes.org> wrote:
> On Mon, Jun 03, 2013 at 12:35:29AM +0200, Luca Barbato wrote
>
>> - eselect init will be opt-in ***FOR THE TIME BEING***, people can
>> be left on their own tools if the want it
>
>   This statement should bring the same reaction as the posting that udev
> source was being rolled into the systemd tarball.  It implies that
> eselect init will eventually become mandatory.

I don't get why it would ever become mandatory, or why people are
worried about this.  The only packages that tend to touch anything
like inittab are the packages that implement init in the first place.
I'm not aware of any init packages that would require otherwise.  That
being the case, there isn't going to be any tight coupling here.  If
you want a simple config just point your grub/etc to the init
implementation of your choice and it is hard-coded.  Or, install the
fancy switcher script/initramfs/whatever and use it.

People get way to panicky every time somebody posts a new idea on
-dev.  Half of these ideas never get implemented, and 90% of those
which are don't become defaults.  Heck, the intent was always to make
OpenRC the default and it took YEARS for that to happen on stable.

When you see two random developers post a crazy idea on -dev, keep in
mind that we're a distro that fosters innovation by letting any
developer start a project based solely on personal initiative.
Generally things don't become defaults until it becomes fairly obvious
that this is the appropriate course of action.

Rich

[gentoo-dev] Re: eselect init

[Duncan]

Luca Barbato posted on Mon, 03 Jun 2013 00:35:29 +0200 as excerpted:

> To not make this a waste of time here a summary of the whole thing:
> 
> - eselect init will be opt-in for the time being, people can be left on
> their own tools if the want it - the default init will stay sysvinit.
> Discussion ongoing if is better to have it installed in a secondary
> fallback path is open (e.g. /bin/init).
> - I still need to send patches to busybox and sysvinit upstream to add a
> command line switch to locate the inittab.
> - people wanting to switch init or enable/disable init addons using
> eselect init might have to refer to /sbin/einit or such custom path
> (assuming we fail to come to an agreement regarding /bin/init)
> 
> The wrapper in /sbin/init is mostly needed to get to the point of a
> clean reboot.
> 
> The first time you boot on a new system it is executed picking the new
> init and just that.
> 
> For addons such as bootchart2 and e4rat it would do slightly more.

Thanks for the summary.  In the muddle of a contentious thread it's not 
easy to figure out which points have been settled on and which are still 
considered under discussion, so a summary by someone suitably involved as 
to be authoritative can be valuable indeed, even for those who (like me) 
have read the entire thread.

And valuable it was to me here. =:^)

The only concern I had with the above is the one Walter D. brought up, 
that "for the time being" caveat.  But rich0 well addressed that, so... 
I'm good! =:^)

Meanwhile, Walter D: Thanks for your work too.  I'm not using your bb-init 
work ATM, but I deeply appreciate having the alternative available, 
should I find the need for it in the future, and am thus very thankful 
that /someone/ was suitably motivated to create it.  I haven't seen a lot 
of direct thanks on-list for your work, but I suspect there's others who 
seriously appreciate it as well, whether we're already using it or may 
actually never use it but deeply value having the alternative should we 
have need of it, so let this be a thanks from all of us.  It's projects 
like yours, someone seeing a need and addressing it for themselves, then 
simply making that work available for use by others, that form the 
"grassroots" of FLOSS.  =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: Re: eselect init

[Pacho Ramos]

El lun, 03-06-2013 a las 00:35 +0200, Luca Barbato escribió:
[...]
> To not make this a waste of time here a summary of the whole thing:
> 
> - eselect init will be opt-in for the time being, people can be left on
> their own tools if the want it
> - the default init will stay sysvinit. Discussion ongoing if is better
> to have it installed in a secondary fallback path is open (e.g. /bin/init).
> - I still need to send patches to busybox and sysvinit upstream to add a
> command line switch to locate the inittab.
> - people wanting to switch init or enable/disable init addons using
> eselect init might have to refer to /sbin/einit or such custom path
> (assuming we fail to come to an agreement regarding /bin/init)
> 
> The wrapper in /sbin/init is mostly needed to get to the point of a
> clean reboot.
> 
> The first time you boot on a new system it is executed picking the new
> init and just that.
> 
> For addons such as bootchart2 and e4rat it would do slightly more.
> 
> Assuming upstream doesn't accept custom paths for the inittab, for my
> specific usecase I might bake something that would remount r/w and pivot
> the inittabs.
> 
> Anybody willing to do something more extreme could even consider having
> /sbin/init as a symlink and have the boot-time configuration switch the
> symlink, thus making the whole script run just a single boot per switch.
> 
> Not necessary but surely feasible.
> 
> lu
> 
> 

Thanks for the summary :)

Re: [gentoo-dev] Re: Re: eselect init

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 1926 bytes --]

On Sun, 2 Jun 2013 20:37:57 -0400
"Walter Dnes" <waltdnes@waltdnes.org> wrote:

> On Mon, Jun 03, 2013 at 12:35:29AM +0200, Luca Barbato wrote
> 
> > - eselect init will be opt-in ***FOR THE TIME BEING***, people can
> > be left on their own tools if the want it
> 
>   This statement should bring the same reaction as the posting that
> udev source was being rolled into the systemd tarball.  It implies
> that eselect init will eventually become mandatory.

How does it imply that? Do you see anyone pursuing it to be mandatory?

>   Your situation is a special use-case, i.e. a developer who wants to
> switch between a "production" init system, and a "test" init system,
> possibly multiple times a day.  You're a developer, you know which
> files to change, put together your own scripts, and run them as
> necessary. Set up your own overlay and write your own eselect init
> ebuild.  No problem.  But why should this eventually be a part of
> mainstream Gentoo?

Because most Gentoo users are developers.

>   BTW, I'm a bigger fan of busybox than most Gentoo users.  Remember
> the announcement of systemd/udev tarball integration, and supposed
> deprecation of a separate /usr?  I was the ****-disturber who started
> up the https://wiki.gentoo.org/wiki/Mdev wiki page on how to replace
> udev with mdev.  I also did a page on automounting at...
> https://wiki.gentoo.org/wiki/Mdev/Automount_USB/automount  Having said
> that, I don't see how busybox development justifies an additional
> layer of complexity for everybody's bootup.

Great, but that's mostly irrelevant to this ML thread; the need for such
articles is a result of not being able to do it in a more proper way.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Re: Re: eselect init

[Luca Barbato]

On 06/03/2013 02:37 AM, Walter Dnes wrote:
> On Mon, Jun 03, 2013 at 12:35:29AM +0200, Luca Barbato wrote
> 
>> - eselect init will be opt-in ***FOR THE TIME BEING***, people can
>> be left on their own tools if the want it
> 
>   This statement should bring the same reaction as the posting that udev
> source was being rolled into the systemd tarball.  It implies that
> eselect init will eventually become mandatory.

Let me restate:

As long there isn't a strict necessity the whole machinery should not
impact the normal systems with the default init.

>   Your situation is a special use-case, i.e. a developer who wants to
> switch between a "production" init system, and a "test" init system,
> possibly multiple times a day.  You're a developer, you know which files
> to change, put together your own scripts, and run them as necessary.
> Set up your own overlay and write your own eselect init ebuild.  No
> problem.  But why should this eventually be a part of mainstream Gentoo?

e4rat, bootchart and other addons might be more mainstream than
gdb-as-init indeed.

>   BTW, I'm a bigger fan of busybox than most Gentoo users.  Remember the
> announcement of systemd/udev tarball integration, and supposed
> deprecation of a separate /usr?  I was the ****-disturber who started up
> the https://wiki.gentoo.org/wiki/Mdev wiki page on how to replace udev
> with mdev.  I also did a page on automounting at...
> https://wiki.gentoo.org/wiki/Mdev/Automount_USB/automount  Having said
> that, I don't see how busybox development justifies an additional layer
> of complexity for everybody's bootup.

It isn't every bootup =)

lu

Re: [gentoo-dev] Re: Re: eselect init

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 360 bytes --]

Hi Luca,

On Mon, Jun 03, 2013 at 12:35:29AM +0200, Luca Barbato wrote:
> Again you should read the whole thread, please do, the whole eselect
> init stuff should stay opt-in for the time being so all this discussion
> is close to pointless.

Can we please make this remain opt-in always? I too would rather not see
this become mandatory for gentoo.

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: Re: eselect init

[Rich Freeman]

On Tue, Jun 4, 2013 at 2:55 PM, William Hubbs <williamh@gentoo.org> wrote:
> On Mon, Jun 03, 2013 at 12:35:29AM +0200, Luca Barbato wrote:
>> Again you should read the whole thread, please do, the whole eselect
>> init stuff should stay opt-in for the time being so all this discussion
>> is close to pointless.
>
> Can we please make this remain opt-in always? I too would rather not see
> this become mandatory for gentoo.

Sure, it is opt-in always.  Done.  :)

And like any other decision in Gentoo, it can always be changed at a
later date when circumstances change.  There really are no "promises."
 However, I'm sure that such a thing would only change after careful
deliberation and only if it makes a lot of sense.  Just look at how
long it took to stabilize OpenRC, or preserve-libs.

I'm not really sure what people are looking for here.  The word of a
developer who might not be around forever, or a council that might not
be around forever?  I'd like to think that our past experiences
haven't been so bad as to justify a great level of concern.  If
somebody wanted to foist this feature prematurely on the masses I'd be
the first to object...

Rich

[gentoo-dev] Re: Re: Re: eselect init

[Steven J. Long]

On Mon, Jun 03, 2013 at 12:35:29AM +0200, Luca Barbato wrote:
> On 06/02/2013 08:20 PM, Steven J. Long wrote:
> > On Sun, Jun 02, 2013 at 11:15:37AM +0200, Luca Barbato wrote:
> >> On 06/01/2013 11:23 AM, Steven J. Long wrote:
> >>> That's not an argument for using a symlink switcher or the
> >>> equivalent across the board, by any means.
> >>
> >> Your opinion.
> > 
> > That's not an argument for it either.
> 
> Had been explained in the thread, please read it.

..
> Again you should read the whole thread, please do, the whole eselect
> init stuff should stay opt-in for the time being so all this discussion
> is close to pointless.

Actually the point is how to implement the best solution in Gentoo, which is
the point of this mailing-list. To float ideas and see what other perspectives
can contribute to the design. For instance, I think Duncan's idea of a single
mode, effectively secondary bootloader, is the only thing that makes any sense.

It's a Gentoo-specific init-switcher that only runs when the user has initiated
a switchover.

Implementing an init fallback is unneeded, since the kernel tries so many paths
already. And Duncan's mail is at least about the interesting, and *useful* part:
making the system ready to switch, and a setup for init-system switching as a
whole.

Including write to rootfs, eg to change inittab format.

> Consider this email a friendly warning, please do not pollute the Gentoo
> media with pointless email when you had been already politely told that
> your concern had been addressed in the previous email in the thread.

No you weren't polite. You wrote an email that had zero technical content in
it and that was basically just 'ad-hominem' as has been pointed out to me:

http://www.netbooknews.com/wp-content/2011/07/the-pyramid-of-debate-550x417.jpg

Review your last email in the context of the above, please.
 
> > You're free to work on whatever you want. You just haven't made any
> > case for why the rest of the ecosystem should be crippled to allow for a
> > use-case that would be better served by an existing, far more robust
> > solution.
> 
> Had it been the case we wouldn't had spent some weeks picking our brains
> on it.

Yes because programmers never make mistakes, and humans are so good at separating
the woods from the trees..

> > Then it can be runit or whatever else takes your fancy. You are ignoring
> > the point of that paragraph though: someone has to put the install together.
> > 
> > Or it isn't a Gentoo install.
> 
> And you seem to miss the point that all you are telling had been
> discussed, taken in consideration and in some part agreed with already...

Lala. Someone puts the install together: they run (or their script runs):
mv /sbin/init /bin/init && mv /sbin/einit || error 'unable to setup init'

> > Wrt to the first, funnily enough the kernel developers have been here before,
> > just like they had with ethN and wlanN. It's a basic requirement for developing
> > an OS that you be able to switch init and fallback to other options.
> 
> Again you didn't ready or you forgot. I said already I don't care about
> systemd many times, yet you failed to remember that.
> My specific use-case would require a trip to single mode and a second
> reboot, the way I want to do spares that.

Actually none of this has got anything to do with systemd, nor did I mention it, 
so please stop banging on about your feelings about it. They're not relevant to
this discussion, since it's init-system agnostic, just like the kernel fallback
mechanism is, or there's no point to it.
 
> On an EFI-stub only system it would require at least a kernel rebuild or
> a trip to the efi shell if available.

No it wouldn't, see above. And http://marc.info/?l=gentoo-dev&m=136968639518816&w=2
 
> > Honestly, my goal is a saving of time so people can focus on making the
> > eselect module work properly, and be of real value to an end-user who wants
> > to switch init.
> 
> To not make this a waste of time here a summary of the whole thing:

Ah finally some technical content. Yes, the above was a waste of time, and so
was your last email. Just a friendly reminder.

> - eselect init will be opt-in for the time being, people can be left on
> their own tools if the want it

Yes, but we want a sane and robust implementation in Gentoo, irrespective of
who's using it.

> - the default init will stay sysvinit. Discussion ongoing if is better
> to have it installed in a secondary fallback path is open (e.g. /bin/init).

You mean "use the kernel fallback mechanism"? I'm sure you won't be surprised
to hear I think that's a good idea.

> - I still need to send patches to busybox and sysvinit upstream to add a
> command line switch to locate the inittab.

Sounds good. busybox using the standard location with a non-standard format
sounds like a mistake though, at least for the default Gentoo config, where
it is supposed to live alongside the normal Linux utils.  When the user has
a saved-config, it is of course up to them what happens.

> - people wanting to switch init or enable/disable init addons using
> eselect init might have to refer to /sbin/einit or such custom path
> (assuming we fail to come to an agreement regarding /bin/init)
> 
> The wrapper in /sbin/init is mostly needed to get to the point of a
> clean reboot.

I think Duncan's idea makes a lot of sense. It'd be easy enough to write the
base framework to use sh modules, which users and init-system devs collaborate
on, and users maintain effectively over time, by sending in bug-reports and
patches. The existing openrc codebase could be used as a starting point.
 
> The first time you boot on a new system it is executed picking the new
> init and just that.
> 
> For addons such as bootchart2 and e4rat it would do slightly more.
> 
> Assuming upstream doesn't accept custom paths for the inittab, for my
> specific usecase I might bake something that would remount r/w and pivot
> the inittabs.

Or build that in as part of the design, as Duncan raised.
 
> Anybody willing to do something more extreme could even consider having
> /sbin/init as a symlink and have the boot-time configuration switch the
> symlink, thus making the whole script run just a single boot per switch.
> 
> Not necessary but surely feasible.

Many things are doable. Many less are advisable. 

-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

[gentoo-dev] Re: Re: Re: eselect init

[Steven J. Long]

On Sun, Jun 02, 2013 at 08:48:23PM +0200, Fabio Erculiani wrote:
> On Sun, Jun 2, 2013 at 8:20 PM, Steven J. Long
> <slong@rathaus.eclipse.co.uk> wrote:
> >
> 
> [...]
> 
> > The whole symlink/boot/fallback thing is simply a waste of technical effort.
> > And blanket "your opinion" and "you didn't comment a week ago, so I don't
> > have to deal with the substance of your points" don't change that.
> 
> Waste? We have multiple use cases for that as stated in several places
> (here, bugzilla, IRC, etc).
> If such use cases are of no interest for you, then you shouldn't be bothered.

The specific idea of reimplementing the kernel fallback mechanism is a waste of
technical effort. Not the whole idea of eselect init, as I stated several times.

If you lose that idiotic idea, you have a lot less complexity to worry about and
can instead get on with the *necessary* complexity: handling whether it is safe
to switch boot, and how to make it so given the 'from' init and the 'to' init,
which might require write access to the rootfs, eg to swap inittab, or to
mkdir -p a necessary path.

It could need anything, there's simply no way of knowing, and it will require
maintenance over time as init-systems change. That's why the Unix inventors came
up with sh. And the best people to maintain it over time, are the users in
collaboration with the init-system devs, since they are the ones who have the
testcases in front of them, and the motivation to make the software work. While
the devs have a broader view, and an interest in keeping things portable (aka:
'generic'.)

Please try to read and consider my whole argument, instead of selectively quoting
one part and using it to justify YAF ad-hominem.

-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

Re: [gentoo-dev] eselect init

[Fabio Erculiani]

There is a new version of eselect-init in the systemd-love overlay to play with.
The new version saw the following major changes:

- the /sbin/init (aka the symlink that eselect-init handles) can be
changed to whatever one wants through make.conf [1] (this is a compile
time option, as documented in the eclass)
- only init is currently handled by eselect-init, which is now using a
very small wrapper POSIX shell script to redirect the calls to the
currently running init [2]
- the wrapper and its code paths are now documented in the
eselect-init eclass [2] [3]

You need systemd and sysvinit from the same overlay for it to work.
If you intend to use switch between systemd to openrc (and vice
versa), make sure to install the rest of the packages in that overlay.
At the moment, if you want to switch, you also need to use
eselect-settingsd. However, I am planning to drop eselect-settingsd:
openrc-settingsd and systemd share the same settingsd dbus interface
while they call different executables, systemd initializes its dbus
services without relying on dbus activation, so the Exec= part of the
service descriptor file is currently set to /bin/false, this rings a
bell :D, because it is possible to replace /bin/false with a script
that starts the respective services when dbus activation is used
(which means that systemd hasn't booted the system). This would make
possible to remove the blocker dependency in openrc-settingsd and
systemd somehow.

[1] https://github.com/Sabayon/systemd-love/commit/ced29311348a81a2573b030b1316f1c3a0335c5b
[2] https://github.com/Sabayon/systemd-love/commit/9eea3ff713c8fa0391e7b1bfa494d533dc21c0be
[3] https://github.com/Sabayon/systemd-love/blob/master/eclass/eselect-init.eclass

-- 
Fabio Erculiani

[gentoo-dev] Re: eselect init

[Steven J. Long]

Fabio Erculiani wrote:
> - only init is currently handled by eselect-init, which is now using a
> very small wrapper POSIX shell script to redirect the calls to the
> currently running init

How does say, switching inittab format, work under this setup?

-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

Re: [gentoo-dev] Re: eselect init

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 705 bytes --]

On Thu, Jun 20, 2013 at 06:10:27PM +0100, Steven J. Long wrote:
> Fabio Erculiani wrote:
> > - only init is currently handled by eselect-init, which is now using a
> > very small wrapper POSIX shell script to redirect the calls to the
> > currently running init
> 
> How does say, switching inittab format, work under this setup?

I think this is a separate issue -- if busybox init's inittab is a
different format than sysvinbb's inittab, it should also use a different
file name, e.g. bb-inittab or something similar.

bb could fall back to inittab, but I think it should look for something
liike bb-inittab first. That way eselect init wouldn't have to worry
about it at all.

William

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] eselect init

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1988 bytes --]

On Thu, Jun 20, 2013 at 12:16:36PM +0200, Fabio Erculiani wrote:
> There is a new version of eselect-init in the systemd-love overlay to play with.
> The new version saw the following major changes:
> 
> - the /sbin/init (aka the symlink that eselect-init handles) can be
> changed to whatever one wants through make.conf [1] (this is a compile
> time option, as documented in the eclass)

Why do we need to mess with /sbin/init at all?

I like the suggestion that came up here on the list a while back, have
the eselect init module install its own symlink at, say, /sbin/einit.
You would still have to have the user edit their boot loader
configuration file one time if they want to use this, but this makes it
completely opt-in.

The other advantage of this is you don't have to mess with any  init
system ebuilds at all.

> - the wrapper and its code paths are now documented in the
> eselect-init eclass [2] [3]

This eclass could go away entirely if you don't try to control
/sbin/init.

> If you intend to use switch between systemd to openrc (and vice
> versa), make sure to install the rest of the packages in that overlay.
> At the moment, if you want to switch, you also need to use
> eselect-settingsd. However, I am planning to drop eselect-settingsd:
> openrc-settingsd and systemd share the same settingsd dbus interface
> while they call different executables, systemd initializes its dbus
> services without relying on dbus activation, so the Exec= part of the
> service descriptor file is currently set to /bin/false, this rings a
> bell :D, because it is possible to replace /bin/false with a script
> that starts the respective services when dbus activation is used
> (which means that systemd hasn't booted the system). This would make
> possible to remove the blocker dependency in openrc-settingsd and
> systemd somehow.

Keep up the good work; the more simple we can make the integration the
better it will be.

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] eselect init

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1071 bytes --]

Dnia 2013-06-20, o godz. 15:56:09
William Hubbs <williamh@gentoo.org> napisał(a):

> On Thu, Jun 20, 2013 at 12:16:36PM +0200, Fabio Erculiani wrote:
> > There is a new version of eselect-init in the systemd-love overlay to play with.
> > The new version saw the following major changes:
> > 
> > - the /sbin/init (aka the symlink that eselect-init handles) can be
> > changed to whatever one wants through make.conf [1] (this is a compile
> > time option, as documented in the eclass)
> 
> Why do we need to mess with /sbin/init at all?

Yes, we do because we don't want sysvinit randomly getting run
as fallback and messing with our systems.

> I like the suggestion that came up here on the list a while back, have
> the eselect init module install its own symlink at, say, /sbin/einit.
> You would still have to have the user edit their boot loader
> configuration file one time if they want to use this, but this makes it
> completely opt-in.

Plus hacking kernel sources to disable /sbin/init fallback.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

Re: [gentoo-dev] eselect init

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1515 bytes --]

On Fri, Jun 21, 2013 at 04:39:59AM +0200, Michał Górny wrote:
> Dnia 2013-06-20, o godz. 15:56:09
> William Hubbs <williamh@gentoo.org> napisał(a):
> 
> > On Thu, Jun 20, 2013 at 12:16:36PM +0200, Fabio Erculiani wrote:
> > > There is a new version of eselect-init in the systemd-love overlay to play with.
> > > The new version saw the following major changes:
> > > 
> > > - the /sbin/init (aka the symlink that eselect-init handles) can be
> > > changed to whatever one wants through make.conf [1] (this is a compile
> > > time option, as documented in the eclass)
> > 
> > Why do we need to mess with /sbin/init at all?
> 
> Yes, we do because we don't want sysvinit randomly getting run
> as fallback and messing with our systems.

I don't understand what you are saying here.

If eselect-init installs the wrapper as /sbin/einit, we don't have to
touch /sbin/init at all, then, the only thing someone would have to do
is to add an entry to their boot loader with init=/sbin/einit on the kcl
to use it.

> > I like the suggestion that came up here on the list a while back, have
> > the eselect init module install its own symlink at, say, /sbin/einit.
> > You would still have to have the user edit their boot loader
> > configuration file one time if they want to use this, but this makes it
> > completely opt-in.
> 
> Plus hacking kernel sources to disable /sbin/init fallback.

No, there is no reason we would have to hack anything in the kernel
sources.

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] eselect init

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1324 bytes --]

Dnia 2013-06-20, o godz. 23:16:00
William Hubbs <williamh@gentoo.org> napisał(a):

> On Fri, Jun 21, 2013 at 04:39:59AM +0200, Michał Górny wrote:
> > Dnia 2013-06-20, o godz. 15:56:09
> > William Hubbs <williamh@gentoo.org> napisał(a):
> > 
> > > On Thu, Jun 20, 2013 at 12:16:36PM +0200, Fabio Erculiani wrote:
> > > > There is a new version of eselect-init in the systemd-love overlay to play with.
> > > > The new version saw the following major changes:
> > > > 
> > > > - the /sbin/init (aka the symlink that eselect-init handles) can be
> > > > changed to whatever one wants through make.conf [1] (this is a compile
> > > > time option, as documented in the eclass)
> > > 
> > > Why do we need to mess with /sbin/init at all?
> > 
> > Yes, we do because we don't want sysvinit randomly getting run
> > as fallback and messing with our systems.
> 
> I don't understand what you are saying here.
> 
> If eselect-init installs the wrapper as /sbin/einit, we don't have to
> touch /sbin/init at all, then, the only thing someone would have to do
> is to add an entry to their boot loader with init=/sbin/einit on the kcl
> to use it.

But *if* the wrapper fails to run somehow, e.g. becomes broken,
the kernel will fallback to the standard location.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

Re: [gentoo-dev] eselect init

[Michael Weber]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 06/21/2013 04:39 AM, Michał Górny wrote:
> Dnia 2013-06-20, o godz. 15:56:09 William Hubbs
> <williamh@gentoo.org> napisał(a):
> 
>> On Thu, Jun 20, 2013 at 12:16:36PM +0200, Fabio Erculiani wrote:
>>> There is a new version of eselect-init in the systemd-love
>>> overlay to play with. The new version saw the following major
>>> changes:
>>> 
>>> - the /sbin/init (aka the symlink that eselect-init handles)
>>> can be changed to whatever one wants through make.conf [1]
>>> (this is a compile time option, as documented in the eclass)
>> 
>> Why do we need to mess with /sbin/init at all?
> 
> Yes, we do because we don't want sysvinit randomly getting run as
> fallback and messing with our systems.
So what's the point in having it optional, if sysvinit would just mess
around with it.

You'd only hit this, if you start your userland with an foreign kernel.
Forgotten bootloader arguments can be "defaulted" with ...

>> I like the suggestion that came up here on the list a while back,
>> have the eselect init module install its own symlink at, say,
>> /sbin/einit. You would still have to have the user edit their
>> boot loader configuration file one time if they want to use this,
>> but this makes it completely opt-in.
> 
> Plus hacking kernel sources to disable /sbin/init fallback.

CONFIG_CMDLINE=/sbin/whatever works, i use it for root=, crypt_dev, ...
CONFIG_CMDLINE_OVERRIDE should stay off to respect bootloader "cmdline".

[ working with foreign init systems (runit-musl based ignite on
archlinux, NoUpgrade=sbin/init aka CONFIG_PROTECT does work, too.]

- -- 
Michael Weber
Gentoo Developer
web: https://xmw.de/
mailto: Michael Weber <xmw@gentoo.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iF4EAREIAAYFAlHEKzMACgkQknrdDGLu8JA6AwD+MyTTKeHlNN/1Nud/G0L7XnA+
hdJl4qATOU3MkyqDQw0A+wao6tYrHTFWCt4MmTOxl3gsBvUvE/w4sQyZcPTElg3h
=XwPu
-----END PGP SIGNATURE-----

Re: [gentoo-dev] eselect init

[Fabio Erculiani]

For me, the big selling points of eselect-init are:

1. as release engineer, i can prepare images that use either systemd
or openrc (at present time these are the two supported options) and do
it reliably, programmatically.
2. as distro maintainer, i can roll out a migration path from openrc
to systemd (or vice versa). The properties of this migration path I am
looking for are reliability and "atomicity". Basically, once you move
logind/consolekit detection to runtime (and believe it or not, many
upstream just get it wrong), and have feature parity in the systemd
units available (wrt openrc initscripts), switching over is a matter
of 2 (soon 1) commands.

Both of them are quite important, because there are scenarios in where
systemd fits better than openrc, and scenarios in where openrc is a
better fit (older kernels, production system with custom init scripts
that are not worth the porting, etc).
Making the switch between openrc and systemd easy is a big win (for
both developers, distro maintainers, users) and makes Gentoo more
attractive, but this is another topic...

-- 
Fabio Erculiani

Re: [gentoo-dev] eselect init

[Pacho Ramos]

El vie, 21-06-2013 a las 13:19 +0200, Fabio Erculiani escribió:
> For me, the big selling points of eselect-init are:
> 
> 1. as release engineer, i can prepare images that use either systemd
> or openrc (at present time these are the two supported options) and do
> it reliably, programmatically.
> 2. as distro maintainer, i can roll out a migration path from openrc
> to systemd (or vice versa). The properties of this migration path I am
> looking for are reliability and "atomicity". Basically, once you move
> logind/consolekit detection to runtime (and believe it or not, many
> upstream just get it wrong), and have feature parity in the systemd
> units available (wrt openrc initscripts), switching over is a matter
> of 2 (soon 1) commands.
> 
> Both of them are quite important, because there are scenarios in where
> systemd fits better than openrc, and scenarios in where openrc is a
> better fit (older kernels, production system with custom init scripts
> that are not worth the porting, etc).
> Making the switch between openrc and systemd easy is a big win (for
> both developers, distro maintainers, users) and makes Gentoo more
> attractive, but this is another topic...
> 

Thanks for the explanation. But I think that, currently, the only
remaining "objection" is whether play with /sbin/init (that needs
sysvinit to be changed if I don't misremember) or with /sbin/einit.
Looks like mgorny has shown some problems on relying on "einit" instead
of plain "init" regarding to fallback :/

Re: [gentoo-dev] eselect init

[Luca Barbato]

On 06/21/2013 01:26 PM, Pacho Ramos wrote:
> Thanks for the explanation. But I think that, currently, the only
> remaining "objection" is whether play with /sbin/init (that needs
> sysvinit to be changed if I don't misremember) or with /sbin/einit.
> Looks like mgorny has shown some problems on relying on "einit" instead
> of plain "init" regarding to fallback :/

I prefer having /sbin/init used for the pivot since /sbin/einit is a bit
more brittle and as Fabio did the whole machinery is _still_ opt-in.

lu

Re: [gentoo-dev] eselect init

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 921 bytes --]

On Fri, Jun 21, 2013 at 01:50:02PM +0200, Luca Barbato wrote:
> On 06/21/2013 01:26 PM, Pacho Ramos wrote:
> > Thanks for the explanation. But I think that, currently, the only
> > remaining "objection" is whether play with /sbin/init (that needs
> > sysvinit to be changed if I don't misremember) or with /sbin/einit.
> > Looks like mgorny has shown some problems on relying on "einit" instead
> > of plain "init" regarding to fallback :/
> 
> I prefer having /sbin/init used for the pivot since /sbin/einit is a bit
> more brittle and as Fabio did the whole machinery is _still_ opt-in.

No, he has his own versions of the systemd and sysvinit ebuilds which
move some of the installation to non-standard places as part of this
machinery, so it is not opt-in.

Also, there was an email on this thread showing that using
init=/sbin/einit works, so I'm not seeing what mgorny's objections are.

William

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] eselect init

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 592 bytes --]

On Fri, Jun 21, 2013 at 12:23:28PM +0200, Michał Górny wrote:
> > If eselect-init installs the wrapper as /sbin/einit, we don't have to
> > touch /sbin/init at all, then, the only thing someone would have to do
> > is to add an entry to their boot loader with init=/sbin/einit on the kcl
> > to use it.
> 
> But *if* the wrapper fails to run somehow, e.g. becomes broken,
> the kernel will fallback to the standard location.

Yes, but if the wrapper replaces /sbin/init, like it does now, and the
wrapper gets broken, I think you are left with an unbootable system.

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] eselect init

[Fabio Erculiani]

Fix the reason why the wrapper got broken then.
If the wrapper broke, it is most likely a symptom of a bigger problem.

I think that sysvinit's /sbin/init should be renamed to /sbin/sysvinit
(or /bin/sysvinit?), anyway...

-- 
Fabio Erculiani

Re: [gentoo-dev] eselect init

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 802 bytes --]

Dnia 2013-06-21, o godz. 10:16:10
William Hubbs <williamh@gentoo.org> napisał(a):

> On Fri, Jun 21, 2013 at 12:23:28PM +0200, Michał Górny wrote:
> > > If eselect-init installs the wrapper as /sbin/einit, we don't have to
> > > touch /sbin/init at all, then, the only thing someone would have to do
> > > is to add an entry to their boot loader with init=/sbin/einit on the kcl
> > > to use it.
> > 
> > But *if* the wrapper fails to run somehow, e.g. becomes broken,
> > the kernel will fallback to the standard location.
> 
> Yes, but if the wrapper replaces /sbin/init, like it does now, and the
> wrapper gets broken, I think you are left with an unbootable system.

Then kernel falls back to safe /bin/sh which is a minimal safe fallback.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

Re: [gentoo-dev] eselect init

[Pacho Ramos]

El vie, 21-06-2013 a las 09:36 -0500, William Hubbs escribió:
[...]
> No, he has his own versions of the systemd and sysvinit ebuilds which
> move some of the installation to non-standard places as part of this
> machinery, so it is not opt-in.
> 
> Also, there was an email on this thread showing that using
> init=/sbin/einit works, so I'm not seeing what mgorny's objections are.
> 
> William

I think mgorny was referring to a case where einit fails to work and,
then, kernel will fallback to using /sbin/init, that could cause
problems as it would always run /sbin/init from sysvinit... but maybe he
was referring to something else :|

Re: [gentoo-dev] eselect init

[Markos Chandras]

On 21 June 2013 16:29, Michał Górny <mgorny@gentoo.org> wrote:
> Dnia 2013-06-21, o godz. 10:16:10
> William Hubbs <williamh@gentoo.org> napisał(a):
>
>> On Fri, Jun 21, 2013 at 12:23:28PM +0200, Michał Górny wrote:
>> > > If eselect-init installs the wrapper as /sbin/einit, we don't have to
>> > > touch /sbin/init at all, then, the only thing someone would have to do
>> > > is to add an entry to their boot loader with init=/sbin/einit on the kcl
>> > > to use it.
>> >
>> > But *if* the wrapper fails to run somehow, e.g. becomes broken,
>> > the kernel will fallback to the standard location.
>>
>> Yes, but if the wrapper replaces /sbin/init, like it does now, and the
>> wrapper gets broken, I think you are left with an unbootable system.
>
> Then kernel falls back to safe /bin/sh which is a minimal safe fallback.
>
> --
> Best regards,
> Michał Górny

Correct. Even if your init end up being broken you end up with a shell
so you can fix things yourself.

(from init/main.c)

        /*
         * We try each of these until one succeeds.
         *
         * The Bourne shell can be used instead of init if we are
         * trying to recover a really broken machine.
         */
        if (execute_command) {
                if (!run_init_process(execute_command))
                        return 0;
                pr_err("Failed to execute %s.  Attempting defaults...\n",
                        execute_command);
        }
        if (!run_init_process("/sbin/init") ||
            !run_init_process("/etc/init") ||
            !run_init_process("/bin/init") ||
            !run_init_process("/bin/sh"))
                return 0;


But this is not pretty. Not everyone knows how to recover from a
broken init. The eselect module aims to offer an elegant way to
switch init systems but if that fails then you need some advanced
knowledge to fix your system. So my opinion is that before such
thing is introduce to the wild, we need to be confident that it will
never fail but even if it does, you need to provide a documented way
on how to recover. Maybe a bold warning with post-mortem instructions
when you first invoke the eselect module is one way to do it.

--
Regards,
Markos Chandras - Gentoo Linux Developer
http://dev.gentoo.org/~hwoarang

Re: [gentoo-dev] eselect init

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 334 bytes --]

On Fri, Jun 21, 2013 at 05:23:51PM +0200, Fabio Erculiani wrote:
> I think that sysvinit's /sbin/init should be renamed to /sbin/sysvinit
> (or /bin/sysvinit?), anyway...

Feel free to file a request with sysvinit upstream to see if they will
do this; I don't think we should be randomly renaming files at the
distro level.

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] eselect init

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1783 bytes --]

On Fri, Jun 21, 2013 at 05:13:33PM +0100, Markos Chandras wrote:
> On 21 June 2013 16:29, Michał Górny <mgorny@gentoo.org> wrote:
> > Dnia 2013-06-21, o godz. 10:16:10
> > William Hubbs <williamh@gentoo.org> napisał(a):
> >
> >> On Fri, Jun 21, 2013 at 12:23:28PM +0200, Michał Górny wrote:
> >> > > If eselect-init installs the wrapper as /sbin/einit, we don't have to
> >> > > touch /sbin/init at all, then, the only thing someone would have to do
> >> > > is to add an entry to their boot loader with init=/sbin/einit on the kcl
> >> > > to use it.
> >> >
> >> > But *if* the wrapper fails to run somehow, e.g. becomes broken,
> >> > the kernel will fallback to the standard location.
> >>
> >> Yes, but if the wrapper replaces /sbin/init, like it does now, and the
> >> wrapper gets broken, I think you are left with an unbootable system.
> >
> > Then kernel falls back to safe /bin/sh which is a minimal safe fallback.
> >
> > --
> > Best regards,
> > Michał Górny
> 
> Correct. Even if your init end up being broken you end up with a shell
> so you can fix things yourself.

The case we are ignoring here is the indirection in the wrapper. e.g.
the wrapper, /sbin/init is a valid process, but the process it tries to
run, say /bin/foobar, is not.

I'm thinking that no matter where we put the wrapper, either as a custom
version of /sbin/init or as something like /bin/einit, once the kernel
hands things off to the wrapper, if the wrapper fails to run the
executable it is directed to run, we are hosed.

If there is a separate boot loader entry to run the wrapper, users
are able to opt in to using the wrapper, but they can recover if it
fails. That is why I'm against having the wrapper replace the standard
init.

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] eselect init

[Luca Barbato]

On 06/21/2013 05:23 PM, Fabio Erculiani wrote:
> Fix the reason why the wrapper got broken then.
> If the wrapper broke, it is most likely a symptom of a bigger problem.
> 
> I think that sysvinit's /sbin/init should be renamed to /sbin/sysvinit
> (or /bin/sysvinit?), anyway...
> 

/bin/init

lu

Re: [gentoo-dev] eselect init

[Luca Barbato]

On 06/21/2013 06:50 PM, William Hubbs wrote:
> On Fri, Jun 21, 2013 at 05:13:33PM +0100, Markos Chandras wrote:
>> On 21 June 2013 16:29, Michał Górny <mgorny@gentoo.org> wrote:
>>> Dnia 2013-06-21, o godz. 10:16:10
>>> William Hubbs <williamh@gentoo.org> napisał(a):
>>>
>>>> On Fri, Jun 21, 2013 at 12:23:28PM +0200, Michał Górny wrote:
>>>>>> If eselect-init installs the wrapper as /sbin/einit, we don't have to
>>>>>> touch /sbin/init at all, then, the only thing someone would have to do
>>>>>> is to add an entry to their boot loader with init=/sbin/einit on the kcl
>>>>>> to use it.
>>>>>
>>>>> But *if* the wrapper fails to run somehow, e.g. becomes broken,
>>>>> the kernel will fallback to the standard location.
>>>>
>>>> Yes, but if the wrapper replaces /sbin/init, like it does now, and the
>>>> wrapper gets broken, I think you are left with an unbootable system.
>>>
>>> Then kernel falls back to safe /bin/sh which is a minimal safe fallback.
>>>
>>> --
>>> Best regards,
>>> Michał Górny
>>
>> Correct. Even if your init end up being broken you end up with a shell
>> so you can fix things yourself.
> 
> The case we are ignoring here is the indirection in the wrapper. e.g.
> the wrapper, /sbin/init is a valid process, but the process it tries to
> run, say /bin/foobar, is not.
> 
> I'm thinking that no matter where we put the wrapper, either as a custom
> version of /sbin/init or as something like /bin/einit, once the kernel
> hands things off to the wrapper, if the wrapper fails to run the
> executable it is directed to run, we are hosed.
> 

I asked to mgorny to try that already, and he did and reported already,
you can try for yourself and see what happens.

lu - no, I won't tell what happens so you will try for yourself

Re: [gentoo-dev] eselect init

[Ulrich Mueller]

>>>>> On Fri, 21 Jun 2013, Luca Barbato wrote:

> /bin/init

Why /bin? It shouldn't be in users' PATH.

Ulrich

Re: [gentoo-dev] eselect init

[Michael Weber]

On 06/22/2013 03:27 AM, Ulrich Mueller wrote:
>>>>>> On Fri, 21 Jun 2013, Luca Barbato wrote:
> 
>> /bin/init
> 
> Why /bin? It shouldn't be in users' PATH.
"users' PATH", a joyful blast from the past, if I'm allowed to say that.
But it's all /usr/bin now [1].

Off topic -- I always have sbins in my non-root path to use non-root
features of e.g. /sbin/ip.

[1]
https://www.archlinux.org/news/binaries-move-to-usrbin-requiring-update-intervention/

-- 
Michael Weber
Gentoo Developer
web: https://xmw.de/
mailto: Michael Weber <xmw@gentoo.org>

[gentoo-dev] Re: eselect init

[Duncan]

Pacho Ramos posted on Fri, 21 Jun 2013 17:48:59 +0200 as excerpted:

> El vie, 21-06-2013 a las 09:36 -0500, William Hubbs escribió:
> [...]
>> No, he has his own versions of the systemd and sysvinit ebuilds which
>> move some of the installation to non-standard places as part of this
>> machinery, so it is not opt-in.
>> 
>> Also, there was an email on this thread showing that using
>> init=/sbin/einit works, so I'm not seeing what mgorny's objections are.
>> 
>> William
> 
> I think mgorny was referring to a case where einit fails to work and,
> then, kernel will fallback to using /sbin/init, that could cause
> problems as it would always run /sbin/init from sysvinit... but maybe he
> was referring to something else :|

This is my understanding as well.  If there's a problem with /sbin/einit, 
the kernel will fallback to /sbin/init.  If /sbin/init runs a sysv init 
that's setup for an old, no longer sysadmin maintained openrc (or 
whatever other) setup, there's little telling what sort of unpredictable 
things that openrc config from three years ago might end up doing to a 
painstakingly configured systemd (or runit, or...) current config.

That's the worry, and as an admin, I'd be worried about it myself, but in 
practice, I'm not sure it's particularly valid, simply because in the 
real world, the failures are more likely to be full service breakage, 
etc, than they are to be anything really destructive.

The caveat, and this one's big enough to give an admin ulcers for sure, 
is if the machine is a server, and that old no-longer-maintained openrc 
config starts up say a no-longer-maintained sshd instance with a poor 
password that has long since been forgotten about, thus exposing the 
machine to any cracker taking a probe.  However unlikely that is (such an 
unmaintained sshd config should have long since been removed on any 
responsibly administered gentoo system), just the possibility is enough 
to give a responsible admin ulcers worrying about it, because even 
responsible sysadmins fat-finger things, or simply forget about them, 
once in awhile.  THAT's our REAL weakness, and we know it all too well!

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: eselect init

[Pacho Ramos]

After talking with WilliamH yesterday, I have this opinion:
- Playing with /sbin/init (instead of /sbin/einit) has two interesting
advantages:
1. For example, I now have init=/sbin/e4rat-preload in my grub.conf, if
I do a typo, it would fallback to /sbin/init. If /sbin/init is provided
by sysvinit, people running other init providers could have problems.
This wouldn't occur if /sbin/init has been changed to use desired init
system.
2. Tools like e4rat or bootchart launch /sbin/init, if I switch to
systemd, I would need to edit separate configuration files for each tool
to point to new init. This wouldn't occur if we "play" with /sbin/init
=> we would only change init in one place

- I have two doubts:
1. Why do we need a wrapper instead of changing symlinks?
2. Why Fabio chose to move sysvinit to subdirectories... wouldn't be
much simpler to simply rename /sbin/init to /sbin/sysvinit?

Re: [gentoo-dev] Re: eselect init

[Michael Weber]

On 06/22/2013 12:07 PM, Pacho Ramos wrote:
> After talking with WilliamH yesterday, I have this opinion:
> - Playing with /sbin/init (instead of /sbin/einit) has two interesting
> advantages:
> 1. For example, I now have init=/sbin/e4rat-preload in my grub.conf, if
> I do a typo, it would fallback to /sbin/init. If /sbin/init is provided
> by sysvinit, people running other init providers could have problems.
> This wouldn't occur if /sbin/init has been changed to use desired init
> system.
> 2. Tools like e4rat or bootchart launch /sbin/init, if I switch to
> systemd, I would need to edit separate configuration files for each tool
> to point to new init. This wouldn't occur if we "play" with /sbin/init
> => we would only change init in one place
good point. maybe a ton other wrapper of that kind. shouldn't they read
/proc/cmdline for init=^H^H^H^H^Hreal_init= , but that takes time.

> - I have two doubts:
> 1. Why do we need a wrapper instead of changing symlinks?
And a plain symlink has the charm to either resolve (and load and most
likely execure the target) or dangles and kernel tries the next one.
No late, wrapper bailouts leaving the kernel in "You killed pid 1" panic.

=== kexec ===
speaking of panic. I've never actually used it, but newer kernels
support kexec and in conjunction with pre-loaded panic-images[1] and
corresponding (compiled-in) initramfs, it'd be possible to have an
recovery shell. for either /sbin/init mixups, or late runtime crashes.
These should have a the decency to respect the panic= timeout to allow
automated reboots or idle till to the end of days.

[sad enought, that kexec'd kernels don't pick up the process tables/heap
of their predecessors and enable real kernel-hotswitching]

=== more fallback ==
maybe we could ask Mr. Tovalds to ad another line in init/main.c, say
/sbin/init.fallback (but don't mention systemd) or we could abuse
/etc/init or /bin/init or /sbin/sh (with an wrapper to test for PID=1)
for an recovery-environment.
Fabio: did you mean that?

=== security ===
Bailing into /bin/sh or whatever can compromise filesystem
integrity/reveal root access to an uncrypted rootfs.
There is a scenario of vandalism-proof installed computer pools (no
physical access except keyboard/monitor) w/ unattended boot that should
not end up in root-shell. ;-) Maybe I should fix that on my systems ...

[1] sys-apps/kexec-tools http://kernel.org/pub/linux/utils/kernel/kexec/

-- 
Michael Weber
Gentoo Developer
web: https://xmw.de/
mailto: Michael Weber <xmw@gentoo.org>

Re: [gentoo-dev] eselect init

[Jason A. Donenfeld]

[-- Attachment #1: Type: text/plain, Size: 695 bytes --]

If we're to support sysvinit and systemd at the same time, let each use
their upstream paths. This means sysvinit gets /sbin/init.

This also means that business can continue as usual, and nobody is forced
to install eselect-init. The current system works for users who don't care
or aren't aware of this innovation. Motivated users who want the ability to
change back and forth can emerge eselect-init and modify their init= line
in the bootloader.

This is cleaner because it keeps things more in lockstep with upstream.

This is also politically easier, as it doesn't require any notable changes
or new ebulds to openrc folks, which I can imagine might be met with
opposition here and there.

[-- Attachment #2: Type: text/html, Size: 788 bytes --]

Re: [gentoo-dev] Re: eselect init

[Rich Freeman]

On Sat, Jun 22, 2013 at 7:13 AM, Michael Weber <xmw@gentoo.org> wrote:
> === kexec ===
> speaking of panic. I've never actually used it, but newer kernels
> support kexec and in conjunction with pre-loaded panic-images[1] and
> corresponding (compiled-in) initramfs, it'd be possible to have an
> recovery shell. for either /sbin/init mixups, or late runtime crashes.
> These should have a the decency to respect the panic= timeout to allow
> automated reboots or idle till to the end of days.

I wrote up the wiki guide on this, but for the last six months I
haven't been able to get it to work. If somebody does have it working
please see if the guide needs updating - something seems to have
changed.

It is annoying because my system seems to freeze up on rare occasion
and I'm sure there is a panic/etc on the console obscured by X11.  At
the moment, however, some kind of xorg freezeup seems to be what is
driving me crazy (seems like a driver puts it into a loop and makes it
freeze for 30s at a time, with even alt-sysrq-r not always working.
Moving both kernel and xorg from stable to ~arch didn't help with that
either...  Ugh.

Rich

Re: [gentoo-dev] eselect init

[hasufell]

On 06/22/2013 01:23 PM, Jason A. Donenfeld wrote:
> and nobody is forced to install eselect-init

That was already demanded earlier in this discussion, but I don't see
any response from the initiators of this idea (possible I just missed it).

Anyway... if they do such a global change without discussing this
particular problem, then it will cause someone to revert it or ask for
QA/council intervention.

Re: [gentoo-dev] Re: eselect init

[Luca Barbato]

On 06/22/2013 12:07 PM, Pacho Ramos wrote:
> After talking with WilliamH yesterday, I have this opinion:
> - Playing with /sbin/init (instead of /sbin/einit) has two interesting
> advantages:
> 1. For example, I now have init=/sbin/e4rat-preload in my grub.conf, if
> I do a typo, it would fallback to /sbin/init. If /sbin/init is provided
> by sysvinit, people running other init providers could have problems.
> This wouldn't occur if /sbin/init has been changed to use desired init
> system.
> 2. Tools like e4rat or bootchart launch /sbin/init, if I switch to
> systemd, I would need to edit separate configuration files for each tool
> to point to new init. This wouldn't occur if we "play" with /sbin/init
> => we would only change init in one place
> 
> - I have two doubts:
> 1. Why do we need a wrapper instead of changing symlinks?

So once I'm not busy playing with pixels and hw accels I would implement
addons support in the wrapper (so bootchart and e4rat would just ran by
the init wrapper)

> 2. Why Fabio chose to move sysvinit to subdirectories... wouldn't be
> much simpler to simply rename /sbin/init to /sbin/sysvinit?

I prefer /bin/init but any place would fit (and should be configurable
anyway)

lu

Re: [gentoo-dev] Re: Switchup-mode and boottime selector? Was: eselect init

[Markos Chandras]

On 05/29/2013 09:55 PM, William Hubbs wrote:
> On Wed, May 29, 2013 at 09:56:00PM +0200, Tom Wijsman wrote:
>>> There are a couple of other possible approaches...
>>> 
>>> 1) If the 2 systems can achieve peacefull co-existance (i.e.
>>> no identically-named files with different contents) then simply
>>> have 2 boot entries in /etc/lilo.conf (or grub equivalant)...
>>> 
>>> [SNIP to shorten mail]
>> 
>> Users can already do this, this isn't a solution.
>> 
>> We want to make this easier towards the user, therefore doing
>> heavy discussion to exhaust all the alternatives and maybe
>> someone's interested in implementing one of them that appears
>> most feasible.
> 
> Since users can already do this, why are we bothering with
> re-inventing the wheel? How does running an eselect init command
> make it easier for the user than telling them to edit their boot
> loader config file?
> 
> Gentoo users are expected to build their kernel and write their
> boot loader config file initially, so why are we trying to dumb
> this down?
> 
> William
> 

There is no harm in providing alternatives.

-- 
Regards,
Markos Chandras - Gentoo Linux Developer
http://dev.gentoo.org/~hwoarang

[gentoo-dev] Re: Re: eselect init

[Steven J. Long]

On Thu, Jun 20, 2013 at 03:48:29PM -0500, William Hubbs wrote:
> On Thu, Jun 20, 2013 at 06:10:27PM +0100, Steven J. Long wrote:
> > Fabio Erculiani wrote:
> > > - only init is currently handled by eselect-init, which is now using a
> > > very small wrapper POSIX shell script to redirect the calls to the
> > > currently running init
> > 
> > How does say, switching inittab format, work under this setup?
> 
> I think this is a separate issue -- if busybox init's inittab is a
> different format than sysvinbb's inittab, it should also use a different
> file name, e.g. bb-inittab or something similar.
> 
> bb could fall back to inittab, but I think it should look for something
> liike bb-inittab first. That way eselect init wouldn't have to worry
> about it at all.

You're missing the point, because of your usual monomania for specific rather
than general use-cases. 'Say' meant it was an example.

I asked the question, because AFAICT from reading the code, the proposed approach
keeps an indication of the running init, from startup, and then traps every call
to that init, to check whether eselect has in the interim changed the symlink to
point elsewhere.

If einit instead simply checked whether there was a 'switchto' file at startup,
it would be able to handle the more general problem, as well as running more
efficiently and robustly, with no need to mess around with symlinks.

The complexity would then be in eselect confirming, eg that the 'to' init is
installed and configured, before setting the file for the next reboot. And
optionally in the switcher when starting the new init at boot, if it should
need anything tricky carried out, which might interact badly with a currently
running init.

That's a re-iteration of Duncan's idea, ofc.

I'm also curious as to how an initramfs fits into the schema, given that there
may be things that need to be done before pid 1 is started (or if not, I have nfc
what all the discussion about replacing the kernel mechanism was in aid of.)

-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)