Mailing List Archive: Gentoo: Dev

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

1 2

View All

Index | Next | Previous | View Threaded

gregkh at gentoo

Apr 8, 2012, 3:04 PM

Post #1 of 43 (358 views)
Permalink

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

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.)
>
> The council has voted in favour of a separate /usr being supported
> (5 yes, 1 no vote).

What?

> During the discussion, some concerns were raised that we might not be
> able to provide a modified or forked udev version. Chainsaw assured
> that if necessary, he will maintain a udev version that supports said
> configuration.

It isn't udev that is the problem here, it's the loads of other
packages. udev is just being "nice" and pointing out that the user has
a problem.

> It was remarked that a solution that comprises both the forked udev
> version (separate /usr) and the latest versions is possible and
> therefore should not block either way preferred by users.

How in the world are you going to support this type of thing, when it
isn't udev that is the issue?

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.

Papering over the issue, by just keeping udev from reporting the
problem is NOT a valid solution. You are shooting the messenger here.

greg k-h

rich0 at gentoo

Apr 8, 2012, 4:28 PM

Post #2 of 43 (356 views)
Permalink

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

On Sun, Apr 8, 2012 at 6:04 PM, Greg KH <gregkh [at] gentoo> 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

slong at rathaus

Apr 9, 2012, 11:09 AM

Post #3 of 43 (350 views)
Permalink

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

Rich Freeman wrote:

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

zmedico at gentoo

Apr 9, 2012, 12:20 PM

Post #4 of 43 (351 views)
Permalink

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

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

williamh at gentoo

Apr 10, 2012, 11:45 AM

Post #5 of 43 (348 views)
Permalink

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

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

slong at rathaus

Apr 10, 2012, 7:28 PM

Post #6 of 43 (345 views)
Permalink

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

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

zmedico at gentoo

Apr 10, 2012, 9:09 PM

Post #7 of 43 (349 views)
Permalink

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

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

williamh at gentoo

Apr 10, 2012, 10:18 PM

Post #8 of 43 (345 views)
Permalink

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

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

sera at gentoo

Apr 11, 2012, 2:34 AM

Post #9 of 43 (349 views)
Permalink

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

On Tue, 10 Apr 2012 13:45:04 -0500
William Hubbs <williamh [at] gentoo> 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

Attachments:

signature.asc (0.48 KB)

rich0 at gentoo

Apr 11, 2012, 4:44 AM

Post #10 of 43 (344 views)
Permalink

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

On Tue, Apr 10, 2012 at 10:28 PM, Steven J Long
<slong [at] rathaus> 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

slong at rathaus

Apr 11, 2012, 7:13 AM

Post #11 of 43 (344 views)
Permalink

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

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

slong at rathaus

Apr 11, 2012, 8:09 AM

Post #12 of 43 (344 views)
Permalink

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

Rich Freeman wrote:

> On Tue, Apr 10, 2012 at 10:28 PM, Steven J Long
> <slong [at] rathaus> 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.

It would only be for packages that are specifically marked, the ones you'd
want in an initramfs. The "fix" is simply making sure the buildsystem
doesn't look in /usr/lib etc when so marked, and checking that binaries
don't link from / to anywhere but /lib*. If they do, it's up to the
maintainer as to whether it's an issue.

You'd only file an upstream bug if the build-system was looking in /usr/lib
despite being told not to (eg when only given -L /lib.) Making sure libs are
available in the right location is down to the distro, same as for the
initramfs.

> 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.
>
That might be true for some Linux-only packages, but I really find it hard
to believe that any upstream targetting more than one OS (just adding a BSD
is enough) with software that could be considered critical (I for one would
include all POSIX utilities as well as basic stuff like mount, fsck and
lvm2) would want to ignore this kind of thing; if the build-system is
ignoring configuration, it's a bug.

