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 853E31381F3 for ; Sun, 23 Dec 2012 17:56:49 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 8076521C01D; Sun, 23 Dec 2012 17:56:29 +0000 (UTC) Received: from mail-ob0-f173.google.com (mail-ob0-f173.google.com [209.85.214.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id C9E4DE0477 for ; Sun, 23 Dec 2012 17:53:21 +0000 (UTC) Received: by mail-ob0-f173.google.com with SMTP id xn12so6163144obc.18 for ; Sun, 23 Dec 2012 09:53:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=X4UmbGPBdN3qpktuV9XzWOpePg7KSBCJntR354LQHME=; b=RrSh7uIPeZv8XLJeKwiiMOncdI1wfuQkW+G0HeMUt6/xyVZnJ/4T9gFu8pRNWwJtox inUzXGZfnjUnFMbW6YZf6jDGANYaWr3JYaS871EMJX7k8u2YQVPqzPNV+YihFUJ/dZ7q WvGsdBKP5cNgxHwRHQ9NjbjIB7QhxzTQPihz6ZVHvd5twRF/vbnJ3U0SXwQqbNVGRLJ+ GlbX6s7AFEq8hi6yue9U6g6+2WkGjXcEfwk0F8rjjLkHMsIx6/NYHPPzWlEJlEPEpvRo yAug5ssWZLLiaCN+G1zHlxU9nTBBSFjHs0Tz2vgN8Fgwa+va881mEBg1JsHmEQR0K+9X KwCw== Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Received: by 10.60.30.201 with SMTP id u9mr4328785oeh.28.1356285200223; Sun, 23 Dec 2012 09:53:20 -0800 (PST) Received: by 10.76.20.243 with HTTP; Sun, 23 Dec 2012 09:53:20 -0800 (PST) Received: by 10.76.20.243 with HTTP; Sun, 23 Dec 2012 09:53:20 -0800 (PST) In-Reply-To: <877go87jec.fsf@ist.utl.pt> References: <8738z7hgsa.fsf@ist.utl.pt> <20121216171043.71084070@khamul.example.com> <20121217104621.735bf43a@khamul.example.com> <20121218163332.7956f31a@khamul.example.com> <87txrd6pb3.fsf@ist.utl.pt> <20121223182037.1553813f@khamul.example.com> <87bodk7lb6.fsf@ist.utl.pt> <20121223172053.GB23711@acm.acm> <877go87jec.fsf@ist.utl.pt> Date: Sun, 23 Dec 2012 12:53:20 -0500 Message-ID: Subject: Re: [gentoo-user] Re: Anyone switched to eudev yet? From: Michael Mol To: gentoo-user@lists.gentoo.org Content-Type: multipart/alternative; boundary=e89a8ff1c58492cf3904d188c1f3 X-Archives-Salt: 7ceda8c3-c5d7-498c-99c5-4a9c4b585dab X-Archives-Hash: 9eeaf2b4de97e0fec352ed4f6410fd21 --e89a8ff1c58492cf3904d188c1f3 Content-Type: text/plain; charset=UTF-8 On Dec 23, 2012 12:46 PM, "Nuno J. Silva" wrote: > > On 2012-12-23, Alan Mackenzie wrote: > > > On Sun, Dec 23, 2012 at 07:03:25PM +0200, Nuno J. Silva wrote: > >> On 2012-12-23, Alan McKinnon wrote: > > > >> > On Sun, 23 Dec 2012 12:22:24 +0200 > >> > nunojsilva@ist.utl.pt (Nuno J. Silva) wrote: > > > >> >> On 2012-12-18, Alan McKinnon wrote: > > > >> >> > On Tue, 18 Dec 2012 09:08:53 -0500 > >> >> > Michael Mol wrote: > > > > > >> >> > This sentence summarizes my understanding of your post nicely: > > > >> >> >> Now, why is /usr special? It's because it contains executable code > >> >> >> the system might require while launching. > > > >> >> > Now there are only two approaches that could solve that problem: > > > >> >> > 1. Avoid it entirely > >> >> > 2. Deal with it using any of a variety of bootstrap techniques > > > >> >> > #1 is handled by policy, whereby any code the system might require > >> >> > while launching is not in /usr. > > > >> >> > #2 already has a solution, it's called an init*. Other solutions > >> >> > exist but none are as elegant as a throwaway temporary filesystem > >> >> > in RAM. > > > >> >> What about just mounting /usr as soon as the system boots? > > > > > >> > Please read the thread next time. The topic under discussion is > >> > solutions to the problem of not being able to do exactly that. > > > >> Then I suppose you can surely explain in a nutshell why can't init > >> scripts simply do that? > > > > Because certain people with influence have rearranged the filesystem so > > that programs within /usr are absolutely necessary for booting; they are > > needed _before_ init has a chance to mount /usr. So either /usr has to > > be in the root partition, or crazy kludges need to be used to mount /usr > > before the kernel runs init. > > I surely don't know the udev architecture well enough, but if this is > all done by the udev daemon, can't we just "mount /usr" before the > daemon is started? The only needed things should be mount (which is > under /bin here) and /etc/fstab. > > Or is something outside udev needing stuff under /usr? Yes. That's the pivot of the problem. > > -- > Nuno Silva (aka njsg) > http://njsg.sdf-eu.org/ > > --e89a8ff1c58492cf3904d188c1f3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Dec 23, 2012 12:46 PM, "Nuno J. Silva" <nunojsilva@ist.utl.pt> wrote:
>
> On 2012-12-23, Alan Mackenzie wrote:
>
> > On Sun, Dec 23, 2012 at 07:03:25PM +0200, Nuno J. Silva wrote: > >> On 2012-12-23, Alan McKinnon wrote:
> >
> >> > On Sun, 23 Dec 2012 12:22:24 +0200
> >> > nunojsilva@ist.= utl.pt (Nuno J. Silva) wrote:
> >
> >> >> On 2012-12-18, Alan McKinnon wrote:
> >
> >> >> > On Tue, 18 Dec 2012 09:08:53 -0500
> >> >> > Michael Mol <mikemol@gmail.com> wrote:
> >
> >
> >> >> > This sentence summarizes my understanding of yo= ur post nicely:
> >
> >> >> >> Now, why is /usr special? It's because = it contains executable code
> >> >> >> the system might require while launching. > >
> >> >> > Now there are only two approaches that could so= lve that problem:
> >
> >> >> > 1. Avoid it entirely
> >> >> > 2. Deal with it using any of a variety of boots= trap techniques
> >
> >> >> > #1 is handled by policy, whereby any code the s= ystem might require
> >> >> > while launching is not in /usr.
> >
> >> >> > #2 already has a solution, it's called an i= nit*. Other solutions
> >> >> > exist but none are as elegant as a throwaway te= mporary filesystem
> >> >> > in RAM.
> >
> >> >> What about just mounting /usr as soon as the system = boots?
> >
> >
> >> > Please read the thread next time. The topic under discus= sion is
> >> > solutions to the problem of not being able to do exactly= that.
> >
> >> Then I suppose you can surely explain in a nutshell why can&#= 39;t init
> >> scripts simply do that?
> >
> > Because certain people with influence have rearranged the filesys= tem so
> > that programs within /usr are absolutely necessary for booting; t= hey are
> > needed _before_ init has a chance to mount /usr. =C2=A0So either = /usr has to
> > be in the root partition, or crazy kludges need to be used to mou= nt /usr
> > before the kernel runs init.
>
> I surely don't know the udev architecture well enough, but if this= is
> all done by the udev daemon, can't we just "mount /usr" = before the
> daemon is started? The only needed things should be mount (which is > under /bin here) and /etc/fstab.
>
> Or is something outside udev needing stuff under /usr?

Yes. That's the pivot of the problem.

>
> --
> Nuno Silva (aka njsg)
> http://njsg.sdf-eu.org/
>
>

--e89a8ff1c58492cf3904d188c1f3--