Mailing List Archive

On Sat, 31 Dec 2011 19:59:47 -0600
William Hubbs <williamh@gentoo.org> wrote:

> Udev, kmod (which is a replacement for module-init-tools which will be needed
> by >=udev-176), systemd, and soon others, are advocating a major change
> to the locations where binaries and libraries are stored on linux
> systems.
>
> The goal is to deprecate /bin, /lib, /sbin and /usr/sbin. My
> understanding is that they want to move software that is installed in
> /bin, /sbin and /usr/sbin to /usr/bin. Also, they want to move
> everything from /lib to /usr/lib.

I coulda swore April was another four months away...


--
fonts, gcc-porting, it makes no sense how it makes no sense
toolchain, wxwidgets but i'll take it free anytime
@ gentoo.org EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

Hi,

On Sat, 2011-12-31 at 19:59 -0600, William Hubbs wrote:
> I have been working with robbat2 on solutions to the separate /usr issue
> (That is why I have specifically cc'd him on this email)
> which will allow people to not use an initramfs. If we migrate
> everything off of the root fs to /usr, all of those solutions become
> moot. On the other hand, if we don't migrate, we run the risk of
> eventually having our default configuration not supported by upstream.

I think the general consensus among other distros is that initramfs is
the new /. Many core elements of the Linux system will start installing
themselves in /usr, starting with udev, so we won't have a choice
anyway. Also, I doubt it's currently possible to boot a Gentoo system
without /usr mounted anyway.

> 1) Start migrating packages along with upstream and have everyone who
> has a separate /usr (including me by the way) start using an initramfs
> of some kind, either dracut or one that we generate specifically for
> gentoo. The reason I suggest the initramfs, is, unfortunately if we
> migrate everything, nothing else would work.

I also don't see a good reason to not adopt dracut, re-implementing
something that already works and is maintained by a competent upstream
seems wasteful to me. I really don't see why people resist using an
initramfs so much.

The udev/kmod/systemd/dracut effort to standardise the base userspace of
Linux is probably scary for quite a few Gentoo-ers as it means that the
end result of an installed Gentoo system will be less differentiated
than it was before. But it still is a step in the right direction as
most of these standardized pieces are much better than what we currently
have. The OpenRC/baselayout-2 fiasco, not much better than baselayout-1
and unmaintained upstream shows that even a relatively large
distribution like us can't maintain a competitive base system solution,
adopting the udev/kmod/systemd way will allow us to use all the work
that they are doing and instead concentrate on making a better system.

--
Olivier Crête
tester@gentoo.org
Gentoo Developer

On Sun, 01 Jan 2012 02:12:22 -0500
Olivier Crête <tester@gentoo.org> wrote:

> Hi,
>
> On Sat, 2011-12-31 at 19:59 -0600, William Hubbs wrote:
> > I have been working with robbat2 on solutions to the separate /usr
> > issue (That is why I have specifically cc'd him on this email)
> > which will allow people to not use an initramfs. If we migrate
> > everything off of the root fs to /usr, all of those solutions become
> > moot. On the other hand, if we don't migrate, we run the risk of
> > eventually having our default configuration not supported by
> > upstream.
>
> I think the general consensus among other distros is that initramfs is
> the new /. Many core elements of the Linux system will start
> installing themselves in /usr, starting with udev, so we won't have a
> choice anyway. Also, I doubt it's currently possible to boot a Gentoo
> system without /usr mounted anyway.
>
> > 1) Start migrating packages along with upstream and have everyone
> > who has a separate /usr (including me by the way) start using an
> > initramfs of some kind, either dracut or one that we generate
> > specifically for gentoo. The reason I suggest the initramfs, is,
> > unfortunately if we migrate everything, nothing else would work.
>
> I also don't see a good reason to not adopt dracut, re-implementing
> something that already works and is maintained by a competent upstream
> seems wasteful to me. I really don't see why people resist using an
> initramfs so much.
>
> The udev/kmod/systemd/dracut effort to standardise the base userspace
> of Linux is probably scary for quite a few Gentoo-ers as it means
> that the end result of an installed Gentoo system will be less
> differentiated than it was before. But it still is a step in the
> right direction as most of these standardized pieces are much better
> than what we currently have. The OpenRC/baselayout-2 fiasco, not much
> better than baselayout-1 and unmaintained upstream shows that even a
> relatively large distribution like us can't maintain a competitive
> base system solution, adopting the udev/kmod/systemd way will allow
> us to use all the work that they are doing and instead concentrate on
> making a better system.
>


All of my systems currently have a seperate /usr that is mounted at
boot. Unfortunately I do agree that this is not something that we can
fight. This was brought up earlier and the only thing we can do
for people like myself (who mount /usr at boot) is to create a simple
initramfs that only has the purpose of mounting /usr at boot. The main
thing I don't like about initramfs is that we have to regenerate it any
time we update the packages that get included in it.

