FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 01-01-2012, 12:59 AM
William Hubbs
 
Default rfc: locations of binaries and separate /usr

All,

a significant change is taking place with several upstreams that will affect
us in gentoo, so I wanted to bring it to the list for discussion.

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

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.

Please discuss; I want to hear what you think.

William
 
Old 01-01-2012, 05:16 AM
Ryan Hill
 
Default rfc: locations of binaries and separate /usr

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
 
Old 01-01-2012, 06:12 AM
Olivier Crête
 
Default rfc: locations of binaries and separate /usr

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
 
Old 01-01-2012, 06:33 AM
Matthew Thode (prometheanfire)
 
Default rfc: locations of binaries and separate /usr

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)
 
Old 01-01-2012, 06:33 AM
Patrick Lauer
 
Default rfc: locations of binaries and separate /usr

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 ...
 
Old 01-01-2012, 07:53 AM
Sven Vermeulen
 
Default rfc: locations of binaries and separate /usr

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
 
Old 01-01-2012, 08:09 AM
Nirbheek Chauhan
 
Default rfc: locations of binaries and separate /usr

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
 
Old 01-01-2012, 08:23 AM
Duncan
 
Default rfc: locations of binaries and separate /usr

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
 
Old 01-01-2012, 08:45 AM
Dale
 
Default rfc: locations of binaries and separate /usr

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"
 
Old 01-01-2012, 09:15 AM
Zac Medico
 
Default rfc: locations of binaries and separate /usr

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
 

Thread Tools




All times are GMT. The time now is 10:23 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org