Mailing List Archive

On Wed, Jan 4, 2012 at 12:06 AM, William Hubbs <williamh@gentoo.org> wrote:
> On Tue, Jan 03, 2012 at 11:40:02AM -0500, Ian Stakenvicius wrote:
>> I don't think anyone's asked this yet:
>>
>> Do we NEED to deprecate /bin,/sbin,/usr/sbin,/lib ?  I realize that
>> udev/kmod/systemd are moving, but there isn't anything in particular
>> that would require everything else to move, is there?
>
> Well, I don't think everything is going to move immediately. The way I
> see this happening is, udev/systemd/kmod are moving first, then other
> upstreams will move their software.
>

From what I can make out, *only* udev and systemd are making this a
hard-and-fast thing so far. kmod has added a configure argument, and
no one else has moved yet. In reality, fedora is patching a lot of
packages to make them install in /usr.

*If* GNU packages decide to move to /usr, *then* we can contemplate
moving. Till then, I say let's just do whatever Debian is doing.

--
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team

On 03-01-2012 13:39:14 -0600, William Hubbs wrote:
> > in /usr/lib/modules even though the kernel installs them
> > in /lib/modules.. So yes, upstream will force these symlinks on us too.
>
> I just looked at the commit in kmod for this. It can be worked around
> with a ./configure switch until the kernel switches their install
> location, so they aren't forcing this one.

Current git even sets the default to "", so in fact they went back to
just /lib/modules.


--
Fabian Groffen
Gentoo on a different level

On Wed, Jan 4, 2012 at 1:05 AM, Rich Freeman <rich0@gentoo.org> wrote:
> part of).  For example, if eventually you can't run gnome without
> systemd where does that leave bsd gentoo users?

Is Mesa support on BSD really all that up-to-date these days? I don't
expect that they keep up with bugfixes that well. For instance, Radeon
works best with KMS + Gallium and afaik that has no driver for BSD at
all. I don't think GNOME Shell is stable on BSD at all.

> Gentoo is about
> choice, and various upstream efforts are moving in the direction of
> giving users only one choice - take it or leave it.

If you're arguing purely on the basis of BSD, I think it's a lost
cause. They're so far behind Linux that it's not even funny anymore.

> How do you
> install KDE and Gnome on the same system when they eventually want
> different sysvinit implementations.

I doubt that's going to happen, though. No DE other than GNOME is
interested in vertical integration. Even if someone is, it's a
technical problem to be solved with a technical solution. "Every
problem in computer science can be solved by adding another layer of
indirection".

> Will the RedHat and Ubuntu of the
> future have no more in common than Tivo and Android do today?
>

Setting aside the silly parts of comparison you've made, the rest is
already true from the user's PoV. The two have drastically different
UIs, and their packages are incompatible (rpm vs deb, yum vs apt). If
some applications are indeed common between the two, it's no surprise
since most of those run on Windows too.

--
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team

On Tue, Jan 03, 2012 at 08:12:06PM +0100, Fabian Groffen wrote:
> > I think the best way to do this part of it is going to be to just follow
> > the upstream packages. When they release a new version that installs in
> > /usr, just allow that to happen. Eventually there will be very little in
> > /{bin,sbin,lib}, maybe nothing besides a couple of symbolic links like
> > /bin/sh.
>
> What packages would that be? If you're thinking about coreutils, just
> trim down the ebuild by not moving some of the tools to /bin. Our
> ebuild makes it conform to FHS, not the coreutils buildsystem itself.

Yes, coreutils will have to be reworked in that case. I don't know what
the upstream build system does, but we will have to take a look at it.

I'll have to go through on my system at
least and find all of the ebuilds that install things in
/{bin,sbin,lib}. I'll open a tracker bug as soon as udev-176 is
released; this will list all of the things we need to do to complete the
migration.

Basically I have these in my head:

* mask udev-176 in the tree.
* figure out and document how to make a simple initramfs with dracut.
* unmask udev 176 making sure to point users with a separate /usr
partition to how to make an initramfs (I could probably do this with
ewarns in the ebuild and maybe a news item before we go stable).
* stabilize a version of dracut.
* stabilize >=udev-176 and kmod.
* Now start stabilizing packages with things installed in /usr instead
of /.

If you do not have separate /usr, you could just enjoy the ride. All
of this would be transparent to you. If you do have separate /usr, the
critical step will be bringing up an initramfs once you upgrade to
udev-176. Once that is done, you could also just enjoy the ride.

Thoughts?

William