--
Matthew Thode (prometheanfire)

On 01/01/12 15:12, Olivier Crête wrote:
> Hi,
>
> On Sat, 2011-12-31 at 19:59 -0600, William Hubbs wrote:
>> I have been working with robbat2 on solutions to the separate /usr issue
>> (That is why I have specifically cc'd him on this email)
>> which will allow people to not use an initramfs. If we migrate
>> everything off of the root fs to /usr, all of those solutions become
>> moot. On the other hand, if we don't migrate, we run the risk of
>> eventually having our default configuration not supported by upstream.
> I think the general consensus among other distros is that initramfs is
> the new /. Many core elements of the Linux system will start installing
> themselves in /usr, starting with udev, so we won't have a choice
> anyway. Also, I doubt it's currently possible to boot a Gentoo system
> without /usr mounted anyway.
"initramfs is the new /" ... and no one asked if maybe that doesn't
really make sense?

That people are now actively working on forcing one big system partition
is annoying, but I really don't see the need to add a layer or two of
complexification just because, well, why not.

>
>> 1) Start migrating packages along with upstream and have everyone who
>> has a separate /usr (including me by the way) start using an initramfs
>> of some kind, either dracut or one that we generate specifically for
>> gentoo. The reason I suggest the initramfs, is, unfortunately if we
>> migrate everything, nothing else would work.
> I also don't see a good reason to not adopt dracut,
Make it work and I'll reconsider it, until then genkernel wins by default.
> re-implementing
> something that already works and is maintained by a competent upstream
> seems wasteful to me. I really don't see why people resist using an
> initramfs so much.
What does it add, apart from time to the boot process? For some setups
(like my notebook with luks+lvm) there's no reasonable way around it,
but on my desktop it's worse than useless.
>
> The udev/kmod/systemd/dracut effort to standardise the base userspace of
> Linux is probably scary for quite a few Gentoo-ers as it means that the
> end result of an installed Gentoo system will be less differentiated
> than it was before. But it still is a step in the right direction as
> most of these standardized pieces are much better than what we currently
> have. The OpenRC/baselayout-2 fiasco, not much better than baselayout-1
> and unmaintained upstream shows that even a relatively large
> distribution like us can't maintain a competitive base system solution,
Eh what?

As part of the OpenRC upstream I find it weird that you call it a fiasco
when it works better than the other "solutions" and had about 10 commits
in the last 48 hours alone.

I don't see an advantage in replacing a known-good solution with some
random stuff that mostly doesn't work yet just because it's the future.


> adopting the udev/kmod/systemd way will allow us to use all the work
> that they are doing and instead concentrate on making a better system.
>
"Better" means no lennartware to me. I want to be able to fully debug
init script failures, which systemd makes very hard to impossible. On
some machines I have changes in the startup that would mean having to
hack up something in C and hope that it doesn't crash init for systemd
(what the bleeeep?)

Please don't try to bring the GnomeOS vision of having MacOS without
paying for it to my computing experience ...

On Sat, Dec 31, 2011 at 07:59:47PM -0600, William Hubbs wrote:
> The goal is to deprecate /bin, /lib, /sbin and /usr/sbin. My
> understanding is that they want to move software that is installed in
> /bin, /sbin and /usr/sbin to /usr/bin. Also, they want to move
> everything from /lib to /usr/lib.

I don't like this one bit. Things used to be simple with the "split" between
/bin and /usr/bin (and its related directories), this isn't going to make it
more simple.

> 1) Start migrating packages along with upstream and have everyone who
> has a separate /usr (including me by the way) start using an initramfs
> of some kind, either dracut or one that we generate specifically for
> gentoo. The reason I suggest the initramfs, is, unfortunately if we
> migrate everything, nothing else would work.

I use a separate /usr with LVM on all my systems. My root partition uses
RAID1. And I never had the need for an initramfs of any kind. Also, there
are some major hurdles to take when it comes to getting an initramfs working
with SELinux. Most initramfs implementations I saw are not SELinux aware, so
all changes they make to the system either result in failures when they try,
or failures when the root-switch occurs.

> 3) Try to maintain things the way they are as long as possible.

I'm all for this one.

But if people really want to focus on initramfs, I'd appreciate some
documentation help on it. Not only on how to create one, but also why it is
necessary, how to manage initramfs'es, the concepts underlying, etc.

Wkr,
Sven Vermeulen

