Re: [gentoo-dev] eselect init

[Luca Barbato <lu_zero@gentoo.org>]

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