Regardless of how Linux might move (and personally I think there is a lot
more opposition to this than devs realise, as it throws the idea behind
userspace compatibility completely out of the window, in that it massively
impacts a generation of *nix working practices, even before one considers
systemd's single-point of kitchen-sink failure) taking away choice from end-
users for no appreciable gain in functionality or efficiency seems like a
bad idea.

I understand that the argument is "this is more efficient for our
development" but we're not talking about every package in the tree. Just the
binaries we might need in an initramfs; making sure their linkage is sound,
is likely to be useful for that case too, since it's an even more restricted
environment.

Wrt constraints on dependencies being removed, I don't really see that as
upstream's job; they simply specify the dependencies required and where they
actually are is up to the distro, and provided to the build by a mechanism
like pkg-config, or just flags from the package manager. Distros always have
been about managing dependencies for us.

> In any case, it sounds like the directive is to keep limping along for
> a while longer,

I read the decision from the Council to be "we will continue to support the
traditional split /usr eg with lvm, and no initramfs" and a Council member
put himself forward to maintain patches to udev to ensure that going
forward, since it is needed in his employment.

Given that we can do it with initscripts, and don't need to fork udev at
all, what's the problem?

It would only be for users who specifically opt in, knowing that they don't
need udev to localmount, and with the awareness that they might need to
configure things-- which any Gentoo user is used to hearing and evaluating.

> 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.
>
No argument on either of those.
--
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

slong at rathaus

Apr 11, 2012, 9:10 AM

Post #13 of 43 (350 views)
Permalink

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

William Hubbs wrote:
> 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.
>
I'm ignorant of which binaries do that? (It's understood that you might not
have manpages in rescue-mode.) OT, it's odd that nano is in /usr/bin but on
my system at least it only links to /lib64.

We're only discussing the same tools one might need in an initramfs, wherein
they presumably also need to have their linkage checked.

> 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.
>
There's been quite a bit of vocal opposition on the forums[1], and it's
users who've setup their machines in line with Gentoo docs that this is
going to impact. Even the link that was given to Red-Hat discussion about
this a while back, showed opposition to the move from their users.

[1] http://forums.gentoo.org/viewtopic-t-914852.html
'It's about as good an idea as putting the entire content of /etc into a
file and calling it "The Registry"
Oh, wait, that's already been done and shown not to work.'
NeddySeagoon - whose experience in system-administration and IT I'll bow to
anyday.

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

rich0 at gentoo

Apr 11, 2012, 9:55 AM

Post #14 of 43 (347 views)
Permalink

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

On Wed, Apr 11, 2012 at 11:09 AM, Steven J Long
<slong [at] rathaus> wrote:
> That might be true for some Linux-only packages, but I really find it hard
> to believe that any upstream targetting more than one OS (just adding a BSD
> is enough) with software that could be considered critical (I for one would
> include all POSIX utilities as well as basic stuff like mount, fsck and
> lvm2) would want to ignore this kind of thing; if the build-system is
> ignoring configuration, it's a bug.

The issue is that if udev requires libfoo, then libfoo must not be in
/usr. If libfoo is libx11 or dbus or some other complex library, that
will pull in a bunch of other stuff as well. However, I doubt that
the maintainers of all those libraries would consider them
boot-essential, so they may not be inclined to make the move.

Obviously we're not there now, but it is a possible consequence of
moving in this direction.

Keep in mind that systemd in particular does not aim to be
cross-platform - they advertise this as one of their core features.
Since tight integration is their goal that could slowly bring in a lot
of other stuff. The main platform pushing it along is Fedora, and
they're aiming to move everything into /usr, so this is a non-issue
for them.

> I read the decision from the Council to be "we will continue to support the
> traditional split /usr eg with lvm, and no initramfs" and a Council member
> put himself forward to maintain patches to udev to ensure that going
> forward, since it is needed in his employment.
>
> Given that we can do it with initscripts, and don't need to fork udev at
> all, what's the problem?

I can't really comment on what the decision from the Council actually
was. However, maintaining patches to udev is effectively the same
thing as forking it. Right now it probably isn't hard, and over time
that could change.

The only time patches != fork is if the patches have been submitted
upstream and are likely to be merged.

