Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Gentoo Development (http://www.linux-archive.org/gentoo-development/)
-   -   Council meeting summary for 3 April 2012 (http://www.linux-archive.org/gentoo-development/654030-council-meeting-summary-3-april-2012-a.html)

Rich Freeman 04-08-2012 11:28 PM

Council meeting summary for 3 April 2012
 
On Sun, Apr 8, 2012 at 6:04 PM, Greg KH <gregkh@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).

> 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.

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.

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.

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.

Rich

Steven J Long 04-09-2012 06:09 PM

Council meeting summary for 3 April 2012
 
Rich Freeman wrote:

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

Zac Medico 04-09-2012 07:20 PM

Council meeting summary for 3 April 2012
 
On 04/09/2012 11:09 AM, Steven J Long wrote:

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)?


We've had some discussion on this before [1], and I've suggested to copy
the content of livecd/usb recovery disk onto a spare partition so that
you can boot into that if necessary. The advantage of using this
approach is that it eliminates the burden of maintaining the "/ is a
self-contained boot disk that's independent of /usr" use case.


[1]
http://archives.gentoo.org/gentoo-dev/msg_ceb908069aafdfff50e7f2d0732bf209.xml

--
Thanks,
Zac

William Hubbs 04-10-2012 06:45 PM

Council meeting summary for 3 April 2012
 
On Sun, Apr 08, 2012 at 03:04:22PM -0700, Greg KH wrote:
> On Sun, Apr 08, 2012 at 04:30:01PM +0200, Ulrich Mueller wrote:
> > New udev and separate /usr partition
> > ====================================
> > Decide on whether a separate /usr is still a supported configuration.
> > If it is, newer udev can not be stabled and alternatives should be
> > investigated. If it isn't, a lot of documentation will have to be
> > updated. (And an alternative should likely still be provided.)

There is no disagreement about whether or not separate /usr will be
supported. No one has said that you can't have a separate /usr
partition.

Was the council aware of the tracker bug we have open where we are
tracking the documentation changes explaining how to build an initramfs
if you have a separate /usr partition [1]?

Also, I am going to reiterate what Greg said. This is not an issue with
udev, but with the entire linux ecosystem.
There are binaries in /{bin,sbin} which link against libraries in
/usr/lib for example.

Also, with the appropriate documentation changes, which are being worked
on (see [1]), I feel that the statement above that newer udev can't be
stabled should be re-evaluated.

William

[1] https://bugs.gentoo.org/show_bug.cgi?id=407959

Steven J Long 04-11-2012 02:28 AM

Council meeting summary for 3 April 2012
 
Zac Medico wrote:

> On 04/09/2012 11:09 AM, Steven J Long wrote:
>> 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)?
>
> We've had some discussion on this before [1], and I've suggested to copy
> the content of livecd/usb recovery disk onto a spare partition so that
> you can boot into that if necessary. The advantage of using this
> approach is that it eliminates the burden of maintaining the "/ is a
> self-contained boot disk that's independent of /usr" use case.
>
It's a nice idea, and could also be done without an initramfs, ofc. You
mention configuring "initramfs to mount that as the root if something goes
wrong with your real root."

Thing is, for most desktop/laptop installs, if something goes wrong mounting
root from hard-disk, it's likely that booting into another partition will go
wrong too. It's pretty rare to get errors just on rootfs, that aren't to do
with the whole drive, and aren't fixed by fsck on a stable fs like ext3. (If
you do, you have to go to backups ofc, and would be wise to suspect the
whole drive.) At least, that's been my experience using separate partitions
for everything.

In that circumstance, if a rescue shell weren't available, (you're able to
boot the kernel or the the spare partition can't be booted to) I would just
boot the latest sysresccd that was around, if not able to download from
another box. If it were really that bad, I'd likely want to reinitialise any
failing partition, and would probably want a recent minimal install disk.

