From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1R4GhV-0007Zo-2Q for garchives@archives.gentoo.org; Thu, 15 Sep 2011 18:30:17 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 8FE8021C2D2; Thu, 15 Sep 2011 18:30:07 +0000 (UTC) Received: from mail-bw0-f53.google.com (mail-bw0-f53.google.com [209.85.214.53]) by pigeon.gentoo.org (Postfix) with ESMTP id A10C121C2AB for ; Thu, 15 Sep 2011 18:29:21 +0000 (UTC) Received: by bkbzt12 with SMTP id zt12so3763908bkb.40 for ; Thu, 15 Sep 2011 11:29:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=R949uRl3PhR3z2Y1DlXP5F9aK4CzpM3igXWPTSAQvHk=; b=wim8jp+UoDPBMfRex+jYgTdyp2rs5B8pOPsM3gCA8cecSXec3scgdMtz69dkNQMmWm 6PJmNGgViJYMFW3flTChpCrDoZ+EpqOozg60PzBYRr97tO5cyprksTpixaAyWDuoFAq/ 4QmeN8grkhzZfULqvWUB9vMJds0BzyQ6JCKv0= 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 Received: by 10.204.142.219 with SMTP id r27mr929543bku.403.1316111360741; Thu, 15 Sep 2011 11:29:20 -0700 (PDT) Sender: freemanrich@gmail.com Received: by 10.204.143.67 with HTTP; Thu, 15 Sep 2011 11:29:20 -0700 (PDT) In-Reply-To: <4E7214B7.9010406@gentoo.org> References: <1740055.XA9oyAS8HQ@eve> <4E7214B7.9010406@gentoo.org> Date: Thu, 15 Sep 2011 14:29:20 -0400 X-Google-Sender-Auth: CzjIEOg0RKiuPym7Ilwg1BegWHI Message-ID: Subject: Re: [gentoo-dev] udev and /usr From: Rich Freeman To: gentoo-dev@lists.gentoo.org Content-Type: multipart/alternative; boundary=0015174c0d5e24522104acff0edb X-Archives-Salt: X-Archives-Hash: 98e3d98cb5b999b0f92e4294ad37d576 --0015174c0d5e24522104acff0edb Content-Type: text/plain; charset=ISO-8859-1 On Thu, Sep 15, 2011 at 11:07 AM, Zac Medico wrote: > On 09/15/2011 07:33 AM, Joost Roeleveld wrote: > > The use for an initrd/initramfs/... will create an additional layer of > > complexity a lot of us users are not really waiting for, especially as we > are > > not seeing any issues with our current systems. > > Like it or not, it's the simplest possible solution if you want separate > /usr. The plan is to provide a minimal initramfs that won't contain any > modules, so it won't have to be rebuilt for each kernel. See the "/usr > vs. initramfs redux" thread: > > It should be noted that the alternative is to use a more full-featured initramfs like dracut, which will also be updated to support mounting /usr (it already parses /etc/fstab to remount root anyway). The minimal initramfs will not contain mdadm or lvm tools, so it is basically suitable for booting systems that don't currently require an initramfs. Of course, something like dracut is more likely to require you to rebuild the initramfs every time you update your kernel, and won't simply be a static image like the simplified one. The simplified initramfs could be compiled into the kernel as Zac suggests (this is probably the most foolproof method), or it could be loaded from /boot using the appropriate grub settings. Note that dracut does drop you to a shell if it fails (this is configurable), but by default this shell is dash, not bash. No doubt it would work fine either way, but bash is likely to be a little slower. I don't think RAM use is likely to be a problem - it should be completely de-allocated before init runs. --0015174c0d5e24522104acff0edb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Sep 15, 2011 at 11:07 AM, Zac Medico <zmedico@gentoo.org> wrote:
=
On 09/15/2011 07:33 AM, Joost Roeleveld wrote:
> The use for an initrd/initramfs/... will create an additional layer of=
> complexity a lot of us users are not really waiting for, especially as= we are
> not seeing any issues with our current systems.

Like it or not, it's the simplest possible solution if you want s= eparate
/usr. The plan is to provide a minimal initramfs that won't contain any=
modules, so it won't have to be rebuilt for each kernel. See the "= /usr
vs. initramfs redux" thread:


I= t should be noted that the alternative is to use a more full-featured initr= amfs like dracut, which will also be updated to support mounting /usr (it a= lready parses /etc/fstab to remount root anyway). =A0

The minimal initramfs will not contain mdadm or lvm too= ls, so it is basically suitable for booting systems that don't currentl= y require an initramfs. =A0Of course, something like dracut is more likely = to require you to rebuild the initramfs every time you update your kernel, = and won't simply be a static image like the simplified one. =A0

The simplified initramfs could be compiled into the ker= nel as Zac suggests (this is probably the most foolproof method), or it cou= ld be loaded from /boot using the appropriate grub settings.

Note that dracut does drop you to a shell if it fails (this = is configurable), but by default this shell is dash, not bash. =A0No doubt = it would work fine either way, but bash is likely to be a little slower. = =A0I don't think RAM use is likely to be a problem - it should be compl= etely de-allocated before init runs.

--0015174c0d5e24522104acff0edb--