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 1R3VGx-0003bo-6n for garchives@archives.gentoo.org; Tue, 13 Sep 2011 15:51:43 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 7033221C1AD; Tue, 13 Sep 2011 15:51:23 +0000 (UTC) Received: from mail.digimed.co.uk (82-69-83-178.dsl.in-addr.zen.co.uk [82.69.83.178]) by pigeon.gentoo.org (Postfix) with ESMTP id 807EE21C1A3 for ; Tue, 13 Sep 2011 15:49:26 +0000 (UTC) Received: from zaphod.digimed.co.uk (zaphod.digimed.co.uk [192.168.1.1]) by mail.digimed.co.uk (Postfix) with ESMTPSA id AC50180747 for ; Tue, 13 Sep 2011 16:49:25 +0100 (BST) Date: Tue, 13 Sep 2011 16:49:25 +0100 From: Neil Bothwick To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] udev + /usr Message-ID: <20110913164925.7f8e96a6@zaphod.digimed.co.uk> In-Reply-To: <20110913152122.GA18428@waltdnes.org> References: <20110912150248.GB3599@acm.acm> <2874055.6JTUjtRtEH@pc> <20110912171737.GC3599@acm.acm> <20110913032807.GB16644@waltdnes.org> <20110913080414.51e3df58@digimed.co.uk> <20110913152122.GA18428@waltdnes.org> Organization: Digital Media Production X-Mailer: Claws Mail 3.7.10cvs16 (GTK+ 2.24.6; x86_64-pc-linux-gnu) X-GPG-Fingerprint: 7260 0F33 97EC 2F1E 7667 FE37 BA6E 1A97 4375 1903 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 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/nnxpZveCP89ZOeN1MzCplTj"; protocol="application/pgp-signature" X-Archives-Salt: X-Archives-Hash: f4f5cf82a14080bfe7f03313f6282743 --Sig_/nnxpZveCP89ZOeN1MzCplTj Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Tue, 13 Sep 2011 11:21:22 -0400, Walter Dnes wrote: > > This is why the whole /usr issue is irrelevant and not a fix at all. > > All it does is avoid the most common breakages caused by udev trying > > to run all its rules too early in the boot process. Putting /var on / > > would "fix" your example, but what if a rule required access to an > > NFS mount? > >=20 > > Every time you fix one of these breakages, you are kludging around the > > real problem. =20 >=20 > How many people really need to run *ARBITRARY* binaries that early in > the boot process? The 1% who do shouldn't force the other 99% of us to > go with initramfs or a Windows C:\ drive. There is no 1%. The problem is that udev is able to run arbitrary binaries, which has its advantages, but it also has to be started early in the boot process to fulfil its other duties. It is trying to combine these two functions that leads to the need for more than / to be available before filesystems are mounted. --=20 Neil Bothwick Reboot America. --Sig_/nnxpZveCP89ZOeN1MzCplTj Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAk5ve4UACgkQum4al0N1GQNclACfSvQiU4pxNimH/eWrBZNMVAMV 9I8AoNbdfyTbI/gojNURdZWAwR5TAHww =R1Ya -----END PGP SIGNATURE----- --Sig_/nnxpZveCP89ZOeN1MzCplTj--