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 1R3Afh-0007Eb-Re for garchives@archives.gentoo.org; Mon, 12 Sep 2011 17:51:54 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 7044621C0C2; Mon, 12 Sep 2011 17:51:39 +0000 (UTC) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by pigeon.gentoo.org (Postfix) with SMTP id 6D4E221C068 for ; Mon, 12 Sep 2011 17:50:17 +0000 (UTC) Received: (qmail invoked by alias); 12 Sep 2011 17:50:16 -0000 Received: from p5B083DA8.dip.t-dialin.net (EHLO pc.localnet) [91.8.61.168] by mail.gmx.net (mp015) with SMTP; 12 Sep 2011 19:50:16 +0200 X-Authenticated: #13997268 X-Provags-ID: V01U2FsdGVkX1+cXyRnF4Scb1TDG46Tzgep9PXWH5E9++CN1OXi4E HgmreAXt6QhJhU From: Michael Schreckenbauer To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] udev + /usr Date: Mon, 12 Sep 2011 19:50:13 +0200 Message-ID: <1469353.CZnlx9uQzD@pc> User-Agent: KMail/4.7.1 (Linux/2.6.38-gentoo; KDE/4.7.1; x86_64; ; ) In-Reply-To: <20110912171737.GC3599@acm.acm> References: <20110912150248.GB3599@acm.acm> <2874055.6JTUjtRtEH@pc> <20110912171737.GC3599@acm.acm> 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-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Y-GMX-Trusted: 0 X-Archives-Salt: X-Archives-Hash: f7c2d75071e0530ea0b1a910be585463 Hi Alan, On Monday, 12. September 2011 17:17:37 Alan Mackenzie wrote: > Hi, Michael. > > On Mon, Sep 12, 2011 at 05:33:34PM +0200, Michael Schreckenbauer wrote: > > Hi Alan, > > > > On Monday, 12. September 2011 15:02:48 Alan Mackenzie wrote: > > > Hope nobody minds me starting a new thread with an accurate name. > > > > > > Which version of udev is it that has this nauseating feature of > > > needing > > > /usr loaded to boot? > > > > > > Somewhere in that version's source will be several (or lots of) > > > "/usr". > > > Just how difficult is it going to be to replace "/usr/bin" with > > > "/bin" > > > throughout the source? > > > > you misunderstood something. udev is able to run arbitrary scripts. Some > > of those scripts are located in /usr/* or need something there. I doubt > > you will find references to /usr in the udev-sources. > > Well, I'm a hacker. udev is free source, therefore fair game. I don't > intend to put up with this nonsense without a fight. As far as I can > make out, this is just one guy, Kay Sievers, who's on a power trip. Are > there any indications at all that he actually talked to anybody in the > wide world before making such a far reaching decision? > On my current system, udev (164-r2) works without an earlily loaded /usr. > Seemingly, later versions don't. That was why I was asking for somebody > to identify one of these later versions for me. it works for you, because your udev-rules need nothing from /usr/* It's *not* udev requiring /usr, it's the scripts triggered by the rules. > > > udev is part of the kernel. > > > > No. udev is usperspace. > > OK, udev is in userspace, _very_ _close_ to the kernel. ;-) > > > > How come the kernel hackers aren't up in arms about this as much as > > > we are? Or are they, maybe? In which case, maybe the kernel people > > > would welcome an option to disrequire the early mounting of /usr as > > > much as we would. > > > > > > Anyhow, I'd like to take a peek at the source code which does this > > > evil > > > thing. Would somebody please tell me which version of udev is > > > involved.> > > Every udev version works this way. > > My udev (164-r2) is just fine at the moment. I'm not sure what you mean > by that statement. It works for you. Every udev-version I know of, is able to run any script you like it to. > > Fixing udev to continue working with separate /usr is far from trivial > > imo. Changing some paths is not the way to go for sure. > > Maybe, maybe not. No, I wrote "for sure", because I *know* this. > But it seems a changing of paths (/ -> /usr) is > precisely what is breaking newer udevs. No, it is *not* > It might be possible to change > them back. This could involve moving a fair amount of stuff from /usr to > /, but not half as much as moving the entire /usr partition. Again, udev can run arbitrary scripts. > > First of all, udev has to distinguish between "device not present" and > > "script error of some kind". Failing scripts have to be queued somehow > > for later execution. If a script keeps failing, it has to be removed > > from that queue, with a message to syslog or something like that. If > > udev needs a script in /usr/* to mount /usr then there's a > > chicken-egg-problem, which could be hard to solve (if possible at all > > without moving things from /usr/ to /). Note, that I am wild guessing > > here, I did not study the udev sources or any related script/rule :) > > This sounds like a separate (if related) problem. No, this *is* the problem.Canek has posted some links in the other thread, some other guy, I have forgotten who it was, posted others. If interested read them. I really don't want to offend you, but unless you understand, how things work and what the problem is, don't waste your time looking at udev's sources. Best, Michael