On Fri, Jun 21, 2013 at 05:13:33PM +0100, Markos Chandras wrote: > On 21 June 2013 16:29, Michał Górny <mgo...@gentoo.org> wrote: > > Dnia 2013-06-21, o godz. 10:16:10 > > William Hubbs <willi...@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
signature.asc
Description: Digital signature