In any case, it isn't a crisis now and waiting a little to see which
way the wind ends up blowing probably makes sense.

Rich

zmedico at gentoo

Apr 11, 2012, 12:57 PM

Post #15 of 43 (346 views)
Permalink

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

On 04/11/2012 07:13 AM, Steven J Long wrote:
> 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.

It's not generally practical to do mounts prior to starting udev, since
udev can may be needed to create the device nodes that are needed for
for performing the mounts. Maybe a subset of users can get away with it
by relying on devtmpfs and having the drivers built into the kernel, but
that won't work for everyone.
--
Thanks,
Zac

rich0 at gentoo

Apr 21, 2012, 7:53 PM

Post #16 of 43 (280 views)
Permalink

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

On Sat, Apr 21, 2012 at 10:43 PM, Steven J Long
<slong [at] rathaus> wrote:
> The Council has voted that Gentoo continue to support that subset, without
> an initramfs.

Citation, please?

Rich

slong at rathaus

Apr 21, 2012, 8:20 PM

Post #17 of 43 (282 views)
Permalink

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

Zac Medico wrote:

> On 04/11/2012 07:13 AM, Steven J Long wrote:
>> 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.
>
> It's not generally practical to do mounts prior to starting udev, since
> udev can may be needed to create the device nodes that are needed for
> for performing the mounts. Maybe a subset of users can get away with it
> by relying on devtmpfs and having the drivers built into the kernel, but
> that won't work for everyone.

OFC not: the generic method is to use an initramfs. But many of us *do* have
the drivers for the device nodes built-in: it's part of the initial setup in
configuring a kernel (manually) and getting it to boot.

I can't speak for others, but that level of control is why I, for one, chose
Gentoo in the first place. I don't see the need for a source-based distro to
include everything and the kitchen-sink: that principle applies via USE-
flags, and it applies via having a lean kernel that doesn't contain modules
for 15 PCI controllers my motherboard doesn't have, and never could have.

The Council has voted that Gentoo continue to support that subset, without
an initramfs.

I'm glad you accept that we don't need to fork udev to do this, though, so
there isn't that maintenance issue, beyond Gentoo initscripts (and if there
should be in future, a Council member has already committed to overseeing
that work.)

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

slong at rathaus

Apr 21, 2012, 8:30 PM

Post #18 of 43 (282 views)
Permalink

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

Rich Freeman wrote:

> On Wed, Apr 11, 2012 at 11:09 AM, Steven J Long wrote:
>> That might be true for some Linux-only packages, but I really find it
>> hard to believe that any upstream targetting more than one OS (just
>> adding a BSD is enough) with software that could be considered critical
>> (I for one would include all POSIX utilities as well as basic stuff like
>> mount, fsck and lvm2) would want to ignore this kind of thing; if the
>> build-system is ignoring configuration, it's a bug.
>
> The issue is that if udev requires libfoo, then libfoo must not be in
> /usr. If libfoo is libx11 or dbus or some other complex library, that
> will pull in a bunch of other stuff as well. However, I doubt that
> the maintainers of all those libraries would consider them
> boot-essential, so they may not be inclined to make the move.
>
> Obviously we're not there now, but it is a possible consequence of
> moving in this direction.
>
Sure, but I'm curious: how would you set up an initramfs under those
conditions?

Where I'm going with this, is that in both cases (an initramfs or a
traditional rootfs system) we need to be aware of what libs pull in what.
Given that, there is actually common work both sides need.

If we could focus on that, we'd all actually be cooperating to fix things
for both setups, instead of arguing about which is best. :)

> Keep in mind that systemd in particular does not aim to be
> cross-platform - they advertise this as one of their core features.
> Since tight integration is their goal that could slowly bring in a lot
> of other stuff. The main platform pushing it along is Fedora, and
> they're aiming to move everything into /usr, so this is a non-issue
> for them.
>
I have a feeling that "integration" is being used as an excuse to avoid
thinking about coupling and cohesion.

