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 1R1lid-0000gu-Q2 for garchives@archives.gentoo.org; Thu, 08 Sep 2011 21:01:08 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 4023321C2A3; Thu, 8 Sep 2011 21:00:44 +0000 (UTC) Received: from mail-ww0-f41.google.com (mail-ww0-f41.google.com [74.125.82.41]) by pigeon.gentoo.org (Postfix) with ESMTP id 1B1D721C29C for ; Thu, 8 Sep 2011 20:56:13 +0000 (UTC) Received: by wwi18 with SMTP id 18so1062147wwi.4 for ; Thu, 08 Sep 2011 13:56:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type:content-transfer-encoding; bh=l8RF3a+tMHljn3jfDmlLrefoq5JZfzM07aXbCy4/h/0=; b=YJ1pI4EsbUiPVtW/PbbkHABnE0U0BhUdb+FMYhSdDNwADOrrEGU8dLaBnotZUL44Wt WF4DsSdPN/Y83zUNhjcMt8ZOLL8Ad7kqnOei7gzXeUsS1B2YtnHHc9JIBxxa95szeRVM ljWcT9SEPMJ1bJt02XABTtXQ/tG/43TU/iAxQ= Received: by 10.216.221.129 with SMTP id r1mr1224102wep.49.1315515373249; Thu, 08 Sep 2011 13:56:13 -0700 (PDT) Received: from rohan (196-210-153-55.dynamic.isadsl.co.za [196.210.153.55]) by mx.google.com with ESMTPS id fq2sm5445686wbb.24.2011.09.08.13.56.10 (version=SSLv3 cipher=OTHER); Thu, 08 Sep 2011 13:56:12 -0700 (PDT) Date: Thu, 8 Sep 2011 22:56:07 +0200 From: Alan McKinnon To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] /dev/sda* missing at boot Message-ID: <20110908225607.4753ad57@rohan> In-Reply-To: <1589058.SM9yHjJMk3@pc> References: <201108191109.34984.michaelkintzios@gmail.com> <12534676.jn0Id4Zse9@pc> <20110908220536.55dd3798@rohan> <1589058.SM9yHjJMk3@pc> X-Mailer: Claws Mail 3.7.8 (GTK+ 2.24.4; x86_64-pc-linux-gnu) 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: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Archives-Salt: X-Archives-Hash: a183f297eb200fa06bcf1b2b0c4c521f On Thu, 08 Sep 2011 22:40:07 +0200 Michael Schreckenbauer wrote: > Am Donnerstag, 8. September 2011, 22:05:36 schrieb Alan McKinnon: > > On Thu, 08 Sep 2011 19:11:04 +0200 > > > > Michael Schreckenbauer wrote: > > > > Then design the correct solution and implement it. If it's > > > > technically sound, it will prevail. I think it's a rather > > > > complicated problem with a non trivial solution, but the code is > > > > there if you feel like give it a try. > > > > > > Where did I write, that I am in the position to write such a > > > beast? I only take the freedom to name this a design flaw in udev. > > > It needs things from userspace, which are not yet available at the > > > point it requests them. An initramsfs is a workaround for this, > > > not a proper fix. > > > > If that is the argument from the udev devs you just quoted, then I > > do not understand it at all. > > It's my understanding, that this is their point. > > > Why can there not be a restriction that udev may only run code in > > the traditional / space (i.e. it will not attempt to run code in > > the /usr or /home spaces)? > > Yes. I really wonder, why we have /bin, /sbin and /lib The / partition may contain, at a absolute minimum, only that software required to boot and start userspace. So you find mount, fsck and sh in there. Everything else that non-root users use routinely (and not required to boot and repair) is in /usr. The software on / splits into three logical categories: - code that only works when run as root in /sbin. Example: fsck - code that is required on /, but regular users may use it under normal circumstances, it cannot go in /sbin so it is in /bin. Example: mount - libraries, which go in /lib The distinction between bin and sbin is traditional and not really required. It comes from the days when resources were scarce and /bin and /sbin were a little too big combined to work efficiently. A nice side-effect is that /sbin could go in root's PATH so the code in it would not clutter up the user's space with tab-completion and which. This is not a security feature, just a convenience (same thinking as dot files). The same three directories exist under /usr, where the system package manager will maintain the contents. And the same three directories exist under /usr/local which is where the local sysadmin installs stuff he compiles himself and where the package manager won't touch it. Pre-compiled binaries such as Skype, Opera and database products go in /opt, completely contained in one directory tree (much like Windows and MacOS). This too is good as you can remove an entire product's files by deleting one directory tree without having to worry about all the places the files might be (the package manager is usually of no help in this). > > > Device nodes are a root function; root is the only user that should > > dictate how device nodes are created; root is the only user that can > > normally write to / and thereby create udev's rules and rulesets. > > > > In what valid way does access to /usr become something that udev > > may be required to support? > > As udev is able to run arbitrary scripts, there *might* be some code, > that requires something from /usr/*. So they want this beast be > mounted, before udev starts doing it's job. > > > Not arguing with *you* here Michael, just wondering about the > > validity of the position you quoted > > Understood :) > > Regards, > Michael > > -- Alan McKinnnon alan.mckinnon@gmail.com