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 <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. >
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
