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 1SHJ0C-0001qV-HI for garchives@archives.gentoo.org; Mon, 09 Apr 2012 18:07:44 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 0D069E0CE7; Mon, 9 Apr 2012 18:07:17 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 35063E0B1F for ; Mon, 9 Apr 2012 18:06:25 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id B88761B40BF for ; Mon, 9 Apr 2012 18:06:24 +0000 (UTC) X-Virus-Scanned: by amavisd-new using ClamAV at gentoo.org X-Spam-Flag: NO X-Spam-Score: -2.005 X-Spam-Level: X-Spam-Status: No, score=-2.005 tagged_above=-999 required=5.5 tests=[AWL=-1.257, BAYES_00=-1.9, RCVD_NUMERIC_HELO=1.164, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from smtp.gentoo.org ([127.0.0.1]) by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UOEU1DQO-z5Y for ; Mon, 9 Apr 2012 18:06:17 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTPS id 4F1891B4023 for ; Mon, 9 Apr 2012 18:06:14 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1SHIyg-0002Rl-DC for gentoo-dev@gentoo.org; Mon, 09 Apr 2012 20:06:10 +0200 Received: from 109.176.235.157 ([109.176.235.157]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 09 Apr 2012 20:06:10 +0200 Received: from slong by 109.176.235.157 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 09 Apr 2012 20:06:10 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Steven J Long Subject: [gentoo-dev] Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012 Date: Mon, 09 Apr 2012 19:09:09 +0100 Organization: Friendly-Coders Message-ID: References: <20353.41193.129711.306663@a1i15.kph.uni-mainz.de> <20120408220422.GA26440@kroah.com> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7Bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 109.176.235.157 X-Archives-Salt: 7845dec1-475e-4692-aba9-392e83a77a68 X-Archives-Hash: c82451fadabd440402161a67ddc251bf Rich Freeman wrote: > On Sun, Apr 8, 2012 at 6:04 PM, Greg KH wrote: >> On Sun, Apr 08, 2012 at 04:30:01PM +0200, Ulrich Mueller wrote: > >>> The council has voted in favour of a separate /usr being supported >>> (5 yes, 1 no vote). >> >> What? > > Perhaps the council should be the ones to clarify, but I think the > vote only was for separate /usr being supported. The irc log seemed a > bit more nuanced than perhaps came out in the summary. Maybe I'm > misreading it. I didn't see anything in the log about a decision that > newer versions of udev are not able to be stabled. > > So, as to what "a separate /usr being supported" means, the impression > I got was "don't worry if you're running it, you'll have an upgrade > path." Right now it sounds like the proposed upgrade path is that > some devs will fork udev and keep it running more like the current one > (presumably breaking in the same situations that it already does > today). > Well I definitely read it as "supported without an initramfs": Chainsaw: So to clarify a universal initramfs is not enough? Betelgeuse: No. Otherwise there is no contention, nor need to consider patches. >> And udev isn't even the problem, all you need is to mount your /usr from >> initramfs. So, the original proposal wasn't even a correct/valid >> proposal in the first place. > If udev simply requires partitions mounted before it is started, that allows those of us who don't need udev to get partitions mounted (still not sure how that works if you do) to continue with initscript-based approaches (eg those mentioned at end.) > Well, as far as I can tell the proposal that was voted on didn't even > mention udev at all, or initramfs. But, as you point out using an > initramfs is likely to be more reliable. > As above, the discussion prior certainly mentioned initramfs, and being able not to use one seems to be a requirement, or there'd be no need to talk about "forking" udev to maintain the old behaviour (which I believe is the ability to retry failed scripts in udev-postmount, which ideally requires udev to distinguish between failures due to file not found, and true failures.) > I'm sure the same arguments were going around back when people were > advocating for dropping bootloader support in the kernel and telling > people to bugger_off_msg. An initramfs creates more flexibility, at > the cost of an extra layer of software, just like grub. The main > downside to it is that it tends to require more maintenance, though if > you build the necessary drivers to mount /usr into the kernel I > imagine that an initramfs would probably work across differing kernel > versions. > One thing that has bothered me with the mooting of an initramfs as the new rescue system that rootfs has traditionally been, is at the we are told at the same time that the initramfs can be very minimal. If so, how does it provide the same capabilities as rootfs (for those of us who can localmount without udev-configured devices)? > In any case, we should still be updating documentation/etc regardless. > A better guide to dracut/genkernel would be useful no matter how this > turns out. I'd like to see stable Gentoo stay current with udev in > any case, but I don't mind using a forked version as long as it is of > similar quality to the original. As you've pointed out already, that > may not actually help people with a separate /usr, so I'd encourage > people to get an initramfs working. > There are two alternatives currently on the forums which don't require an initramfs, nor patches to udev. earlymounts[1] is an initscript which runs before udev in sysinit, which appears to be having teething troubles eg with fsck, and I have posted an approach[2] which allows udev to start after localmount, ie in the manner it used to, which has no problems with fsck, but is trickier to setup. Of course, neither of these can be used if you have root on lvm or encrypted partitions, ie the cases which traditionally required an initrd, or if you have need of udev-configured devices to get through localmount. [1] http://forums.gentoo.org/viewtopic-t-918466.html [2] http://forums.gentoo.org/viewtopic-t-901206.html -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)