>> I read the decision from the Council to be "we will continue to support
>> the traditional split /usr eg with lvm, and no initramfs" and a Council
>> member put himself forward to maintain patches to udev to ensure that
>> going forward, since it is needed in his employment.
>>
>> Given that we can do it with initscripts, and don't need to fork udev at
>> all, what's the problem?
>
> I can't really comment on what the decision from the Council actually
> was.

Well, I've stated that several times now, and included the snippet from the
log where Betelgeuse specifically asked Chainsaw to clarify that a
"universal" minimal initramfs was not good enough, which was confirmed.

If Council members disagree with that interpretation, I'd welcome their
clarification.

Split /usr with lvm was specifically discussed as a use-case, since it has
been outlined in Gentoo documentation.

> However, maintaining patches to udev is effectively the same
> thing as forking it. Right now it probably isn't hard, and over time
> that could change.
>
> The only time patches != fork is if the patches have been submitted
> upstream and are likely to be merged.
>
udev != openrc or any other init system, which is what we are patching[1] so
that udev is not started til after localmount, should the user set a
currently unsupported udev.conf option (initramfs="no").

We're only making minor shell-script modifications to udev and udev-mount
initscripts, not openrc itself.

Earlymounts[2] is simply an additional initscript.

IOW no patches to udev whatsoever, so no fork.

> In any case, it isn't a crisis now and waiting a little to see which
> way the wind ends up blowing probably makes sense.
>
No indeed: those of us who wish to stay with our traditional setup, who have
already configured our machines to localmount with built-in modules, can use
the patched initscripts/earlymounts. What we'd like is for those, or
equivalent functionality, to be maintained within Gentoo so we don't have to
tweak patches whenever udev-init-scripts is updated, or in the earlymounts
case there appear to be more issues, and those could use input from devs
imo.

I prefer the patched approach, even if it is a bit more setup and I am
biased, since it appears to have less potential for interaction with other
stuff: if you never needed an initramfs before, and can localmount with just
kernel-created device-nodes (eg: you need to change fstab from using
/dev/vg/lv to /dev/mapper/vg-lv for lvm), then you're fine.

[1] http://forums.gentoo.org/viewtopic-t-901206.html
[2] http://forums.gentoo.org/viewtopic-t-918466.html
--
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

slong at rathaus

Apr 21, 2012, 10:28 PM

Post #19 of 43 (281 views)
Permalink

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

Rich Freeman wrote:
>> The Council has voted that Gentoo continue to support that subset,
>> without an initramfs.
>
(The "subset of users" being those who do not need udev before localmount.)

> Citation, please?
>

<ulm> New udev and separate /usr partition
<Chainsaw> In my opinion, a separate /usr partition has been a supported
configuration for a very long time and should remain so.
<Betelgeuse> Chainsaw: So to clarify a universal initramfs is not enough?
<Chainsaw> Betelgeuse: No. That is additional work for a clearly broken
package.

So we must support separate /usr *without* an initramfs.

<dberkholz> who's going to either "port" udev as necessary, or maintain an
old version forever?
<Chainsaw> I will keep an old version going until the end of time.
<Chainsaw> dberkholz: My plan is to patch reasonable behaviour back into
udev, and going with the upstream releases as long as it is feasible.

To confirm again, that this is about without initramfs:
<dberkholz> sure i can. maintain old udev-XXX forever, put an elog in new
udev that says "if you want separate /usr without initramfs, install old
udev, mask new, or whatever"

And again, I ask: if it were *not* about running udev without an initramfs,
then why would anyone even be discussing the possibility of patching or
forking?

The only question is whether running without an initramfs means the same
thing as not requiring udev before localmount. I contend that it is, since
the basic requirement we've been given is that udev as a service requires
/usr and /var mounted before starting, since some devices already require
scripts which are in /usr or access /var (and going forward effectively can
require a script anywhere.)

Wrt udev linking to /usr/lib, it seems that any such linkage would need to
be satisfied in an initramfs too, so the same data could be used for people
who don't have an initramfs (how we deal with it on our systems is up to
us.)