Boot up problems which need admin-work on Gentoo, ime, tend to be about
system upgrades not playing nicely, rather than the kernel unable to boot at
all (once you know which drivers you need for eg PCI/SATA drives built-in,
you usually are able to get at least root consistently, on an older kernel
if you're upgrading.)

Again, being able to boot into the machine, and have the rootfs at hand for
say dispatch-conf and rc-update, works nicely. A rescue partition would
effectively work the same as a live-disk, in that you'd need to do all the
chrooting etc afaics, and would need to be maintained to stay current.

I suppose you could script that, but again, it just seems like a lot of
bother to implement an "alternative" that doesn't actually gain anything
over the traditional setup (plus making sure that partitions are mounted
before udev starts.)

As for the burden of ensuring that binaries installed to /{s,}bin don't link
to libs in /usr, why not just automate a QA check for that, and let
developers decide whether a fix is necessary? After all, core packages that
do that even when configured with prefix and execprefix = /, aren't so
portable, and Gentoo has always championed "doing the right thing" wrt
helping upstream fix portability issues.

I realise "core" is subjective, but it amounts to "what our lovely devs
decide on for us" which is part of the reason you choose a distro, and the
trust you place in its developers.

--
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

Zac Medico 04-11-2012 04:09 AM

Council meeting summary for 3 April 2012
 
On 04/10/2012 07:28 PM, Steven J Long wrote:

I suppose you could script that, but again, it just seems like a lot of
bother to implement an "alternative" that doesn't actually gain anything
over the traditional setup (plus making sure that partitions are mounted
before udev starts.)


At least in the case of udev, we gain from not having to maintain a fork.


As for the burden of ensuring that binaries installed to /{s,}bin don't link
to libs in /usr, why not just automate a QA check for that, and let
developers decide whether a fix is necessary? After all, core packages that
do that even when configured with prefix and execprefix = /, aren't so
portable, and Gentoo has always championed "doing the right thing" wrt
helping upstream fix portability issues.


If the relevant ebuild developers really want to support that, it's fine
I guess. Hopefully that won't involve using static links as workarounds
for cross-/usr dependencies.

--
Thanks,
Zac

William Hubbs 04-11-2012 05:18 AM

Council meeting summary for 3 April 2012
 
On Tue, Apr 10, 2012 at 09:09:03PM -0700, Zac Medico wrote:
> On 04/10/2012 07:28 PM, Steven J Long wrote:
> > I suppose you could script that, but again, it just seems like a lot of
> > bother to implement an "alternative" that doesn't actually gain anything
> > over the traditional setup (plus making sure that partitions are mounted
> > before udev starts.)
>
> At least in the case of udev, we gain from not having to maintain a fork.
>
> > As for the burden of ensuring that binaries installed to /{s,}bin don't link
> > to libs in /usr, why not just automate a QA check for that, and let
> > developers decide whether a fix is necessary? After all, core packages that
> > do that even when configured with prefix and execprefix = /, aren't so
> > portable, and Gentoo has always championed "doing the right thing" wrt
> > helping upstream fix portability issues.
>
> If the relevant ebuild developers really want to support that, it's fine
> I guess. Hopefully that won't involve using static links as workarounds
> for cross-/usr dependencies.

Another issue to consider is binaries that want to access things in
/usr/share/*. If a binary in /{bin,sbin} needs to access something in
/usr/share/*, you have two choices. move the binary to /usr or move the
thing it wants to access to / somewhere which would involve creating
/share. Actually there is another choice, but I don't want to go there.
That would be writing patches.

The best way to solve all cross / - /usr dependencies imo is the /usr
merge (moving everything from /{bin,sbin,lib*} to the counterparts in
/usr), which has been discussed pretty extensively on this list, and
there hasn't been a lot of opposition to it.

William

Ralph Sennhauser 04-11-2012 09:34 AM

Council meeting summary for 3 April 2012
 
On Tue, 10 Apr 2012 13:45:04 -0500
William Hubbs <williamh@gentoo.org> wrote:

> On Sun, Apr 08, 2012 at 03:04:22PM -0700, Greg KH wrote:
> > On Sun, Apr 08, 2012 at 04:30:01PM +0200, Ulrich Mueller wrote:
> > > New udev and separate /usr partition
> > > ====================================
> > > Decide on whether a separate /usr is still a supported
> > > configuration. If it is, newer udev can not be stabled and
> > > alternatives should be investigated. If it isn't, a lot of
> > > documentation will have to be updated. (And an alternative should
> > > likely still be provided.)
>
> There is no disagreement about whether or not separate /usr will be
> supported. No one has said that you can't have a separate /usr
> partition.
>

Isn't meant /usr without initramfs, independent of how "broken" some
people precieve it?

> Was the council aware of the tracker bug we have open where we are
> tracking the documentation changes explaining how to build an
> initramfs if you have a separate /usr partition [1]?
>

That's an effort I welcome either way. So thanks for that.

> Also, I am going to reiterate what Greg said. This is not an issue
> with udev, but with the entire linux ecosystem.
> There are binaries in /{bin,sbin} which link against libraries in
> /usr/lib for example.
>

With udev-182 its no longer only the ecosystem which produce some
broken products but udev itself which is broken. Otherwise we would
have gone on like we always did, right?

> Also, with the appropriate documentation changes, which are being
> worked on (see [1]), I feel that the statement above that newer udev
> can't be stabled should be re-evaluated.
>

Long term newer udevs will be stabilized and I'm positive it wont take
as long as grub2 or portage-2.2 ;)

There is no particular hurry as far as I know so let's give Chainsaw
some time to look into an udev patch and don't go with the 30 day
with bug fixing rule.

Support for initramfs was rather poor until recently. For instance
dracut-0.17-r3 (haven't tested 0.18 so far) was the first to actually
produce a usable initramfs for me. Thus far I crafted them manually if
needed. Personally I would like to see the initramfs situation further
improved, this includes genkernel and dracut stable on all platforms and
then give it time to let the knowlage spread or alternatively an udev
patch which allows current setups to continue to work before the
council re-evaluates the udev stabilization again.

Cheers
Ralph

> William
>
> [1] https://bugs.gentoo.org/show_bug.cgi?id=407959

Rich Freeman 04-11-2012 11:44 AM

Council meeting summary for 3 April 2012
 
On Tue, Apr 10, 2012 at 10:28 PM, Steven J Long
<slong@rathaus.eclipse.co.uk> wrote:
> As for the burden of ensuring that binaries installed to /{s,}bin don't link
> to libs in /usr, why not just automate a QA check for that, and let
> developers decide whether a fix is necessary? After all, core packages that
> do that even when configured with prefix and execprefix = /, aren't so
> portable, and Gentoo has always championed "doing the right thing" wrt
> helping upstream fix portability issues.

The only issue with that logic is that upstream is perfectly aware of
what they're doing already, and bugs are likely to be closed as
WONTFIX. So, all the QA checks would do is ensure that we slowly
start maintaining forks of more and more packages. Right now the
problem is probably manageable, but I'm not convinced it will stay
that way. Once upstream developers consider all constraints to be
removed on their dependencies you could see a lot of stuff getting
pulled into root if you tried to enforce this rule.

In any case, it sounds like the directive is to keep limping along for
a while longer, and that makes sense anyway until docs/etc are
improved. I agree with Ralph's suggestion that the newer initramfs
tools should be stabilized as well.

Rich

Steven J Long 04-11-2012 02:13 PM

Council meeting summary for 3 April 2012
 
Zac Medico wrote:

> On 04/10/2012 07:28 PM, Steven J Long wrote:
>> I suppose you could script that, but again, it just seems like a lot of
>> bother to implement an "alternative" that doesn't actually gain anything
>> over the traditional setup (plus making sure that partitions are mounted
>> before udev starts.)
>
> At least in the case of udev, we gain from not having to maintain a fork.
>
"Making sure that partitions are mounted before udev starts" is a lot less
of an ask than setting up an initramfs, and changing the way we've worked
for years. It's what you proposed: an earlymounts init script, or patches to
Gentoo initscripts to do the same thing. Neither involves any patches to
udev proper, so no fork needs to be maintained.

>> As for the burden of ensuring that binaries installed to /{s,}bin don't
>> link to libs in /usr, why not just automate a QA check for that, and let
>> developers decide whether a fix is necessary? After all, core packages
>> that do that even when configured with prefix and execprefix = /, aren't
>> so portable, and Gentoo has always championed "doing the right thing" wrt
>> helping upstream fix portability issues.
>
> If the relevant ebuild developers really want to support that, it's fine
> I guess. Hopefully that won't involve using static links as workarounds
> for cross-/usr dependencies.

Well I for one wouldn't like that, so no argument there: it's only for where
the package would be definitely be considered for inclusion in a rescue-
disk/ initramfs/ partition, like say lvm2, mount or fsck. While you might
not always be able to access the manpages, a system admin would want at
least the binaries available.

I think it was mgorny who posted a check, which is why I brought it up.
Perhaps an opt-in check if some variable is set, would be better? That way,
only a maintainer who wants to mark the package as system-critical, and is
happy to deal with linkage issues for binaries (including just deciding that
some aren't so critical, which implies an optional exclusion variable, or
listing binaries that should be checked) would set it, in the interests of
overall portability and helping traditional users.

If a maintainer isn't interested, or upstream don't like it (ie won't accept
bugs with such a setup even when linkage is not the issue), there's no
additional burden.

Of course, if no developer thinks it's worth doing, the discussion is moot.
It would seem at the least useful, if not necessary, however, if Gentoo is
going to continue to support the traditional split /usr setup.

--
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)


All times are GMT. The time now is 05:39 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.