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