On Sun, Jan 1, 2012 at 2:23 PM, Sven Vermeulen <swift@gentoo.org> wrote:
> On Sat, Dec 31, 2011 at 07:59:47PM -0600, William Hubbs wrote:
>> The goal is to deprecate /bin, /lib, /sbin and /usr/sbin. My
>> understanding is that they want to move software that is installed in
>> /bin, /sbin and /usr/sbin to /usr/bin. Also, they want to move
>> everything from /lib to /usr/lib.
>
> I don't like this one bit. Things used to be simple with the "split" between
> /bin and /usr/bin (and its related directories), this isn't going to make it
> more simple.

Actually, I've always thought that the split between /usr/bin and /bin
was quite arbitrary. However, I would like to note that merging /bin
and /usr/bin would break some app combinations like bzip2+pbzip2, so
that problem also needs to be solved (via eselect perhaps).

Overall, this change "feels" wrong to me, but there's nothing
intrinsically wrong with what they're suggesting. OTOH, it's probably
just going to cause chaos and further divergence between distros for
little gain.

--
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team

William Hubbs posted on Sat, 31 Dec 2011 19:59:47 -0600 as excerpted:

> a significant change is taking place with several upstreams that will
> affect us in gentoo[. Boot-critical components such as Udev, kmod,
> etc], are advocating a major change to the locations where binaries
> and libraries are stored on linux systems.
>
> The goal is to deprecate /bin, /lib, /sbin and /usr/sbin. My
> understanding is that they want to move software that is installed in
> /bin, /sbin and /usr/sbin to /usr/bin. Also, they want to move
> everything from /lib to /usr/lib.

> If we migrate everything off of the root fs to /usr, all of those
> solutions become moot. On the other hand, if we don't migrate,
> we run the risk of eventually having our default configuration
> not supported by upstream.
>
> I see three options:
>
> 1) Start migrating packages along with upstream[. Have separate /usr
> users] start using an initramfs [as previously discussed onlist].
>
> 2) Combine the sbin and bin directories both on the root filesystem and
> in /usr by moving things from /sbin to /bin and /usr/sbin to /usr/bin.
>
> 3) Try to maintain things the way they are as long as possible.
>
> Whether or not I like what is happening personally, I think we should
> consider the first option, because I think it will get more and more
> difficult for us to do anything else over time. And we will eventually
> find ourselves not supported by upstreams.

I'm for #1 (migrate along with upstream) as well.

Gentoo has historically been both "light patch", with a policy of staying
close to upstream if possible, and "customizer's choice", allowing users
far more flexibility than most distros. Keeping both goals in mind,
migrating with upstream is ultimately the only viable alternative for a
whole host of reasons including both staying close to upstream and simple
manpower resource issues.

That said, we can continue to try to support a separate /usr as long as
possible, while switching new installs to the new way and changing the
handbook to document it, preferably as soon as possible. Further, as
previously discussed, a near-static bare-minimal initramfs that can be
configured and forgotten about for long periods over many kernel upgrades
should make the switch as painless as possible at least for "simple" bare-
partition installations.


As for the switchover, I had already been thinking about it here and thus
have a couple ideas I'd very much like to see implemented in portage/PM/
base.eclass that could definitely help, along with a USE flag. I'll call
them "migrated-rootfs" and "migrateroot-strict" for purposes of
discussion, here, and assume they're both portage features and that
migrated-rootfs is also a USE flag

FEATURES=migrated-rootfs would set a USE-default for migrated-root-to-usr
so that it'd default to ON, and would indicate that a user is an "early
adopter" of the new layout, preferring migration as soon as possible.
Users could still set the USE flag as desired for specific packages, at
least at first, tho at some point it'd probably first be made a profile
default, and ultimately profile-masked either on or off.

Additionally, FEATURES=migrated-root would expand the collision-protect
feature to check for and warn on both same-package and cross-package
collisions between related dirs, with all four bin/sbin root/usr dirs
checked for name collisions, and both lib dirs (for single lib,
additional pairs for multilib) checked as well.

Optionally, if implementation is easy enough, have portage simply remove
symlinks to identically named files that would otherwise set off the
warning. This is a major reason for having it a feature and a USE flag
both, since if this is implemented, portage would take preventive action
quite apart from whether an ebuild had been updated to use the USE flag
or not.

FEATURES=migrateroot-strict would make those collision warnings fatal,
much like FEATURES=multilib-strict does for its multilib checks. (As an
amd64 user who had this feature on for years, until I switched to no-
multilib, that's what the idea is based on.)


The goal would be to allow early adopter users to set the less strict
version and run a --empty-tree @world update, then grep the logs for the
warnings it turned on. If none occurred and /usr is either already on
the same filesystem or they have the appropriate early-boot measures in
place, they could feel reasonably confident about setting up symlinks
pointing to the /usr/bin and /usr/lib dirs as appropriate, and could then
set FEATURES=migratedroot-strict to ensure it stays "clean", since after
that any attempted merge that would collide would be fatal.

Alternatively users could just set the strict version and see what
breaks, instead of grepping the logs for the warnings.

Since this would leverage the code already in place and tested for
collision-protect and multilib-strict, cross-package checking should be
fairly easy to implement, but same-package checking and/or actively
stripping colliding symlinks may involve rather more new code.

Zac? Other portage,/PM/PMS folks?

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman

Sven Vermeulen wrote:
> But if people really want to focus on initramfs, I'd appreciate some
> documentation help on it. Not only on how to create one, but also why
> it is necessary, how to manage initramfs'es, the concepts underlying,
> etc. Wkr, Sven Vermeulen

This is my issue as well. I tried to make a init* to deal with this and
have yet to get one to work, not one single working boot up. I have
tried different howtos and not one of them produced anything that
works. I have not found a dracut howto that makes any sense either.
Sorry but genkernel left a bad taste in my mouth ages ago.

As bad as I hate to even use a init*, I hate even worse being told I
have to have one and not being able to get one to work following the
docs. There needs to be some really well tested docs for people to use
before this kicks in.

Now to go brush my teeth. :/ This init* thingy tastes really bad.

Dale

:-) :-)

--
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!

Miss the compile output? Hint:
EMERGE_DEFAULT_OPTS="--quiet-build=n"

On 01/01/2012 01:23 AM, Duncan wrote:
> As for the switchover, I had already been thinking about it here and thus
> have a couple ideas I'd very much like to see implemented in portage/PM/
> base.eclass that could definitely help, along with a USE flag. I'll call
> them "migrated-rootfs" and "migrateroot-strict" for purposes of
> discussion, here, and assume they're both portage features and that
> migrated-rootfs is also a USE flag
>
> FEATURES=migrated-rootfs would set a USE-default for migrated-root-to-usr
> so that it'd default to ON, and would indicate that a user is an "early
> adopter" of the new layout, preferring migration as soon as possible.
> Users could still set the USE flag as desired for specific packages, at
> least at first, tho at some point it'd probably first be made a profile
> default, and ultimately profile-masked either on or off.

I'm not sure if a USE flag for FEATURES setting would be necessary. If
we want to enforce a global policy, then I guess a QA warning would be
warranted.

Overall, a migration like this should go pretty smoothly as long as
people with separate /usr take appropriate actions to make sure their
systems will boot. People without separate /usr can basically relax and
enjoy the ride.
--
Thanks,
Zac

On Sun, Jan 1, 2012 at 4:45 AM, Dale <rdalek1967@gmail.com> wrote:
> This is my issue as well.  I tried to make a init* to deal with this and
> have yet to get one to work, not one single working boot up.  I have tried
> different howtos and not one of them produced anything that works.  I have
> not found a dracut howto that makes any sense either.  Sorry but genkernel
> left a bad taste in my mouth ages ago.

While I think that the direction we're moving in (/usr on root or use
an initramfs) is inevitable, I do agree that it needs some
improvement.

I've gotten Dracut to work fine in VMs (even with fairly complex
setups), but every time I try it on my server it doesn't set up the
raid for some reason, and drops me to a dash shell. If I just run
mdadm_auto at that point it takes about 15 seconds to find and setup
my raid, and just typing exit boots the system just fine. I keep it
as an option in grub so that whenever my raid device numbers get mixed
up (seems to happen every other month for no apparent reason) I can
boot the system, since dracut does use the mdadm.conf and UUIDs to put
everything in the right place and find the right root (something you
can't do without an initramfs). One of these days I'll figure out how
to hack an mdadm_auto into the script as a last-ditch measure and then
I'll just have to deal with a one-minute delay.

For being the wave of the future it seems like the only documentation
Dracut has is a single page website with a few paragraphs of info.

I think the bottom line is that the future may look inevitable, but it
isn't actually here yet. I advocate being ready for the future, but
let's try not to force its arrival before everything is mature (though
having it in portage as an option is completely in the spirit of
Gentoo).

Rich