On Tue, 2012-01-03 at 14:35 -0500, Rich Freeman wrote:
> 2012/1/3 Olivier Crête <tester@gentoo.org>:
> > A couple years ago, Gentoo was the forward looking distribution, ready
> > to try radical changes that break existing assumption, like our init
> > scripts with dependencies or our early use of udev. These days, I see so
> > much resistance to progress, it makes me sad.
>
> I think the key is to keep huge changes optional to start with. This
> one feels like it is being pushed upon us.
>
> I don't really have a big problem with moving to /usr and all that.
> However, I do have some concerns with the larger direction that
> everybody is taking with vertical integration (which this is just a
> part of). For example, if eventually you can't run gnome without
> systemd where does that leave bsd gentoo users? Gentoo is about
> choice, and various upstream efforts are moving in the direction of
> giving users only one choice - take it or leave it. How do you
> install KDE and Gnome on the same system when they eventually want
> different sysvinit implementations. Will the RedHat and Ubuntu of the
> future have no more in common than Tivo and Android do today?

Well, don't worry, the KDE people don't have the will or the means to
make their own init system.. And rumor is that Ubuntu may be switching
to systemd in the near future too.

With a Linux kernel, you already need some Linux specific things like
udev, ifconfig/ip, etc. In the new world, you also have a Linux specific
init system. The BSD people are free to do whatever they want, they can
try to keep up with the Linux kernel, but good luck to them. Or they can
stay in the 80s. My advice to them is to admit that Linux is so far
ahead that they can't catch up and just join us.

Honestly, we should not promote choice at the expense of quality,
maintainability and reliability and these are the decisions that have
been made by the udev/systemd/etc upstreams. All of the init systems of
each Linux distribution has been doing the same thing in slightly
incompatible ways, so everyone has to maintain separate init scripts, on
each distro you have to remember where to set things like the hostname
(/etc/conf.d/hostname, /etc/hostname, /etc/rc.d/hostname, /etc/system/hostname, etc/wtf), etc. One of the key goals of systemd is to reduce this confusion by standardising the boot process across all distributions.

Vertical integration is the only way we can make things "Just Work" for
the users, we tried to do abstraction layers (HAL for example), but it
has been a failure. In the GNOME project, we're trying to make the Linux
desktop awesome, and we plan to fix any part of the puzzle that would
prevent us from achieving that goal.

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

On Tue, Jan 03, 2012 at 01:50:25PM -0500, Olivier Crête wrote:
> On Mon, 2012-01-02 at 10:41 +0200, Eray Aslan wrote:
> > RedHat made some bad design decisions on RPM (.rpmnew files anyone?) and
> > udev. Udev was probably salvagable before systemd but noone has the
> > motivation or the man-power to manage the huge delta that would result
> > now. It would probably amount to forking udev. So people are following
> > along even if they are unhappy.
>
> This is completely unrelated to RPMs.

The same packages are moving towards a system where config files reside
under /usr/lib with users overriding the defaults in /etc
(/usr/lib/udev/rules.d/ and /etc/udev/rules.d). I doubt this would have
come about if RPM had a sensible way of dealing with config files -if
they had etc-update/dispatch-conf for example.

--
Eray Aslan <eras@gentoo.org>

On 03-01-2012 14:01:20 -0600, William Hubbs wrote:
> On Tue, Jan 03, 2012 at 08:12:06PM +0100, Fabian Groffen wrote:
> > > I think the best way to do this part of it is going to be to just follow
> > > the upstream packages. When they release a new version that installs in
> > > /usr, just allow that to happen. Eventually there will be very little in
> > > /{bin,sbin,lib}, maybe nothing besides a couple of symbolic links like
> > > /bin/sh.
> >
> > What packages would that be? If you're thinking about coreutils, just
> > trim down the ebuild by not moving some of the tools to /bin. Our
> > ebuild makes it conform to FHS, not the coreutils buildsystem itself.
>
> Yes, coreutils will have to be reworked in that case. I don't know what
> the upstream build system does, but we will have to take a look at it.

Upstream build system has all binaries just installed in $(PREFIX)/bin,
like normal autoconf-based projects.

> I'll have to go through on my system at
> least and find all of the ebuilds that install things in
> /{bin,sbin,lib}. I'll open a tracker bug as soon as udev-176 is
> released; this will list all of the things we need to do to complete the
> migration.

I would suggest not to do this. It's more interesting to know what udev
really requires to be in /usr/bin.

> Basically I have these in my head:
>
> * mask udev-176 in the tree.
> * figure out and document how to make a simple initramfs with dracut.
> * unmask udev 176 making sure to point users with a separate /usr
> partition to how to make an initramfs (I could probably do this with
> ewarns in the ebuild and maybe a news item before we go stable).
> * stabilize a version of dracut.
> * stabilize >=udev-176 and kmod.
> * Now start stabilizing packages with things installed in /usr instead
> of /.

If the system can work with things being in /, why would we have to move
away from that? I don't like my systems breaking, and this is a likely
candidate to do so. E.g. also gcc-config needs changing for this. And
baselayout/openrc. How many locations for functions.sh are there
already in scripts now?

