Rich Freeman wrote: > On Sun, Apr 8, 2012 at 6:04 PM, Greg KH <gre...@gentoo.org> 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":
<Betelgeuse> Chainsaw: So to clarify a universal initramfs is not enough? <Chainsaw> 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 ;-)
