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 <gentoo-dev+bounces-47621-garchives=archives.gentoo.org@lists.gentoo.org>)
id 1R4IYO-0005ak-Pf
for garchives@archives.gentoo.org; Thu, 15 Sep 2011 20:29:01 +0000
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id 69D5121C1E5;
Thu, 15 Sep 2011 20:28:42 +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 2F9F921C0DC
for <gentoo-dev@lists.gentoo.org>; Thu, 15 Sep 2011 20:27:35 +0000 (UTC)
Received: by bkbzt12 with SMTP id zt12so3876675bkb.40
for <gentoo-dev@lists.gentoo.org>; Thu, 15 Sep 2011 13:27:35 -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=/YZh/Cc060NdmnQ4jXQ1yVBTc2uDKIe/xylgkJOubV0=;
b=hm+p5FDIQtXT5SE7H9tPOUal7mGB+cTKBLagjhCs80p4L+ncuew9c68bs+tCi6zGld
8oQA8EZFMUuRlPkSdgIYB7xK7VEf/bYerfRWMJcRnoLG55FfSszOm+qvmrZZL+/40+Fp
f+zCr8gEV3trLCsvKfyoG7fARiWWSiBHrtjFI=
Precedence: bulk
List-Post: <mailto:gentoo-dev@lists.gentoo.org>
List-Help: <mailto:gentoo-dev+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org>
X-BeenThere: gentoo-dev@lists.gentoo.org
Reply-to: gentoo-dev@lists.gentoo.org
MIME-Version: 1.0
Received: by 10.204.140.131 with SMTP id i3mr1006544bku.351.1316118455353;
Thu, 15 Sep 2011 13:27:35 -0700 (PDT)
Sender: freemanrich@gmail.com
Received: by 10.204.143.67 with HTTP; Thu, 15 Sep 2011 13:27:35 -0700 (PDT)
In-Reply-To: <1779916.3DFgxt01uS@eve>
References: <1740055.XA9oyAS8HQ@eve>
<3639422.QgOtQNiHae@eve>
<4E72275A.9000704@gentoo.org>
<1779916.3DFgxt01uS@eve>
Date: Thu, 15 Sep 2011 16:27:35 -0400
X-Google-Sender-Auth: Bl_bfsOhtI10BnslqKLMPaubFA8
Message-ID: <CAGfcS_mSLdjabAXJDPKkJOp6yL+RmpzUUfD=tNgsf5Q8PWLYww@mail.gmail.com>
Subject: Re: [gentoo-dev] udev and /usr
From: Rich Freeman <rich0@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Content-Type: multipart/alternative; boundary=00151747810e0380eb04ad00b569
X-Archives-Salt:
X-Archives-Hash: a551033c2b31956703b04cd6f0d5902d
--00151747810e0380eb04ad00b569
Content-Type: text/plain; charset=ISO-8859-1
On Thu, Sep 15, 2011 at 4:03 PM, Joost Roeleveld <joost@antarean.org> wrote:
> On Thursday, September 15, 2011 09:27:06 AM Zac Medico wrote:
> > It should be similar to how sys-apps/v86d is used for uvesafb support.
> > It installs /usr/share/v86d/initramfs and when you configure your
> > kernel, you set CONFIG_INITRAMFS_SOURCE="/usr/share/v86d/initramfs" in
> > order to have in included in your kernel image.
>
> Will this be set somewhere globally to the initramfs automatically?
> And doesn't this mean that a new kernel will need to be build just to
> satisfy
> this?
>
> I'm trying to think of how best to avoid users who are not aware to get
> caught
> with non-booting systems.
>
> Wouldn't automatic inclusion into grub.conf be a better approach? Not sure
> if
> grub.conf can handle a "global" setting for initramfs.
>
>
Well, the only way to set a kernel config parameter is to rebuild the
kernel. There might be some way to extract the built-in initramfs (every
kernel has one) and replace it with the new one without rebuilding it, but I
doubt most users would prefer that we mount /boot and start modifying their
kernel images.
Changes to grub.conf will only be properly merged if /boot is mounted, if
grub is installed (don't laugh - I checked and since my system was migrated
so many times I don't actually have the package installed any longer), and
the user actually merges the changes in. Fiddling with grub.conf isn't
exactly risk-free either.
I think something like this is best handled via news.
Note also that depending on your definition of "broken" the separate /usr
situation is already broken. It will probably steadily become more broken
over time, so when it stops booting altogether for any particular user might
happen anytime from a year ago to never.
Rich
--00151747810e0380eb04ad00b569
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Thu, Sep 15, 2011 at 4:03 PM, Joost Roeleveld <span dir=3D"ltr"><<a h=
ref=3D"mailto:joost@antarean.org">joost@antarean.org</a>></span> wrote:<=
br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class=3D"im">On Thursday, September 15, 2011 09:27:06 AM Zac Medico wr=
ote:<br>> It should be similar to how sys-apps/v86d is used for uvesafb =
support.<br>
> It installs /usr/share/v86d/initramfs and when you configure your<br>
> kernel, you set CONFIG_INITRAMFS_SOURCE=3D"/usr/share/v86d/initra=
mfs" in<br>
> order to have in included in your kernel image.<br>
<br>
</div>Will this be set somewhere globally to the initramfs automatically?<b=
r>
And doesn't this mean that a new kernel will need to be build just to s=
atisfy<br>
this?<br>
<br>
I'm trying to think of how best to avoid users who are not aware to get=
caught<br>
with non-booting systems.<br>
<br>
Wouldn't automatic inclusion into grub.conf be a better approach? Not s=
ure if<br>
grub.conf can handle a "global" setting for initramfs.<br>
<div class=3D"im"><br></div></blockquote><div><br></div><div>Well, the only=
way to set a kernel config parameter is to rebuild the kernel. =A0There mi=
ght be some way to extract the built-in initramfs (every kernel has one) an=
d replace it with the new one without rebuilding it, but I doubt most users=
would prefer that we mount /boot and start modifying their kernel images. =
=A0</div>
<div><br></div><div>Changes to grub.conf will only be properly merged if /b=
oot is mounted, if grub is installed (don't laugh - I checked and since=
my system was migrated so many times I don't actually have the package=
installed any longer), and the user actually merges the changes in. =A0Fid=
dling with grub.conf isn't exactly risk-free either.</div>
<div><br></div><div>I think something like this is best handled via news.</=
div><div><br></div><div>Note also that depending on your definition of &quo=
t;broken" the separate /usr situation is already broken. =A0It will pr=
obably steadily become more broken over time, so when it stops booting alto=
gether for any particular user might happen anytime from a year ago to neve=
r.</div>
<div><br></div><div>Rich</div></div>
--00151747810e0380eb04ad00b569--