> If you do not have separate /usr, you could just enjoy the ride. All
> of this would be transparent to you. If you do have separate /usr, the
> critical step will be bringing up an initramfs once you upgrade to
> udev-176. Once that is done, you could also just enjoy the ride.
>
> Thoughts?

Let's just first see how the rest of the world reacts to all of this.
We've waited serveral years with baselayout-1 -> openrc/baselayout-2, so
I wouldn't mind doing some waiting here too. It doesn't look like
there's much going to change. I can't imagine bash devs dropping /bin
from bare default PATH (we control the default PATH), neither that glibc
folks drop /lib from the search path (although more likely since it's
more limited to Linux).

Perhaps, even start to experiment with this in an overlay (it's
relatively easy to start, just disable gen_usr_ldscript, fix bash to
pass --prefix=/usr and coreutils not to move bins) and try to see how
hard migration is with zlib moving around (shouldn't be too hard with
ELF, is a downright drama with Mach-O && without portage's
preserve-libs).

But also, starting to experiment to see how easy it is to let things as
they are. udev might consider a world without /bin and /lib, but maybe
what's in there isn't much interesting to it anyway. Most stuff is
installed in /usr for a reason.


--
Fabian Groffen
Gentoo on a different level

On Sun, Jan 01, 2012 at 03:21:47PM -0500, Olivier Crête wrote:
> > 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).

Yes... but no.

