From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 4B4E11381F3 for ; Fri, 21 Jun 2013 19:36:47 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 33819E0B61; Fri, 21 Jun 2013 19:36:41 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 51B2EE0B32 for ; Fri, 21 Jun 2013 19:36:40 +0000 (UTC) Received: from [192.168.0.95] (dynamic-adsl-84-220-166-175.clienti.tiscali.it [84.220.166.175]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: lu_zero) by smtp.gentoo.org (Postfix) with ESMTPSA id 8BBFE33E2B1 for ; Fri, 21 Jun 2013 19:36:38 +0000 (UTC) Message-ID: <51C4AB4A.9050604@gentoo.org> Date: Fri, 21 Jun 2013 21:36:42 +0200 From: Luca Barbato User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130411 Thunderbird/17.0.5 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] eselect init References: <51A08A68.3020900@gentoo.org> <20130620205609.GB23719@linux1> <20130621043959.7eae0921@gentoo.org> <20130621041600.GA24770@linux1> <20130621122328.662eddc0@gentoo.org> <20130621151610.GA26281@linux1> <20130621172941.1dd87fd1@gentoo.org> <20130621165045.GB26775@linux1> In-Reply-To: <20130621165045.GB26775@linux1> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Archives-Salt: b13a1f96-45fc-4fe0-9591-889348717d7f X-Archives-Hash: e2244d0ad190f80c99aa9d3e15fb3d79 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 wrote: >>> Dnia 2013-06-21, o godz. 10:16:10 >>> William Hubbs 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