[gentoo-dev] Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012

[Steven J Long]

Rich Freeman wrote:

> On Sun, Apr 8, 2012 at 6:04 PM, Greg KH <gregkh@g.o> 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 ;-)