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 C44F61381F3 for ; Sun, 29 Sep 2013 06:06:51 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id CF689E0E0C; Sun, 29 Sep 2013 06:06:45 +0000 (UTC) Received: from ironport2-out.teksavvy.com (ironport2-out.teksavvy.com [206.248.154.182]) by pigeon.gentoo.org (Postfix) with ESMTP id D1346E0B59 for ; Sun, 29 Sep 2013 06:06:44 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABK/CFFFxI1U/2dsb2JhbABEvw4Xc4IeAQEEATocEgwKCwsYCRMSDwUlN4gLBgzBHQSNBIMlYQONfoRcgzKFfohwgV6DEw X-IPAS-Result: Av8EABK/CFFFxI1U/2dsb2JhbABEvw4Xc4IeAQEEATocEgwKCwsYCRMSDwUlN4gLBgzBHQSNBIMlYQONfoRcgzKFfohwgV6DEw X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="29347336" Received: from 69-196-141-84.dsl.teksavvy.com (HELO waltdnes.org) ([69.196.141.84]) by ironport2-out.teksavvy.com with SMTP; 29 Sep 2013 02:03:35 -0400 Received: by waltdnes.org (sSMTP sendmail emulation); Sun, 29 Sep 2013 02:06:34 -0400 From: "Walter Dnes" Date: Sun, 29 Sep 2013 02:06:34 -0400 To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Re: separate / and /usr to require initramfs 2013-11-01 Message-ID: <20130929060633.GB30380@waltdnes.org> References: <20130927222109.GD23408@server> <5246079E.7090406@gmail.com> <524759FB.2090304@gmail.com> 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-Disposition: inline In-Reply-To: <524759FB.2090304@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Archives-Salt: a42cb810-a419-4a7e-9ed2-c63a25034579 X-Archives-Hash: 3d2269bda3c239864a9504deb88195ce On Sun, Sep 29, 2013 at 12:36:43AM +0200, Alan McKinnon wrote > The actual problem is better stated something like this: > > In the early stages of user-land setup (around the time when udev is > getting it's act together), arbitrary code can run and that code can be > in any arbitrary place, but there is no guarantee that that code is even > accessible at the point when it is needed. The actual cause of this mess > is the lack of standards on where to put stuff on Linux systems, and it > forms a classic bootstrap problem. > > There has only ever been one way around that problem - define an exact > entry point that is guaranteed to be in a specific state. For current > userland this effectively means that everything that has traditionally > been in bin, sbin and lib in / and /usr must be available as step 1. > Technically, you could include /var/lib/ and maybe even /opt in there. > but we can safely exclude those at this time as only a brain-dead moron > would ever put init-critical code there. Separate /usr worked for many years, even with udev. The question I have is why is udev *NOW* monkeying around with a whole bunch of additional stuff before mounting partitions? If you have an NFS-mounted /usr, I can see needing to have network services running first. Ditto for /usr being in an LVM or encrypted partition, you need LVM and/or decryption running first. There is no excuse for anything else breaking a separate /usr. Then again, separate /usr isn't the first thing Kay Sievers has broken since he took over udev, and I wouldn't be surprised if he one day "just happens to break openrc"... https://lkml.org/lkml/2012/10/2/303 > From Linus Torvalds <> > Date Tue, 2 Oct 2012 09:33:03 -0700 > Subject Re: udev breakages - was: Re: Need of an ".async_probe()" > type of callback at driver's core - Was: Re: [PATCH] [media] drxk: > change it to use request_firmware_nowait() > On Tue, Oct 2, 2012 at 6:03 AM, Mauro Carvalho Chehab > wrote: > > > I basically tried a few different approaches, including deferred > > probe(), as you suggested, and request_firmware_async(), as Kay > > suggested. > > Stop this crazy. FIX UDEV ALREADY, DAMMIT. > > Who maintains udev these days? Is it Lennart/Kai, as part of systemd? > > Lennart/Kai, fix the udev regression already. Lennart was the one > who brought up kernel ABI regressions at some conference, and if > you now you have the *gall* to break udev in an incompatible manner > that requires basically impossible kernel changes for the kernel to > "fix" the udev interface, I don't know what to say. > > "Two-faced lying weasel" would be the most polite thing I could say. > But it almost certainly will involve a lot of cursing. > > > However, for 3.7 or 3.8, I think that the better is to revert > > changeset 177bc7dade38b5 and to stop with udev's insanity of > > requiring asynchronous firmware load during device driver > > initialization. If udev's developers are not willing to do that, > > we'll likely need to add something at the drivers core to trick > > udev for it to think that the modules got probed before the probe > > actually happens. > > The fact is, udev made new - and insane - rules that are simply > *invalid*. Modern udev is broken, and needs to be fixed. > > I don't know where the problem started in udev, but the report I > saw was that udev175 was fine, and udev182 was broken, and would > deadlock if module_init() did a request_firmware(). That kind of > nested behavior is absolutely *required* to work, in order to not > cause idiotic problems for the kernel for no good reason. > > What kind of insane udev maintainership do we have? And can we fix it? -- Walter Dnes I don't run "desktop environments"; I run useful applications