I would dearly love to hear a walkthrough of how you deal with device nodes
created by udev which are required for udev to start in your initramfs, but
it does not affect the basic requirement for our use-case: that udev is not
needed for localmount.

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

floppym at gentoo

Apr 21, 2012, 11:00 PM

Post #20 of 43 (282 views)
Permalink

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

On Sun, Apr 22, 2012 at 1:28 AM, Steven J Long
<slong [at] rathaus> wrote:
> Rich Freeman wrote:
>>> The Council has voted that Gentoo continue to support that subset,
>>> without an initramfs.
>>
> (The "subset of users" being those who do not need udev before localmount.)
>
>> Citation, please?
>>
>
> <ulm> New udev and separate /usr partition
> <Chainsaw> In my opinion, a separate /usr partition has been a supported
> configuration for a very long time and should remain so.
> <Betelgeuse> Chainsaw: So to clarify a universal initramfs is not enough?
> <Chainsaw> Betelgeuse: No. That is additional work for a clearly broken
> package.
>
> So we must support separate /usr *without* an initramfs.
>
> <dberkholz> who's going to either "port" udev as necessary, or maintain an
> old version forever?
> <Chainsaw> I will keep an old version going until the end of time.
> <Chainsaw> dberkholz: My plan is to patch reasonable behaviour back into
> udev, and going with the upstream releases as long as it is feasible.
>
> To confirm again, that this is about without initramfs:
> <dberkholz> sure i can. maintain old udev-XXX forever, put an elog in new
> udev that says "if you want separate /usr without initramfs, install old
> udev, mask new, or whatever"
>
> And again, I ask: if it were *not* about running udev without an initramfs,
> then why would anyone even be discussing the possibility of patching or
> forking?
>

Here is my interpretation: the council voted on the following question:

<ulm> The question is: "Decide on whether a separate /usr is still a supported
configuration."

It did not decide the method that would be used to accomplish this. A
few council members (Chainsaw mainly) expressed a desire to do it
without an initramfs, but an official stance on this was not put
forward.

You are reading into it more that you should.

ulm at gentoo

Apr 22, 2012, 2:07 AM

Post #21 of 43 (279 views)
Permalink

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

>>>>> On Sun, 22 Apr 2012, Mike Gilbert wrote:

> Here is my interpretation: the council voted on the following
> question:

> <ulm> The question is: "Decide on whether a separate /usr is still a
> supported configuration."

> It did not decide the method that would be used to accomplish this.
> A few council members (Chainsaw mainly) expressed a desire to do it
> without an initramfs, but an official stance on this was not put
> forward.

> You are reading into it more that you should.

Please don't cite single lines without context. My next line in that
log is:

<ulm> as in the agenda

Which says:

| 3. New udev and separate /usr partition (30 minutes)
|
| See [4]: "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.)"
|
| [4] <http://archives.gentoo.org/gentoo-project/msg_c96d1b724cd736702820fa5ff1547557.xml>

Ulrich

slong at rathaus

Apr 22, 2012, 2:11 AM

Post #22 of 43 (282 views)
Permalink

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

Mike Gilbert wrote:

> On Sun, Apr 22, 2012 at 1:28 AM, Steven J Long wrote:
>> And again, I ask: if it were *not* about running udev without an
>> initramfs, then why would anyone even be discussing the possibility of
>> patching or forking?
>>
>
> Here is my interpretation: the council voted on the following question:
>
> <ulm> The question is: "Decide on whether a separate /usr is still a
> supported
> configuration."
>
> It did not decide the method that would be used to accomplish this. A
> few council members (Chainsaw mainly) expressed a desire to do it
> without an initramfs, but an official stance on this was not put
> forward.
>
While I agree it would be better if the vote had specified "without an
initramfs" it seems clear to me that that was what was under discussion,
since a) Chainsaw was asked to describe the issue and specifically turned
down an initramfs, and b) udev with an initramfs already supports a separate
/usr partition, so why would the Council need to vote on it?

It's already supported if you use an initramfs, so there isn't anything to
discuss, nor vote on as technical policy.

