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 884551381F3 for ; Mon, 24 Dec 2012 15:31:29 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 1A66E21C0DC; Mon, 24 Dec 2012 15:30:25 +0000 (UTC) Received: from mail-oa0-f42.google.com (mail-oa0-f42.google.com [209.85.219.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 7BCA221C0CF for ; Mon, 24 Dec 2012 15:27:41 +0000 (UTC) Received: by mail-oa0-f42.google.com with SMTP id j1so6898590oag.15 for ; Mon, 24 Dec 2012 07:27:40 -0800 (PST) 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; bh=s5l3WcAp02pTwPmSutme28QcqaI7jHVZ/hkzXG3RyL4=; b=c8Cu50/TQjD2QRfLFy5WwOBFjAeBHSEU1LJaUYKKCJSTX2axm/Dn0hb/yKEMj/JPSI ztQJS18M5qQMCaOPqa4IETlMfGBfHd+O24T33xOBX3ZpJKrHFu+keGWCMElRG827zxW7 E6VMoyt0SYbMsifbJZS4GvuIReW9DkMg3f8lZxN8pGUFzO9i1yKJwAlpWAi+CFfSip1V MZrYRX43bGh8RI4XUhRMiQQNT4rGkoywjT099FhuDqBkvmSjtEbDSm3303fB1Rct9sOI 3id+ff/4oVR2ZhZKgyvglot2iCSqtASnzqnccPMF0S2+3dQw+OKRjgO7GKFhGMzSCHP/ uIfg== 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 Received: by 10.182.226.103 with SMTP id rr7mr17816469obc.76.1356362860655; Mon, 24 Dec 2012 07:27:40 -0800 (PST) Received: by 10.76.20.243 with HTTP; Mon, 24 Dec 2012 07:27:40 -0800 (PST) In-Reply-To: <878v8n5w1q.fsf@ist.utl.pt> References: <50CB1942.3020900@gmail.com> <50CB4A3C.1030109@gmail.com> <50CB5406.7040404@gmail.com> <8738z7hgsa.fsf@ist.utl.pt> <20121216171043.71084070@khamul.example.com> <20121217104621.735bf43a@khamul.example.com> <20121218163332.7956f31a@khamul.example.com> <87txrd6pb3.fsf@ist.utl.pt> <20121223182037.1553813f@khamul.example.com> <87bodk7lb6.fsf@ist.utl.pt> <20121224085528.56f535ec@khamul.example.com> <50D85167.9060309@gmail.com> <50D85F68.609@gmail.com> <878v8n5w1q.fsf@ist.utl.pt> Date: Mon, 24 Dec 2012 10:27:40 -0500 Message-ID: Subject: Re: [gentoo-user] Re: Anyone switched to eudev yet? From: Michael Mol To: gentoo-user@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 X-Archives-Salt: 1075c0fe-53c0-436a-9e13-e77daa3c855b X-Archives-Hash: 733ae25252f2631443368cb6183d185b On Mon, Dec 24, 2012 at 10:06 AM, Nuno J. Silva wrote: > On 2012-12-24, Dale wrote: > [snip] >> Well, so far I have stuck with the udev that works without a init >> thingy. I do have a init thingy for when the udev that requires it is >> marked stable. The devs are keeping the udev that requires /usr on / >> masked and/or keyworded until everyone is ready. That was until eudev >> was announced. Now they are also waiting on eudev to get stable so >> people can switch to it. I plan to switch too. >> >> The problem is this from my understanding. For decades, any commands or >> config files needed to boot Linux had to be in /bin, /sbin, /etc, and/or >> /lib. Those directories were what was needed to boot and anything >> needed to boot a system should be installed into one or more of those >> directories. Then someone came up with the idea of putting things into >> /usr instead. When they did that, it broke things. To me, this change >> makes as much sense as putting the mount command is /usr/bin but that is >> where some want Linux to go. I have read where some want to basically >> move about everything to /usr but not sure how much traction that is >> getting. > > From my understanding, the problem with udev was that the rules used to > process events may require stuff from /usr. Which is OK, as I think the > rules may even end up executing random executables. And the sole problem > with this is that udev will not wait, it will simply fail in a silent > way when applying rules that require stuff from /usr. > > Now, also, from my understanding, this was already the case for some > time (maybe even years?). And that's why I've asked for more details. > > So, if the udev you use is OK with no initrd, what is in the new udev > that actually requires the initrd? > > Meanwhile, I found https://bugs.gentoo.org/show_bug.cgi?id=446372, which > would explain why, all of a sudden, there is a bigger problem. You found the answer to your own question. > Now, I > wonder how is this solved with an initrd, by copying udevd there? If so, > why don't we simply install udevd under (or copy its stuff to) / instead > of using /usr as $PREFIX? An initr* "solves" the problem by copying all tools necessary to reliably mount /usr to a temporary filesystem loaded at boot (and then discarded). As a solution, this 'works'. Opinions differ strongly on: * The weight of the burden it places on system administrators * The weight of reliability and security concerns which can arise from ** Increased maintenance complexity ** Having separate copies of tools ** Complications arising from maintaining multiple kernel versions on a system, and their corresponding supporting initr* tools. * The elegance of the solution > >> Basically, something that has worked for decades is declared to be >> broken all that time and if it wasn't broken, we are going to break it. > > ... yeah... the thing here is that I'm just trying to separate the > upstream comments on "separate /usr is broken" from the actual thing > that breaks the boot process. So far, even the stuff from freedesktop > I've read stating that "separate /usr is broken" do not seem to mention > that udevd is moving to /usr. Based on one or two emails on the -dev list (I'm really not sure; that list has been flying lately, and it's difficult for me to keep up right now), this may have been an individual action taken by the gentoo maintainer of udevd based on upstreams declaration that they don't give a flying frell about separate /usr contexts, and expect those scenarios to become more and more difficult. If that's the case, I can understand the maintainer's action; upstream mailing lists would let things break over time and respond to reports with "we don't support that configuration". The maintainer, not being superhuman, brought the problem to the foreground by putting udevd in a place such that the breakage is more up-front, concentrated and easier for him to mark reports as WONTFIX. The eudevd fork is intended to give people whose separate /usr configurations would fall under WONTFIX territory in udev a place to go. While there are certain to that cases where separate /usr without an initr* is fundamentally impossible, there's still a large number of cases where it ought to work, and more where its failure is the result of software bugs (either in code or in design). > >> From my understanding, if I upgrade my system to the later version of >> udev and bypass the init system, my system will not boot. I have not >> tested the theory but that is what people have been saying. Not only is >> my /usr separate but it is on LVM partitons too. > > Your problem would be LVM (if that's an issue at all, as I said I don't > know LVM), you'd not need udevd to mount /usr if it were a regular > partition. "you wouldn't have this problem if you did *something else*" is a terrible response. There are very good reasons to use LVM. There are good (IMO, at least) reasons to avoid using an initr* on Gentoo. (Those reasons are sprinkled through the thread, some spoken by me, some spoken by others.) You'll find most of the people in the discussion so far aren't against initr* in all cases. It's the increase in number of cases where it becomes technically required that's a problem. -- :wq