Rich Freeman wrote:
> On Sun, Jan 1, 2012 at 4:45 AM, Dale<rdalek1967@gmail.com> wrote:
>> This is my issue as well. I tried to make a init* to deal with this and
>> have yet to get one to work, not one single working boot up. I have tried
>> different howtos and not one of them produced anything that works. I have
>> not found a dracut howto that makes any sense either. Sorry but genkernel
>> left a bad taste in my mouth ages ago.
> While I think that the direction we're moving in (/usr on root or use
> an initramfs) is inevitable, I do agree that it needs some
> improvement.
>
> I've gotten Dracut to work fine in VMs (even with fairly complex
> setups), but every time I try it on my server it doesn't set up the
> raid for some reason, and drops me to a dash shell. If I just run
> mdadm_auto at that point it takes about 15 seconds to find and setup
> my raid, and just typing exit boots the system just fine. I keep it
> as an option in grub so that whenever my raid device numbers get mixed
> up (seems to happen every other month for no apparent reason) I can
> boot the system, since dracut does use the mdadm.conf and UUIDs to put
> everything in the right place and find the right root (something you
> can't do without an initramfs). One of these days I'll figure out how
> to hack an mdadm_auto into the script as a last-ditch measure and then
> I'll just have to deal with a one-minute delay.
>
> For being the wave of the future it seems like the only documentation
> Dracut has is a single page website with a few paragraphs of info.
>
> I think the bottom line is that the future may look inevitable, but it
> isn't actually here yet. I advocate being ready for the future, but
> let's try not to force its arrival before everything is mature (though
> having it in portage as an option is completely in the spirit of
> Gentoo).
>
> Rich
>
>


I installed dracut and it did something, although I'm not sure what
yet. I googled until I think google should be tired of me to find docs
to help. Getting it to run was on one page, then figuring out some
options was on yet another page, then grub was on yet another. I don't
know yet if some of these are outdated or anything so I don't know if it
is going to work or just blow up something. Please, don't ask me what it
did. I said I did it, I didn't say I understand it. If it is broken or
breaks in the future, I'm screwed. (Sort of starting to wonder why I
left Mandriva now. I could have swore I wanted to be rid of init* stuff
and make my on freakin kernels. )

I might also add for those considering dracut being the official way, it
is keyworded at this point. I would think someone needs to get this
stable or whatever needs doing before telling folks to use this. It may
work fine but if that is the case, then it needs to be unkeyworded.
Spell check doesn't like our terms here.

I think the future is actually taking several steps backward. That
point has been discussed to death tho.

I hope Sven has his thinking hat on. Maybe I can help some with the
docs. If it works for me, it should work for most. lol

Dale

:-) :-)

--
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!

Miss the compile output? Hint:
EMERGE_DEFAULT_OPTS="--quiet-build=n"

On Sun, Jan 01, 2012 at 02:12:22AM -0500, Olivier Crête wrote:
> > 1) Start migrating packages along with upstream and have everyone who
> > has a separate /usr (including me by the way) start using an initramfs
> > of some kind, either dracut or one that we generate specifically for
> > gentoo. The reason I suggest the initramfs, is, unfortunately if we
> > migrate everything, nothing else would work.
>
> I also don't see a good reason to not adopt dracut, re-implementing
> something that already works and is maintained by a competent upstream
> seems wasteful to me. I really don't see why people resist using an
> initramfs so much.
>
> The udev/kmod/systemd/dracut effort to standardise the base userspace of
> Linux is probably scary for quite a few Gentoo-ers as it means that the
> end result of an installed Gentoo system will be less differentiated
> than it was before. But it still is a step in the right direction as
> most of these standardized pieces are much better than what we currently
> have. The OpenRC/baselayout-2 fiasco, not much better than baselayout-1
> and unmaintained upstream shows that even a relatively large
> distribution like us can't maintain a competitive base system solution,
> adopting the udev/kmod/systemd way will allow us to use all the work
> that they are doing and instead concentrate on making a better system.

The problem you are missing here is that gentoo isn't just for linux. We
are cross-platform, so we have to have a cross-platform init system as
the default. Unless they port systemd to *bsd, we may have to keep
openrc as the default init system for some time afaik.

Also, your statement about openrc not being maintained upstream is not
correct. It is correct that Roy doesn't work on it any more, but there
is a team that does maintain it.

William

Zac Medico posted on Sun, 01 Jan 2012 02:15:49 -0800 as excerpted:

> I'm not sure if a USE flag for FEATURES setting would be necessary. If
> we want to enforce a global policy, then I guess a QA warning would be
> warranted.

I didn't state why I suggested that, but here's the reasoning:

Unless I missed an update somewhere, USE flags are covered by PMS and
thus available to be used in ebuilds, etc. AFAIK, portage FEATURES are
just that, portage FEATURES, and thus are supposed to be opaque to
ebuilds, which shouldn't need to care which PM is running or its
features, as long as it's PMS compliant.

Thus, the split between the FEATURES bit which the ebuild shouldn't need
to know about (the user sets up the symlinks and sets the features and
portage takes care of it managing the rest for existing versions without
rewriting), and the USE flag, for where upstreams and/or ebuilds are
actually rewritten with the possibility of both layouts (and later only
the /usr locations) in mind and the ebuild installs to the targeted
location based on the USE flag.

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman

On Sat, 31 Dec 2011 19:59:47 -0600
William Hubbs <williamh@gentoo.org> wrote:

> I see three options:
>
> 1) Start migrating packages along with upstream and have everyone who
> has a separate /usr (including me by the way) start using an initramfs
> of some kind, either dracut or one that we generate specifically for
> gentoo. The reason I suggest the initramfs, is, unfortunately if we
> migrate everything, nothing else would work.
>
> 2) Combine the sbin and bin directories both on the root
> filesystem and in /usr by moving things from /sbin to /bin
> and /usr/sbin to /usr/bin.
>
> 3) Try to maintain things the way they are as long as possible.

We should *at least* start doing some preparations, like ensuring that
random things don't unnecessarily hardcode /sbin or /bin paths. Most
importantly, if a particular tool runs in a complete environment (which
is true for most of the cases), there is no need to hardcode paths to
tools.

As I see it, 2) seems achievable within a reasonable time now. It
shouldn't require any specific changes from users (except for fixing
their own broken scripts) yet some tree-wide action of fixing hardcoded
paths.

We could create /sbin and /usr/sbin symlinks as well but that shouldn't
be really necessary, especially if we prepare packages well beforehand.
Introducing such symlinks would be hard to perform and getting rid of
them later would be even harder; mostly due to PMS-enforced limitations.

For a long-term view, 1) is the only way to go. Splitting packages
randomly between rootfs and /usr was never really correct, and we
especially shouldn't force users to junk their systems with shattered
packages and cheap glue to keep it all working.

I'd suggest going the other way than I did with kmod. Temporary IUSE
like 'install-to-usr', disabled by default for now. Packages having
that IUSE should have correct USE-dependencies, and users who need not
to use that could just enable 'install-to-usr' globally (we'd probably
want to mask it first).

Of course, that way will require removing hardcoded paths as well, or
supporting switching them on IUSE. For the latter, it may be simpler to
use '[install-to-usr=]' kind of dependencies.

--
Best regards,
Michał Górny

On Sun, Jan 01, 2012 at 09:23:11AM +0000, Duncan wrote:
> Gentoo has historically been both "light patch", with a policy of staying
> close to upstream if possible, and "customizer's choice", allowing users
> far more flexibility than most distros. Keeping both goals in mind,
> migrating with upstream is ultimately the only viable alternative for a
> whole host of reasons including both staying close to upstream and simple
> manpower resource issues.

> That said, we can continue to try to support a separate /usr as long as
> possible, while switching new installs to the new way and changing the
> handbook to document it, preferably as soon as possible.

In this situation, I don't know how we will be able to support both
ways because there is more involved than just where things are
installed.

Udev 175 is currently masked, because the way it operates has changed
enough that it doesn't work correctly if it starts before /usr is
mounted, and the failures you find will be very difficult to track down.
So, udev isn't only changing where it is installed, but how it runs.

Supporting a separate /usr without an initramfs will require one of two
things.

One possibility is a customization to openrc, which we have been
looking at, that would be able to run fsck on /usr and mount /usr all
before udev starts. The drawback here is this will only work for openrc
users.

Another possibility is a script that would run as the init= parameter to
the kernel, which would fsck /usr and mount /usr then start the real
init process. This would be more generic and would be able to run
regardless of whether you are using sysvinit/openrc.

Here is the big problem with both of these solutions as I see them. They
depend on several pieces of software remaining on the root filesystem,
and if/when this software is migrated, we will be back to having this discussion
again.

> Further, as
> previously discussed, a near-static bare-minimal initramfs that can be
> configured and forgotten about for long periods over many kernel upgrades
> should make the switch as painless as possible at least for "simple" bare-
> partition installations.

I want to look at dracut and see if there is a way to configure it to
create a minimal initramfs like you are suggesting, because, if there is
we don't need to re-invent the wheel.

I don't think your portage feature/use flag suggestion is a good idea,
because, right now most of this is about where things are installed,
but, eventually we might have to start actually patching software to
make it work if it is installed on / instead of /usr, and there is no
way to know how much patching we would have to do.

What are your thoughts?

William

On Sun, 01 Jan 2012 02:12:22 -0500
Olivier Crête <tester@gentoo.org> wrote:
> The udev/kmod/systemd/dracut effort to standardise the base userspace
> of Linux is probably scary for quite a few Gentoo-ers as it means
> that the end result of an installed Gentoo system will be less
> differentiated than it was before. But it still is a step in the
> right direction as most of these standardized pieces are much better
> than what we currently have. The OpenRC/baselayout-2 fiasco, not much
> better than baselayout-1 and unmaintained upstream shows that even a
> relatively large distribution like us can't maintain a competitive
> base system solution, adopting the udev/kmod/systemd way will allow
> us to use all the work that they are doing and instead concentrate on
> making a better system.

Doesn't all this mess just show that no-one else can maintain a
"competitive" base system solution either?

--
Ciaran McCreesh

Yeah I know I"m replying to my own message, but I wanted to add a
thought about the symbolic links issue.

I don't think the /{bin,sbin,lib} and /usr/sbin directories should be
deleted.

However, what I would like to see is that the package maintainers would
be responsible for creating any compatibility symlinks their package
needs, not portage. I don't think it is a good idea to have portage or
any package manager controling the migration.

That way, once the package maintainer knows that the symbolic links are
not needed, they can be removed and eventually all of these directories
would be empty and they could eventually be removed if desired.

Thoughts?

William

On Sun, 2012-01-01 at 01:33 -0600, Matthew Thode wrote:
> On Sun, 01 Jan 2012 02:12:22 -0500
> Olivier Crête <tester@gentoo.org> wrote:
> All of my systems currently have a seperate /usr that is mounted at
> boot. Unfortunately I do agree that this is not something that we can
> fight. This was brought up earlier and the only thing we can do
> for people like myself (who mount /usr at boot) is to create a simple
> initramfs that only has the purpose of mounting /usr at boot. The main
> thing I don't like about initramfs is that we have to regenerate it any
> time we update the packages that get included in it.

That's why you have dracut to do it for you.


--
Olivier Crête
tester@gentoo.org
Gentoo Developer

Hi,

On Sun, 2012-01-01 at 12:46 -0600, William Hubbs wrote:
> I don't think the /{bin,sbin,lib} and /usr/sbin directories should be
> deleted.
>
> However, what I would like to see is that the package maintainers would
> be responsible for creating any compatibility symlinks their package
> needs, not portage. I don't think it is a good idea to have portage or
> any package manager controling the migration.