Fedora uses SELinux but using a policy where most domains run unconfined
(meaning they're allowed to do almost anything) and mostly the
network-facing services are confined.

I just got dracut working on a SELinux system here (took me a few hours to
compile a SELinux domain for dracut, because the application doesn't work
with the standard privileges of an administrator) and it boots up (up to
and including "dracut: Switching root") until SELinux is activated.

From that point onwards, it's dead since its using wrong labels and wrong
context.

It is SELinux-aware (it mounts the selinuxfs and such) but I think I'll need
to edit the /usr/lib/dracut/* stuff to get it to boot up properly on a
SELinux system that doesn't use unconfined domains...

I'll try to get it working the next few days. Once (or when) it does, I'll
submit the necessary patches to wherever is necessary.

Wkr,
Sven Vermeulen

On Tue, Jan 03, 2012 at 10:22:15PM +0100, Fabian Groffen wrote:
> > I'll have to go through on my system at
> > least and find all of the ebuilds that install things in
> > /{bin,sbin,lib}. I'll open a tracker bug as soon as udev-176 is
> > released; this will list all of the things we need to do to complete the
> > migration.
>
> I would suggest not to do this. It's more interesting to know what udev
> really requires to be in /usr/bin.

The issues involve binaries in /{bin,sbin} that link to libraries in
/usr/lib as well as packages that install udev rules that run binaries.

>
> > Basically I have these in my head:
> >
> > * mask udev-176 in the tree.
> > * figure out and document how to make a simple initramfs with dracut.
> > * unmask udev 176 making sure to point users with a separate /usr
> > partition to how to make an initramfs (I could probably do this with
> > ewarns in the ebuild and maybe a news item before we go stable).
> > * stabilize a version of dracut.
> > * stabilize >=udev-176 and kmod.

The part of the process above is the part I am the most concerned about.
I think we need to get everyone who is using separate /usr switched over
to an initramfs with udev 176, and this needs to happen sooner than
later, without using things like wrapper scripts or ways to avoid the
initramfs. Those are just stop-gap options that will only work until
some package they are depending on migrates to /usr.

Once we get to this point in the process, I think we could take each
package that installs things in / individually and migrate it. But, I
think the part of the process listed above needs to happen sooner than
later.

What are your thoughts?

William

On Tue, 3 Jan 2012 17:09:18 -0600
William Hubbs <williamh@gentoo.org> wrote:

> On Tue, Jan 03, 2012 at 10:22:15PM +0100, Fabian Groffen wrote:
> > > I'll have to go through on my system at
> > > least and find all of the ebuilds that install things in
> > > /{bin,sbin,lib}. I'll open a tracker bug as soon as udev-176 is
> > > released; this will list all of the things we need to do to
> > > complete the migration.
> >
> > I would suggest not to do this. It's more interesting to know what
> > udev really requires to be in /usr/bin.
>
> The issues involve binaries in /{bin,sbin} that link to libraries in
> /usr/lib as well as packages that install udev rules that run
> binaries.
>
> >
> > > Basically I have these in my head:
> > >
> > > * mask udev-176 in the tree.
> > > * figure out and document how to make a simple initramfs with
> > > dracut.
> > > * unmask udev 176 making sure to point users with a separate /usr
> > > partition to how to make an initramfs (I could probably do this
> > > with ewarns in the ebuild and maybe a news item before we go
> > > stable).
> > > * stabilize a version of dracut.
> > > * stabilize >=udev-176 and kmod.
>
> The part of the process above is the part I am the most concerned
> about. I think we need to get everyone who is using separate /usr
> switched over to an initramfs with udev 176, and this needs to happen
> sooner than later, without using things like wrapper scripts or ways
> to avoid the initramfs. Those are just stop-gap options that will
> only work until some package they are depending on migrates to /usr.
>
> Once we get to this point in the process, I think we could take each
> package that installs things in / individually and migrate it. But, I
> think the part of the process listed above needs to happen sooner than
> later.
>
> What are your thoughts?

I agree. Especially with the last part.

Thus, we need to:

1) fix and stabilize packages necessary to create an initramfs,
2) prepare really good instructions for creating one,
3) prepare a news item for users.

For the case of really simple initramfs mounting / and /usr only, I can
even create a small tool on klibc if anyone's interested.

--
Best regards,
Michał Górny

Ian Stakenvicius posted on Tue, 03 Jan 2012 13:18:06 -0500 as excerpted:

> ... if Gentoo's installed on a system (regardless of platform, and
> leaving out the Prefix installs), the filesystem is up to gentoo right?
> ie, there wouldn't be a need for a particular platform to stick with
> FHS-2.3 would there? Once we migrate to FHS-3.0, we can migrate all
> archs and profiles at the same time?

Filesystem or file hierarchy? At least on Gentoo, the filesystem choice
has always been up to the installing admin, but in context I believe you
mean file hierarchy.

As for archs, I'm not familiar with the minor ones and really only know
about x86/amd64, but I don't see any reason the others, possibly with an
exception or two that could be single-cased as needed, can't migrate at
the same time. I do know some of them get stuck on for instance, older
glibc, for long periods, tho, and it wouldn't surprise me at all to have
one or more of the minor ones stuck on an old version of something that
would either need monkey-patch-backported to deal with the new FHS, or
have special-cases for various packages to deal with older layout due to
the old versions of one or two packages holding things up for that arch.

AFAIK vapier's the gentoo guy with the knowledge there, due to all his
work on exotic stuff like superh/sh and the new x32 stuff, or at least
he's the one that seems most active in discussions such as this.

--
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 Tue, 2012-01-03 at 22:47 +0000, Sven Vermeulen wrote:
> On Sun, Jan 01, 2012 at 03:21:47PM -0500, Olivier Crête wrote:
> > > 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).
>
> Yes... but no.
>
> Fedora uses SELinux but using a policy where most domains run unconfined
> (meaning they're allowed to do almost anything) and mostly the
> network-facing services are confined.
>
> I just got dracut working on a SELinux system here (took me a few hours to
> compile a SELinux domain for dracut, because the application doesn't work
> with the standard privileges of an administrator) and it boots up (up to
> and including "dracut: Switching root") until SELinux is activated.
>
> From that point onwards, it's dead since its using wrong labels and wrong
> context.
>
> It is SELinux-aware (it mounts the selinuxfs and such) but I think I'll need
> to edit the /usr/lib/dracut/* stuff to get it to boot up properly on a
> SELinux system that doesn't use unconfined domains...
>
> I'll try to get it working the next few days. Once (or when) it does, I'll
> submit the necessary patches to wherever is necessary.

My understanding is that the dracut maintainer recently removed SELinux
support and moved it into systemd. So patches that go in the other
directions aren't likely to go very far. My understanding is also that
it is now systemd doing all the SELinux magic (relabelling, etc), if you
don't want to use systemd, you should at least look at the relevant code
[1] [2] in systemd and do that in your own init system. And if you have
any questions, just ask Lennart, he's actually surprisingly helpful.

[1] http://cgit.freedesktop.org/systemd/tree/src/selinux-setup.c
[2] http://cgit.freedesktop.org/systemd/tree/src/mount-setup.c#n386

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

William Hubbs schrieb:
> On Tue, Jan 03, 2012 at 10:22:15PM +0100, Fabian Groffen wrote:
>>> I'll have to go through on my system at
>>> least and find all of the ebuilds that install things in
>>> /{bin,sbin,lib}. I'll open a tracker bug as soon as udev-176 is
>>> released; this will list all of the things we need to do to complete the
>>> migration.
>>
>> I would suggest not to do this. It's more interesting to know what udev
>> really requires to be in /usr/bin.
>
> The issues involve binaries in /{bin,sbin} that link to libraries in
> /usr/lib as well as packages that install udev rules that run binaries.
>
>>
>>> Basically I have these in my head:
>>>
>>> * mask udev-176 in the tree.
>>> * figure out and document how to make a simple initramfs with dracut.
>>> * unmask udev 176 making sure to point users with a separate /usr
>>> partition to how to make an initramfs (I could probably do this with
>>> ewarns in the ebuild and maybe a news item before we go stable).
>>> * stabilize a version of dracut.
>>> * stabilize >=udev-176 and kmod.
>
> The part of the process above is the part I am the most concerned about.
> I think we need to get everyone who is using separate /usr switched over
> to an initramfs with udev 176, and this needs to happen sooner than
> later, without using things like wrapper scripts or ways to avoid the
> initramfs. Those are just stop-gap options that will only work until
> some package they are depending on migrates to /usr.
>
> Once we get to this point in the process, I think we could take each
> package that installs things in / individually and migrate it. But, I
> think the part of the process listed above needs to happen sooner than
> later.
>
> What are your thoughts?
>
> William
>

If i did not miss something in this long thread, we are currently mostly
talking about udev needing /usr to be mounted when it starts. Systemd is
not our default init system and other packages are currently not
changing their default. Since udev is our default and that requires a
mounted /usr, we should show our users their options with a suggested
default:

1. minimal initramfs (default suggestion)
2. switching from udev to mdev (avoids required /usr of udev)
3. some wrapper script to mount /usr before udev starts

for 1: I use myself a self-created initramfs, which has worked fine for
many kernel releases, the only adjustment needed was back with kernel
2.6.27. With this in mind, some default minimal initramfs should be
doable without much maintaincence work.

for 2: from what i did read up to now, this option looks interesting for
those people, who dont want to use an initramfs or other mounting script
and dont use advanced features of udev, so especially server setups or
minimal desktop systems



For the idea of complete migration to /usr, i see no reason to go this
route in advance. Just keep with our default install locations and
follow upstream, if and where needed.
If a package switches to /usr and depending packages follow, fine, let
them do that and we can follow without much additional work.
There is no need to do such migration beforehand or changing our install
location in advance.


So in short:

1. Tell our users about the change in udev and show them their options
with a suggested default one.
2. for the rest, just calm down, follow upstreams and only change the
install location where needed. No need for mental pressure without an
actual pressure. ;-)

--

Thomas Sachau
Gentoo Linux Developer

On Wed, 04 Jan 2012 01:47:38 +0100
Thomas Sachau <tommy@gentoo.org> wrote:

> 2. switching from udev to mdev (avoids required /usr of udev)
> 3. some wrapper script to mount /usr before udev starts

These two should be really discouraged as a cheap, temporary solution.
We should not support hate-admining. I personally think that busybox is
ready to go into /usr even earlier than udev.

> For the idea of complete migration to /usr, i see no reason to go this
> route in advance. Just keep with our default install locations and
> follow upstream, if and where needed.

What about upstreams who do not care? In other words, all those
packages which we hack to install into rootfs?

--
Best regards,
Michał Górny

The 03/01/12, G.Wolfe Woodbury wrote:

> The problem is that one group of developers is ignoring years of history
> and purpose in the separation of /bin and /usr/bin and the ability of
> having a separate /usr. This is in the udev development team and they
> /deliberately/ placed or used some programs in /usr/bin instead /bin and
> requiring that /usr bee in the root partition.

The udev team has nothing to do with the /usr mount requirement. Lot of
packages hooked themselves via udev while they had binaries or
dependencies in /usr.

> I will note that the historical separation of the /usr stems from the
> days of user home directories being in /usr/home instead of /home. It
> is getting to the point that the security aspects of having a read-only
> mount for userspace executables is being overridden by developer fiat.

It's a joke?

--
Nicolas Sebrecht

Michał Górny schrieb:
> On Wed, 04 Jan 2012 01:47:38 +0100
> Thomas Sachau <tommy@gentoo.org> wrote:
>
>> 2. switching from udev to mdev (avoids required /usr of udev)
>> 3. some wrapper script to mount /usr before udev starts
>
> These two should be really discouraged as a cheap, temporary solution.
> We should not support hate-admining. I personally think that busybox is
> ready to go into /usr even earlier than udev.

Please give us a bit more than just your opinion.

Why do you see mdev as a temporary solution?

And this part was not about the movement to /usr at all, so why do you
suggest another movement here? And while you answer that, please also
tell us, why you want to migrate packages to a different install
location without a need.

>
>> For the idea of complete migration to /usr, i see no reason to go this
>> route in advance. Just keep with our default install locations and
>> follow upstream, if and where needed.
>
> What about upstreams who do not care? In other words, all those
> packages which we hack to install into rootfs?

They install and work fine, so just keep it this way. I did not see any
argument to move packages around, that work well and have no issue with
their current install location.


--

Thomas Sachau
Gentoo Linux Developer

On 3 January 2012 15:21, Walter Dnes <waltdnes@waltdnes.org> wrote:
> On Sat, Dec 31, 2011 at 07:59:47PM -0600, William Hubbs 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.
>
>  4) Following pointers from Zac Medico and others, I've managed to get
> Gentoo running with busybox's mdev, instead of udev.  See
> http://archives.gentoo.org/gentoo-user/msg_bc91b392ee0f76376104591cdf7dc5f0.xml
> Executive summary... look Ma; no udev!

Does mdev support all the rules we have in /lib/udev/rules.d/? The
Internet is surprisingly mute on this subject, but a quick grep
through the busybox source doesn't turn up anything that suggests that
it might.

--
Arun Raghavan
http://arunraghavan.net/
(Ford_Prefect | Gentoo) & (arunsr | GNOME)

On Wed, Jan 4, 2012 at 7:58 AM, Arun Raghavan <ford_prefect@gentoo.org> wrote:
> Does mdev support all the rules we have in /lib/udev/rules.d/? The
> Internet is surprisingly mute on this subject, but a quick grep
> through the busybox source doesn't turn up anything that suggests that
> it might.

I think the main use case for mdev is to do a one-time creation of
typical device nodes with minimal use of resources. Perhaps you might
say mdev is to udev as dash is to bash (though dash is
syntax-compatible with bash, or at least it aims to be, and I'm not
sure the same is true of mdev vs udev).

If you're running a server or embedded device and you just need it to
detect your hard drives and maybe a few devices you're willing to
write scripts for, then it is a perfect choice. I have no idea how
well it supports hotplugging of usb devices and such.

For a desktop - it seems like a poor choice. By the time you enhanced
it to do everything udev does you'll ruin it for embedded use and
probably be stuck with all the same issues we have with udev. Fork
udev if you must (good luck with that), but I don't really see mdev as
being a real competitor.

By all means write up an mdev howto and link it in the embedded guide
or if enough users are passionate about it perhaps even link it in the
handbook (as an alternative for adventurous users with special needs).
However, I just can't see it ever becoming the default on a
general-purpose distro like Gentoo (which aims to be all things to all
people as much as is supportable). Certainly it is in the spirit of
Gentoo to support it as an option for those willing to deal with the
downsides (don't expect your bluetooth keyboard to work automagically,
etc).

Rich

On Wed, Jan 4, 2012 at 6:43 PM, Rich Freeman <rich0@gentoo.org> wrote:
> On Wed, Jan 4, 2012 at 7:58 AM, Arun Raghavan <ford_prefect@gentoo.org> wrote:
>> Does mdev support all the rules we have in /lib/udev/rules.d/? The
>> Internet is surprisingly mute on this subject, but a quick grep
>> through the busybox source doesn't turn up anything that suggests that
>> it might.
>
> I think the main use case for mdev is to do a one-time creation of
> typical device nodes with minimal use of resources.

In that case, you don't need a userspace daemon at all. Just use
devtmpfs. That'll use even lower resources.

--
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team

Michał Górny wrote:

> On Sun, 1 Jan 2012 08:53:26 +0000
> 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.
>
> Simple? Should I start requesting additional packages moved into rootfs
> because I feel like needing them? Things can and will go more ugly,
> and I wouldn't be surprised if anytime soon people will start
> complaining because they ran out of space on their rootfs.
>
Well, it is conceptually quite simple: if it's needed in single-user mode to
get your system up and running again, it belongs in rootfs, and if it isn't,
then leave it in user-land.

The thing I don't understand is why it is necessary to move stuff from /bin
to /usr/bin. After all, if you're running the "approved" setup you don't
have a separate /usr so all the binaries are available from the get-go.

What does moving them enable that can't be done now?


Sure, if you have binaries in /bin that link to libraries in /usr/lib that
could be an issue, but only if you're running with a separate /usr and don't
have it mounted when udev starts. So again, not the "approved" setup, and
something you as an admin already have to deal with by making sure /usr is
mounted when udev starts (either via an initramfs, or by a tweak to udev
startup scripts[1].)

wrt GNU coreutils installing to /usr by default, that's so of every GNU
package, since they default to a prefix of /usr/local and it's up to a
distro (or the end-user) to configure them differently; in general the
package assumes it's an addition to the system, unless told otherwise.

(Additionally I'd say that binaries installed to /bin that require libraries
installed to /usr is a bug, but something that should be dealt with
separately. Though with the direction people seem to think is needed, I'm
not sure how much effort anyone will put into that.)

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

On Wed, Jan 4, 2012 at 8:50 AM, Steven J Long
<slong@rathaus.eclipse.co.uk> wrote:
> The thing I don't understand is why it is necessary to move stuff from /bin
> to /usr/bin. After all, if you're running the "approved" setup you don't
> have a separate /usr so all the binaries are available from the get-go.

Where is this approved setup documented? Consider guides like this one:
http://www.gentoo.org/doc/en/gentoo-x86+raid+lvm2-quickinstall.xml

While you're fixing that you might want to write up an "easy migration
guide" for anybody who followed our official docs in "the past" (with
"the past" including up to the moment that the raid+lvm guide is
updated)...

> Sure, if you have binaries in /bin that link to libraries in /usr/lib that
> could be an issue, but only if you're running with a separate /usr and don't
> have it mounted when udev starts. So again, not the "approved" setup, and
> something you as an admin already have to deal with by making sure /usr is
> mounted when udev starts (either via an initramfs, or by a tweak to udev
> startup scripts[1].)

Well, it is hard to think of a meaningful raid+lvm configuration that
doesn't require an initramfs of some sort with the dependence on files
in /usr during boot. So, getting our initramfs options improved and
supporting this configuration just makes sense regardless before we
unmask newer versions of udev.

Raid+lvm isn't exactly an unusual use-case. Many distros actually use
at least lvm by default now.

Rich

Rich Freeman wrote:

> On Wed, Jan 4, 2012 at 8:50 AM, Steven J Long
> <slong@rathaus.eclipse.co.uk> wrote:
>> The thing I don't understand is why it is necessary to move stuff from
>> /bin to /usr/bin. After all, if you're running the "approved" setup you
>> don't have a separate /usr so all the binaries are available from the
>> get-go.
>
> Where is this approved setup documented?

I could swear we were told in prior discussions on this list that a separate
/usr partition is not considered supported by upstream udev, but searching
all I can find is that an initramfs is required.[1]

Having read the other page[2] that has been pointed out, the answer to my
question "what does this enable that we can't do currently?" is:
snapshotting the OS by backing up just the /usr partition.

I can see the attraction in that, especially for organisations. Though it
does make me smile that it depends on having a separate /usr partition to
work. ;)

The whole saga has just seemed confused to me: one minute a separate /usr is
a terrible idea, the next we have to move every binary to /usr in order to
snapshot a separate /usr. Loath as I am to agree with him, I have to concur
with Ciaran McCreesh that this is "a case of carelessly letting the horse
escape and then trying to convince everyone that no-one needs a horse
anyway."[3]

> Well, it is hard to think of a meaningful raid+lvm configuration that
> doesn't require an initramfs of some sort with the dependence on files
> in /usr during boot. So, getting our initramfs options improved and
> supporting this configuration just makes sense regardless before we
> unmask newer versions of udev.
>
I was under the impression that anyone using lvm+raid (+luks) on root
already has an initramfs, and there are docs out there about that, but sure,
improving those docs and the software is always a good idea.

> Raid+lvm isn't exactly an unusual use-case. Many distros actually use
> at least lvm by default now.
>
Yeah I've been using lvm for several years now, with a separate /usr and no
initramfs, though not on root. For the last few months, I've been running
with the tweaked udev startup scripts I mentioned before, so /usr is mounted
before udev starts (which is possible since I don't have any requirement on
udev-initialised hardware to mount local drives.)

Regardless of the ability to backup just /usr, I'm still not convinced about
moving every binary there. It certainly isn't necessary, in that the
packages we install respect prefix, and there's no need to change the
ebuilds to make packages work; further most admins already have their own
backup scripts in-place.

I for one, would like to be able to run in single-user mode off just the
rootfs, in case for instance, something goes wrong with lvm and /usr won't
mount; and I don't want to duplicate all those utilities in an initramfs. If
that's not going to be possible, fair enough: that's life.

[1] http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken
[2] http://fedoraproject.org/wiki/Features/UsrMove
[3] http://article.gmane.org/gmane.linux.gentoo.devel/72130
--
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

On Wed, Jan 4, 2012 at 10:19 AM, Steven J Long
<slong@rathaus.eclipse.co.uk> wrote:
> I was under the impression that anyone using lvm+raid (+luks) on root
> already has an initramfs, and there are docs out there about that, but sure,
> improving those docs and the software is always a good idea.

Anybody running root on lvm+raid(+luks) is already using an initramfs.
However, the guide I linked does not run root on lvm/luks - just on
raid1, which does not require an initramfs. That guide puts
everything BUT root on LVM, assuming that baselayout/sysvinit/openrc
on root can mount everything else.

The existing initramfs tools do not yet mount /usr regardless. I'm
sure RedHat and others pursing a read-only /usr required at time of
boot will be looking to rectify this, so Gentoo is moving along with
upstream for dracut/etc here.

> Yeah I've been using lvm for several years now, with a separate /usr and no
> initramfs, though not on root. For the last few months, I've been running
> with the tweaked udev startup scripts I mentioned before, so /usr is mounted
> before udev starts (which is possible since I don't have any requirement on
> udev-initialised hardware to mount local drives.)

That's basically my configuration as well. However, I don't really
want to set the goal of making Gentoo support my own configuration.
In any case, having a more robust initramfs solution for separate /usr
should support this and many other configurations.

>
> Regardless of the ability to backup just /usr, I'm still not convinced about
> moving every binary there. It certainly isn't necessary, in that the
> packages we install respect prefix, and there's no need to change the
> ebuilds to make packages work; further most admins already have their own
> backup scripts in-place.

I think that the path of least resistance is to move with upstream -
let's not try to force everything into /usr unless that becomes a
consensus with many other distros. However, we can at least look to
accomodate things like udev that are moving in this direction so that
it doesn't create sparks within Gentoo.

>
> I for one, would like to be able to run in single-user mode off just the
> rootfs, in case for instance, something goes wrong with lvm and /usr won't
> mount; and I don't want to duplicate all those utilities in an initramfs. If
> that's not going to be possible, fair enough: that's life.
>

I hear you. No harm in supporting this as long as seems reasonable,
but you're going to be stuck without udev from the sound of things,
and that is a lot to lose.

You should give dracut a shot - it does quite a bit automagically
though for some reason it doesn't set up my raid properly (I can do it
with a simple mdadm --assemble --scan from the dracut shell), and it
doesn't mount /usr yet. So, it isn't there, but it does quite a bit
just the same.

Rich

On Wed, 04 Jan 2012 13:06:11 +0100
Thomas Sachau <tommy@gentoo.org> wrote:

> Michał Górny schrieb:
> > On Wed, 04 Jan 2012 01:47:38 +0100
> > Thomas Sachau <tommy@gentoo.org> wrote:
> >
> >> 2. switching from udev to mdev (avoids required /usr of udev)
> >> 3. some wrapper script to mount /usr before udev starts
> >
> > These two should be really discouraged as a cheap, temporary
> > solution. We should not support hate-admining. I personally think
> > that busybox is ready to go into /usr even earlier than udev.
>
> Please give us a bit more than just your opinion.
>
> Why do you see mdev as a temporary solution?

Because we will then return to this discussion at some later point
and people will start throwing excrements at us again. So let's be done
with this at once.

> And this part was not about the movement to /usr at all, so why do you
> suggest another movement here? And while you answer that, please also
> tell us, why you want to migrate packages to a different install
> location without a need.

Because we need to finally be able to fix mistakes made in the past
by other people.

> >> For the idea of complete migration to /usr, i see no reason to go
> >> this route in advance. Just keep with our default install
> >> locations and follow upstream, if and where needed.
> >
> > What about upstreams who do not care? In other words, all those
> > packages which we hack to install into rootfs?
>
> They install and work fine, so just keep it this way. I did not see
> any argument to move packages around, that work well and have no
> issue with their current install location.

What if, say, upstream introduces pkg-config file where our hacks will
cause it to be installed into /lib/pkgconfig? Should we then expand
the hack to cover that, and something else, and then another thing...

--
Best regards,
Michał Górny

On Wed, 04 Jan 2012 13:50:45 +0000
Steven J Long <slong@rathaus.eclipse.co.uk> wrote:

> (Additionally I'd say that binaries installed to /bin that require
> libraries installed to /usr is a bug, but something that should be
> dealt with separately. Though with the direction people seem to think
> is needed, I'm not sure how much effort anyone will put into that.)

/bin/bsdcpio
libexpat.so.1 => /usr/lib64/libexpat.so.1 (0x00007fa3c89e3000)
liblzma.so.5 => /usr/lib64/liblzma.so.5 (0x00007fa3c7be9000)
libcrypto.so.1.0.0 => /usr/lib64/libcrypto.so.1.0.0
(0x00007fa3c7418000)
/bin/expr
libgmp.so.10 => /usr/lib64/libgmp.so.10 (0x00007f7cf26cc000)
/bin/findmnt
libmount.so.1 => /usr/lib64/libmount.so.1 (0x00007fa23d614000)
/bin/grub2-mkfont
libfreetype.so.6 => /usr/lib64/libfreetype.so.6
(0x00007f1007a4c000)
/bin/grub2-mkimage
liblzma.so.5 => /usr/lib64/liblzma.so.5 (0x00007fa60d479000)
/bin/lowntfs-3g
libfuse.so.2 => /usr/lib64/libfuse.so.2 (0x00007f912ed48000)
/bin/mail
liblockfile.so.1 => /usr/lib64/liblockfile.so.1
(0x00007fb8e249c000)
/bin/systemctl
libdbus-1.so.3 => /usr/lib64/libdbus-1.so.3 (0x00007f6cfdf4c000)
/sbin/audisp-remote
libcap-ng.so.0 => /usr/lib64/libcap-ng.so.0 (0x00007fbd76aae000)
/sbin/irqbalance
libcap-ng.so.0 => /usr/lib64/libcap-ng.so.0 (0x00007fc5b8eb3000)
libglib-2.0.so.0 => /usr/lib64/libglib-2.0.so.0
(0x00007fc5b8b92000)
/sbin/rpcbind
libgssglue.so.1 => /usr/lib64/libgssglue.so.1
(0x00007fb209614000)

(and I tried not to list more than one file from a single package)

The list could be longer if I enabled more USE flags, I think. And for
example, I could see benefits of having sshd on rootfs as well, if we
kept the old definition of it.

--
Best regards,
Michał Górny