> You are reading into it more that you should.

Well two of the votes specifically mention initramfs:
<Betelgeuse> As long as there is no automated help for people to
automatically get initramfs I vote yes
<hwoarang> i vote no, because diverting from upstream is not an ideal option
for me

If it were not about supporting users without an initramfs, why would a yes
vote mean diverging from upstream?

At this point, I'd like the Council to clarify. I really don't see what else
could have required a vote, and the whole discussion was about not using an
initramfs, who would maintain any patches needed, and what the potential
consequences might be.

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

slong at rathaus

Apr 22, 2012, 2:28 AM

Post #23 of 43 (281 views)
Permalink

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

Ulrich Mueller wrote:

> | 3. New udev and separate /usr partition (30 minutes)
> |
> | See [4]: "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.)"
> |
> | [4]
> | [<http://archives.gentoo.org/gentoo-
project/msg_c96d1b724cd736702820fa5ff1547557.xml>
>
From the first reply:

"To clarify, the question is whether or not we support a separate /usr
_without_ mounting it early via an initramfs."

I hope that settles that particular issue.

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

floppym at gentoo

Apr 22, 2012, 10:55 AM

Post #24 of 43 (279 views)
Permalink

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

On 04/22/2012 05:28 AM, Steven J Long wrote:
> Ulrich Mueller wrote:
>
>> | 3. New udev and separate /usr partition (30 minutes)
>> |
>> | See [4]: "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.)"
>> |
>> | [4]
>> | [<http://archives.gentoo.org/gentoo-
> project/msg_c96d1b724cd736702820fa5ff1547557.xml>
>>
> From the first reply:
>
> "To clarify, the question is whether or not we support a separate /usr
> _without_ mounting it early via an initramfs."
>
> I hope that settles that particular issue.
>

Hmm... I see that in Zac's reply, thanks for that.

Unfortunately, from what I can tell, that clarification was not actually
part of the proposed agenda [5], nor was it directly referenced. So the
subject of the vote still seems open to interpretation.

Ultimately, the council's only "power" is to stop things from happening
under threat of expulsion from the project. I think it would be a
mistake for this particular council vote to be used as the sole
justification for preventing devs from committing changes that would
require an initramfs for separate /usr support. It simply does not seem
clear enough for that.

[5]
http://archives.gentoo.org/gentoo-project/msg_ac95bed78694852cd09f20a07437b805.xml

Attachments:

signature.asc (0.22 KB)

zmedico at gentoo

Apr 22, 2012, 11:13 AM

Post #25 of 43 (280 views)
Permalink

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

On 04/22/2012 10:55 AM, Mike Gilbert wrote:
> On 04/22/2012 05:28 AM, Steven J Long wrote:
>> Ulrich Mueller wrote:
>>
>>> | 3. New udev and separate /usr partition (30 minutes)
>>> |
>>> | See [4]: "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.)"
>>> |
>>> | [4]
>>> | [<http://archives.gentoo.org/gentoo-
>> project/msg_c96d1b724cd736702820fa5ff1547557.xml>
>>>
>> From the first reply:
>>
>> "To clarify, the question is whether or not we support a separate /usr
>> _without_ mounting it early via an initramfs."
>>
>> I hope that settles that particular issue.
>>
>
> Hmm... I see that in Zac's reply, thanks for that.
>
> Unfortunately, from what I can tell, that clarification was not actually
> part of the proposed agenda [5], nor was it directly referenced. So the
> subject of the vote still seems open to interpretation.

Yeah, it almost seems as though the council was being intentionally
vague and leaving things open to interpretation. In response, we had
William post about the ">= udev-182 tracker" [1], to which Tony seemed
to respond positively [2].

[1]
http://archives.gentoo.org/gentoo-dev/msg_015e73cfccbd72fa956a8bdbc2e9cdc0.xml
[2]
http://archives.gentoo.org/gentoo-dev/msg_fb17ccaadc95c7f3f27d0613c13aa04e.xml
--
Thanks,
Zac

1 2

View All

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads