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 EBF5B1381F3 for ; Fri, 30 Aug 2013 14:56:51 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 1CB84E10BF; Fri, 30 Aug 2013 14:56:47 +0000 (UTC) Received: from mail-la0-f46.google.com (mail-la0-f46.google.com [209.85.215.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id C2396E10B4 for ; Fri, 30 Aug 2013 14:56:45 +0000 (UTC) Received: by mail-la0-f46.google.com with SMTP id eh20so1595723lab.5 for ; Fri, 30 Aug 2013 07:56:43 -0700 (PDT) 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:content-transfer-encoding; bh=RmIPwyphAslhoRRENX/vWFbVqDg8SpxyGCeLBqcHkIg=; b=vtUO7jmZxD1mOIgJOjcHqip8HdmZr9Ks8NZRqOp+tT5xye/LU/h7DL881M8PSyJebl JK2UPR8+3dJ0Nu8Uug+4lVTTl6g45hUObpxg5YsvsVwEcA+128hWQDNTmV1pP/8wEorw sf0QEjH5x+T1i0QJzJu+wQJIvtsEUUfeUEy90EWFNqvrIjo1qKabEuDLdj5ZgUtpUR30 RpSQDR6wDsX8BKjBvXTqb0iNaRDcnhfizFa+O+/pyZhi33URCiTyLSXm73Url2KyZub1 hTrqeSDxGBnP06EgXrPlsbsA9GybUGIdtDdZDMF3i8MLrBMdA0OZfii8LD4Ce9A4V2v1 B1IA== 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 X-Received: by 10.152.116.109 with SMTP id jv13mr8223903lab.30.1377874603800; Fri, 30 Aug 2013 07:56:43 -0700 (PDT) Received: by 10.114.96.2 with HTTP; Fri, 30 Aug 2013 07:56:43 -0700 (PDT) In-Reply-To: <5220AE1F.20601@libertytrek.org> References: <87r4dcbisz.fsf@nyu.edu> <87sixschz7.fsf@nyu.edu> <87wqn4ar3w.fsf@nyu.edu> <52203746.3090203@gmail.com> <522046B3.3060209@gmail.com> <5220A68D.1080407@libertytrek.org> <5220AE1F.20601@libertytrek.org> Date: Fri, 30 Aug 2013 09:56:43 -0500 Message-ID: Subject: Re: [gentoo-user] where did lvm installation guide go? From: =?UTF-8?B?Q2FuZWsgUGVsw6FleiBWYWxkw6lz?= To: gentoo-user@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 6d540a48-f3d3-4a6b-8c4d-1c83911cfda3 X-Archives-Hash: 0a99e43722fe2374fa17ff0cf5ee6421 On Fri, Aug 30, 2013 at 9:37 AM, Tanstaafl wrot= e: > On 2013-08-30 10:28 AM, Canek Pel=C3=A1ez Vald=C3=A9s = wrote: >> >> udev/eudev has nothing to do with it. It's the init systems (as in >> both systemd and OpenRC) the ones that are pushing/have pushed for >> dropping support for it. In Gentoo, the move is being championed by >> William Hubs: >> >> http://thread.gmane.org/gmane.linux.gentoo.project/2946 >> >> He's the OpenRC maintainer. NOBODY who has actually worked on the >> problem wants to support a separate /usr without an initramfs, because >> it makes no sense. > > > Please stop making such false statements. > > It only makes no sense because of *other* decisions being made that want = to > force files critical to booting to be placed into /usr. > > There is no *philosophical* reason that it 'makes no sense. I agree; it's because of technical reasons that it makes no sense. >> So it doesn't matter if you use udev, eudev, mdev or even a static >> /dev directory; no init system wants to support a separate /usr >> without an initramfs. > > > Just fyi... the *only* problem that I have with this is that I have an > *existing* system that has a separate /usr, and it only has that separate > /usr because when I followed the original gentoo installation handbook ba= ck > in 2003 or so, it actually had a separate /usr in the example directory > structure layout, so I thought it was the official gentoo *recommendation= * > to do it that way. > > If I wasn't in this predicament, I'd just make a mental note to never > install /usr to a separate partition and be done with it. > > >> And for a good reason: is braindead. > > > Again - it is only braindead if you accept the basic premise that it 'mak= es > sense' to put files critical to the boot process into /usr. > > Personally, I think it only 'makes sense' to put files critical to the bo= ot > process into /boot. What it's "critical" in the *general case*? It's NFS "critical"? It's bluetooth "critical"? It's the network "critical"? It's LVM "critical"? Are you going to put all of that in /boot or in /? An initramfs covers all those cases (and many more). It doesn't matter if some really simple cases could possible-perhaps-if-the-stars-align-maybe work; the devs cannot complicate the general case just to keep supporting some simple cases. The devs want a *GENERAL* solution, that works for everybody. That solution is an initramfs. Regards. --=20 Canek Pel=C3=A1ez Vald=C3=A9s Posgrado en Ciencia e Ingenier=C3=ADa de la Computaci=C3=B3n Universidad Nacional Aut=C3=B3noma de M=C3=A9xico