1 |
On 06/21/2013 06:50 PM, William Hubbs wrote: |
2 |
> On Fri, Jun 21, 2013 at 05:13:33PM +0100, Markos Chandras wrote: |
3 |
>> On 21 June 2013 16:29, Michał Górny <mgorny@g.o> wrote: |
4 |
>>> Dnia 2013-06-21, o godz. 10:16:10 |
5 |
>>> William Hubbs <williamh@g.o> napisał(a): |
6 |
>>> |
7 |
>>>> On Fri, Jun 21, 2013 at 12:23:28PM +0200, Michał Górny wrote: |
8 |
>>>>>> If eselect-init installs the wrapper as /sbin/einit, we don't have to |
9 |
>>>>>> touch /sbin/init at all, then, the only thing someone would have to do |
10 |
>>>>>> is to add an entry to their boot loader with init=/sbin/einit on the kcl |
11 |
>>>>>> to use it. |
12 |
>>>>> |
13 |
>>>>> But *if* the wrapper fails to run somehow, e.g. becomes broken, |
14 |
>>>>> the kernel will fallback to the standard location. |
15 |
>>>> |
16 |
>>>> Yes, but if the wrapper replaces /sbin/init, like it does now, and the |
17 |
>>>> wrapper gets broken, I think you are left with an unbootable system. |
18 |
>>> |
19 |
>>> Then kernel falls back to safe /bin/sh which is a minimal safe fallback. |
20 |
>>> |
21 |
>>> -- |
22 |
>>> Best regards, |
23 |
>>> Michał Górny |
24 |
>> |
25 |
>> Correct. Even if your init end up being broken you end up with a shell |
26 |
>> so you can fix things yourself. |
27 |
> |
28 |
> The case we are ignoring here is the indirection in the wrapper. e.g. |
29 |
> the wrapper, /sbin/init is a valid process, but the process it tries to |
30 |
> run, say /bin/foobar, is not. |
31 |
> |
32 |
> I'm thinking that no matter where we put the wrapper, either as a custom |
33 |
> version of /sbin/init or as something like /bin/einit, once the kernel |
34 |
> hands things off to the wrapper, if the wrapper fails to run the |
35 |
> executable it is directed to run, we are hosed. |
36 |
> |
37 |
|
38 |
I asked to mgorny to try that already, and he did and reported already, |
39 |
you can try for yourself and see what happens. |
40 |
|
41 |
lu - no, I won't tell what happens so you will try for yourself |