The other option is to do mv /bin/* /sbin/* /usr/sbin/* /usr/bin; and
then create symlinks from the other dirs to /usr/bin.. That can be done
in big move, it's the way Fedora is going to do it.

--
Olivier Crête
tester@gentoo.org
Gentoo Developer

On Sun, 1 Jan 2012 01:33:05 -0600
Matthew Thode (prometheanfire) <prometheanfire@gentoo.org> wrote:

> All of my systems currently have a seperate /usr that is mounted at
> boot. Unfortunately I do agree that this is not something that we can
> fight. This was brought up earlier and the only thing we can do
> for people like myself (who mount /usr at boot) is to create a simple
> initramfs that only has the purpose of mounting /usr at boot. The
> main thing I don't like about initramfs is that we have to regenerate
> it any time we update the packages that get included in it.

Eh, I think I'll end up writing myself that four lines of shell code
for you which mounts /usr and runs init.

Or maybe I'll leave that task to you. Attaching my /init for
micro-initramfs on klibc. It looks like that:

├── bin
│   ├── ls
│   ├── mount
│   ├── run-init
│   └── sh
├── dev
│   ├── null
│   └── sda2
├── init
├── lib64
│   ├── klibc-MZ_9MGQEe6NFqmrPjRpy5i6WlV8.so
│   └── libc.so -> klibc-MZ_9MGQEe6NFqmrPjRpy5i6WlV8.so
├── newroot
└── proc

$ du -sh
176K .

--
Best regards,
Michał Górny

On Sun, 2012-01-01 at 15:33 +0800, Patrick Lauer wrote:
> On 01/01/12 15:12, Olivier Crête wrote:
> > Hi,
> >
> > On Sat, 2011-12-31 at 19:59 -0600, William Hubbs wrote:
> >> I have been working with robbat2 on solutions to the separate /usr issue
> >> (That is why I have specifically cc'd him on this email)
> >> which will allow people to not use an initramfs. If we migrate
> >> everything off of the root fs to /usr, all of those solutions become
> >> moot. On the other hand, if we don't migrate, we run the risk of
> >> eventually having our default configuration not supported by upstream.
> > I think the general consensus among other distros is that initramfs is
> > the new /. Many core elements of the Linux system will start installing
> > themselves in /usr, starting with udev, so we won't have a choice
> > anyway. Also, I doubt it's currently possible to boot a Gentoo system
> > without /usr mounted anyway.
> "initramfs is the new /" ... and no one asked if maybe that doesn't
> really make sense?
>
> That people are now actively working on forcing one big system partition
> is annoying, but I really don't see the need to add a layer or two of
> complexification just because, well, why not.

We're absolutely not forcing a single system partition. We're just
saying that the bits required to mount all the partitions you want
should be in an initramfs.

> >> 1) Start migrating packages along with upstream and have everyone who
> >> has a separate /usr (including me by the way) start using an initramfs
> >> of some kind, either dracut or one that we generate specifically for
> >> gentoo. The reason I suggest the initramfs, is, unfortunately if we
> >> migrate everything, nothing else would work.
> > I also don't see a good reason to not adopt dracut,
> Make it work and I'll reconsider it, until then genkernel wins by default.
> > re-implementing
> > something that already works and is maintained by a competent upstream
> > seems wasteful to me. I really don't see why people resist using an
> > initramfs so much.
> What does it add, apart from time to the boot process? For some setups
> (like my notebook with luks+lvm) there's no reasonable way around it,
> but on my desktop it's worse than useless.

I don't see how it adds time to the boot process. Either you have a
single big partition (and then you don't even need an initramfs), or you
have multiple partitions and then most of the time is mounting them
anyway.

> > The udev/kmod/systemd/dracut effort to standardise the base userspace of
> > Linux is probably scary for quite a few Gentoo-ers as it means that the
> > end result of an installed Gentoo system will be less differentiated
> > than it was before. But it still is a step in the right direction as
> > most of these standardized pieces are much better than what we currently
> > have. The OpenRC/baselayout-2 fiasco, not much better than baselayout-1
> > and unmaintained upstream shows that even a relatively large
> > distribution like us can't maintain a competitive base system solution,
> Eh what?
>
> I don't see an advantage in replacing a known-good solution with some
> random stuff that mostly doesn't work yet just because it's the future.

Random stuff that was well though to work together and works well enough
that all other major distros are adopting it.

> > adopting the udev/kmod/systemd way will allow us to use all the work
> > that they are doing and instead concentrate on making a better system.
> >
> "Better" means no lennartware to me. I want to be able to fully debug
> init script failures, which systemd makes very hard to impossible. On
> some machines I have changes in the startup that would mean having to
> hack up something in C and hope that it doesn't crash init for systemd
> (what the bleeeep?)

You can start services with a shell scripts in systemd, you just have to
aim the .service unit file to you shellscript..

> Please don't try to bring the GnomeOS vision of having MacOS without
> paying for it to my computing experience ...

Honestly, so many things just work on MacOS and just need hours of
tweaking for us..

--
Olivier Crête
tester@gentoo.org
Gentoo Developer

On Sun, 2012-01-01 at 08:53 +0000, Sven Vermeulen wrote:
> On Sat, Dec 31, 2011 at 07:59:47PM -0600, William Hubbs wrote:
> > 1) Start migrating packages along with upstream and have everyone who
> > has a separate /usr (including me by the way) start using an initramfs
> > of some kind, either dracut or one that we generate specifically for
> > gentoo. The reason I suggest the initramfs, is, unfortunately if we
> > migrate everything, nothing else would work.
>
> I use a separate /usr with LVM on all my systems. My root partition uses
> RAID1. And I never had the need for an initramfs of any kind. Also, there
> are some major hurdles to take when it comes to getting an initramfs working
> with SELinux. Most initramfs implementations I saw are not SELinux aware, so
> all changes they make to the system either result in failures when they try,
> or failures when the root-switch occurs.

dracut fully supports SELinux (it's used in Fedora which has this
SELinux horror on by default).

> > 3) Try to maintain things the way they are as long as possible.
>
> I'm all for this one.
>
> But if people really want to focus on initramfs, I'd appreciate some
> documentation help on it. Not only on how to create one, but also why it is
> necessary, how to manage initramfs'es, the concepts underlying, etc.

Short version: use dracut.

--
Olivier Crête
tester@gentoo.org
Gentoo Developer

On Sun, 01 Jan 2012 15:21:24 -0500
Olivier Crête <tester@gentoo.org> wrote:
> Honestly, so many things just work on MacOS and just need hours of
> tweaking for us..

The problem with "just works" is that when it breaks, it can't be
fixed. Not being able to handle /usr on its own filesystem is a perfect
example of this.

--
Ciaran McCreesh

Olivier Crête wrote:
> On Sun, 2012-01-01 at 01:33 -0600, Matthew Thode wrote:
>> On Sun, 01 Jan 2012 02:12:22 -0500
>> Olivier Crête<tester@gentoo.org> wrote:
>> All of my systems currently have a seperate /usr that is mounted at
>> boot. Unfortunately I do agree that this is not something that we can
>> fight. This was brought up earlier and the only thing we can do
>> for people like myself (who mount /usr at boot) is to create a simple
>> initramfs that only has the purpose of mounting /usr at boot. The main
>> thing I don't like about initramfs is that we have to regenerate it any
>> time we update the packages that get included in it.
> That's why you have dracut to do it for you.
>
>

Which is keyworded at this point. Stable users do what?

Dale

:-) :-)

--
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!

Miss the compile output? Hint:
EMERGE_DEFAULT_OPTS="--quiet-build=n"