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