[gentoo-dev] rfc: using /libexec

[gentoo-dev] rfc: using /libexec

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 422 bytes --]

All,

we just got the following bug report for openrc today [1].

On a gentoo 64 bit system, /lib is a symbolic link to /lib64, and this
causes breakage in openrc.

The simplest fix for this would be for us to add /libexec to baselayout
and start using it for platform-agnostic code. We have /usr/libexec, so
I don't know why we don't have /libexec. Should we?


William

[1] http://bugs.gentoo.org/show_bug.cgi?id=381783

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] rfc: using /libexec

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 755 bytes --]

On Tue, 6 Sep 2011 13:46:06 -0500
William Hubbs <williamh@gentoo.org> wrote:

> we just got the following bug report for openrc today [1].
> 
> On a gentoo 64 bit system, /lib is a symbolic link to /lib64, and this
> causes breakage in openrc.
> 
> The simplest fix for this would be for us to add /libexec to
> baselayout and start using it for platform-agnostic code. We
> have /usr/libexec, so I don't know why we don't have /libexec. Should
> we?

We don't have it because we usually don't want to introduce additional
directories in rootfs. Honestly, I'd rather see all stuff go to /usr
than introducing /libexec.

Other solution is finally to migrate to a multilib solution with no
symlinks.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] rfc: using /libexec

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 969 bytes --]

On Tue, Sep 06, 2011 at 09:20:38PM +0200, Michał Górny wrote:
> On Tue, 6 Sep 2011 13:46:06 -0500
> William Hubbs <williamh@gentoo.org> wrote:
> 
> > we just got the following bug report for openrc today [1].
> > 
> > On a gentoo 64 bit system, /lib is a symbolic link to /lib64, and this
> > causes breakage in openrc.
> > 
> > The simplest fix for this would be for us to add /libexec to
> > baselayout and start using it for platform-agnostic code. We
> > have /usr/libexec, so I don't know why we don't have /libexec. Should
> > we?
> 
> We don't have it because we usually don't want to introduce additional
> directories in rootfs. Honestly, I'd rather see all stuff go to /usr
> than introducing /libexec.

openrc cannot be installed in /usr, because it is
used to boot the system. Also remember that openrc is not used on linux
systems only, so we can't blindly assume that everyone would be fine
with us moving it to /usr.

William


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] rfc: using /libexec

[Olivier Crête]

[-- Attachment #1: Type: text/plain, Size: 1210 bytes --]

Hi,

On Tue, 2011-09-06 at 13:46 -0500, William Hubbs wrote:
> we just got the following bug report for openrc today [1].

The solution to that bug is probably to use /lib*/.. instead of /lib/...
as the path you use ?

> On a gentoo 64 bit system, /lib is a symbolic link to /lib64, and this
> causes breakage in openrc.

That sounds like an openrc bug to me.

> The simplest fix for this would be for us to add /libexec to baselayout
> and start using it for platform-agnostic code. We have /usr/libexec, so
> I don't know why we don't have /libexec. Should we?

/usr/libexec is not for platform-agnostic code, it is for platform
dependant executables that are not meant to be executed directly by the
user. /usr/lib/X/Y and /usr/libexec/Y should be exactly the same.

You may want to put all the executables in /usr/libexec anyway, as
having separate / and /usr is a outdated idea anyway, and most of the
other distros will make that completely impossible very soon. Be bold.
Fedora is even going to make /lib, /bin and /sbin symlinks to /usr.

My 2 cents (as the guy who made the /lib->/lib64 link in the first
place).

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] rfc: using /libexec

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 867 bytes --]

On Tuesday, September 06, 2011 14:46:06 William Hubbs wrote:
> we just got the following bug report for openrc today [1].
> 
> On a gentoo 64 bit system, /lib is a symbolic link to /lib64, and this
> causes breakage in openrc.

that specific report sounds like using /run would fix things ?

as for the paths, openrc should be using the paths it installs into.  so if 
we're installing into /lib64/rc..., then that's what we should be using.

> The simplest fix for this would be for us to add /libexec to baselayout
> and start using it for platform-agnostic code. We have /usr/libexec, so
> I don't know why we don't have /libexec. Should we?

same answer as last time people have asked about /libexec: no.  we dont need 
it, and it's ugly cruft that no other distro ive seen uses, and this isnt 
something we need to differentiate Gentoo.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] rfc: using /libexec

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1390 bytes --]

On Tue, Sep 06, 2011 at 05:21:40PM -0400, Mike Frysinger wrote:
> On Tuesday, September 06, 2011 14:46:06 William Hubbs wrote:
> > we just got the following bug report for openrc today [1].
> > 
> > On a gentoo 64 bit system, /lib is a symbolic link to /lib64, and this
> > causes breakage in openrc.
> 
> that specific report sounds like using /run would fix things ?

I haven't really looked at using /run for anything in openrc on linux,
but that might be possible once we have it installed in baselayout.

I don't think it would fix this issue though.

> as for the paths, openrc should be using the paths it installs into.  so if 
> we're installing into /lib64/rc..., then that's what we should be using.

We are installing into /lib/rc, but /lib is a symlink on 64 bit systems,
so we are having an issue resolving the path.

> > The simplest fix for this would be for us to add /libexec to baselayout
> > and start using it for platform-agnostic code. We have /usr/libexec, so
> > I don't know why we don't have /libexec. Should we?
> 
> same answer as last time people have asked about /libexec: no.  we dont need 
> it, and it's ugly cruft that no other distro ive seen uses, and this isnt 
> something we need to differentiate Gentoo.

The same thing should be applied to /usr/libexec then shouldn't it?
(just asking for more info here)

William


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] rfc: using /libexec

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 882 bytes --]

On Tue, Sep 06, 2011 at 04:45:43PM -0500, William Hubbs wrote:
> On Tue, Sep 06, 2011 at 05:21:40PM -0400, Mike Frysinger wrote:
> > On Tuesday, September 06, 2011 14:46:06 William Hubbs wrote:
> > > we just got the following bug report for openrc today [1].
> > > 
> > > On a gentoo 64 bit system, /lib is a symbolic link to /lib64, and this
> > > causes breakage in openrc.
> > 
> > that specific report sounds like using /run would fix things ?
> 
> I haven't really looked at using /run for anything in openrc on linux,
> but that might be possible once we have it installed in baselayout.
> 
> I don't think it would fix this issue though.

Looking at this again, you are right, if rc_svcdir was /run/openrc,
there would no longer be an issue.

So, can you please fix baselayout to install /run?

http://bugs.gentoo.org/361349

Thanks much,

William


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] rfc: using /libexec

[Olivier Crête]

[-- Attachment #1: Type: text/plain, Size: 926 bytes --]

On Tue, 2011-09-06 at 16:45 -0500, William Hubbs wrote:
> On Tue, Sep 06, 2011 at 05:21:40PM -0400, Mike Frysinger wrote:
> > On Tuesday, September 06, 2011 14:46:06 William Hubbs wrote:
> > > The simplest fix for this would be for us to add /libexec to baselayout
> > > and start using it for platform-agnostic code. We have /usr/libexec, so
> > > I don't know why we don't have /libexec. Should we?
> > 
> > same answer as last time people have asked about /libexec: no.  we dont need 
> > it, and it's ugly cruft that no other distro ive seen uses, and this isnt 
> > something we need to differentiate Gentoo.
> 
> The same thing should be applied to /usr/libexec then shouldn't it?
> (just asking for more info here)

/usr/libexec is used by almost all major distros (except Debian), it has
been standardin Red Hat since before the FHS existed.

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] rfc: using /libexec

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1017 bytes --]

On Tuesday, September 06, 2011 17:58:12 Olivier Crête wrote:
> On Tue, 2011-09-06 at 16:45 -0500, William Hubbs wrote:
> > On Tue, Sep 06, 2011 at 05:21:40PM -0400, Mike Frysinger wrote:
> > > On Tuesday, September 06, 2011 14:46:06 William Hubbs wrote:
> > > > The simplest fix for this would be for us to add /libexec to
> > > > baselayout and start using it for platform-agnostic code. We have
> > > > /usr/libexec, so I don't know why we don't have /libexec. Should we?
> > > 
> > > same answer as last time people have asked about /libexec: no.  we dont
> > > need it, and it's ugly cruft that no other distro ive seen uses, and
> > > this isnt something we need to differentiate Gentoo.
> > 
> > The same thing should be applied to /usr/libexec then shouldn't it?
> > (just asking for more info here)
> 
> /usr/libexec is used by almost all major distros (except Debian), it has
> been standardin Red Hat since before the FHS existed.

and i think Debian is sane for not following ;)
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] rfc: using /libexec

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1048 bytes --]

On Tuesday, September 06, 2011 17:53:37 William Hubbs wrote:
> On Tue, Sep 06, 2011 at 04:45:43PM -0500, William Hubbs wrote:
> > On Tue, Sep 06, 2011 at 05:21:40PM -0400, Mike Frysinger wrote:
> > > On Tuesday, September 06, 2011 14:46:06 William Hubbs wrote:
> > > > we just got the following bug report for openrc today [1].
> > > > 
> > > > On a gentoo 64 bit system, /lib is a symbolic link to /lib64, and
> > > > this causes breakage in openrc.
> > > 
> > > that specific report sounds like using /run would fix things ?
> > 
> > I haven't really looked at using /run for anything in openrc on linux,
> > but that might be possible once we have it installed in baselayout.
> > 
> > I don't think it would fix this issue though.
> 
> Looking at this again, you are right, if rc_svcdir was /run/openrc,
> there would no longer be an issue.
> 
> So, can you please fix baselayout to install /run?

yes, i guess i can stop dragging my feet on this since it seems that every 
other distro is going this route as well
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] rfc: using /libexec

[Alexey Shvetsov]

Moving things as openrc to /usr/libexec will effectevely barake old 
systems with separtae / and /usr. So it isnt good idea

On Tue, 6 Sep 2011 16:45:43 -0500, William Hubbs wrote:
> On Tue, Sep 06, 2011 at 05:21:40PM -0400, Mike Frysinger wrote:
>> On Tuesday, September 06, 2011 14:46:06 William Hubbs wrote:
>> > we just got the following bug report for openrc today [1].
>> >
>> > On a gentoo 64 bit system, /lib is a symbolic link to /lib64, and 
>> this
>> > causes breakage in openrc.
>>
>> that specific report sounds like using /run would fix things ?
>
> I haven't really looked at using /run for anything in openrc on 
> linux,
> but that might be possible once we have it installed in baselayout.
>
> I don't think it would fix this issue though.
>
>> as for the paths, openrc should be using the paths it installs into. 
>> so if
>> we're installing into /lib64/rc..., then that's what we should be 
>> using.
>
> We are installing into /lib/rc, but /lib is a symlink on 64 bit 
> systems,
> so we are having an issue resolving the path.
>
>> > The simplest fix for this would be for us to add /libexec to 
>> baselayout
>> > and start using it for platform-agnostic code. We have 
>> /usr/libexec, so
>> > I don't know why we don't have /libexec. Should we?
>>
>> same answer as last time people have asked about /libexec: no.  we 
>> dont need
>> it, and it's ugly cruft that no other distro ive seen uses, and this 
>> isnt
>> something we need to differentiate Gentoo.
>
> The same thing should be applied to /usr/libexec then shouldn't it?
> (just asking for more info here)
>
> William

-- 
Best Regards,
Alexey 'Alexxy' Shvetsov
Petersburg Nuclear Physics Institute, Russia
Department of Molecular and Radiation Biophysics
Gentoo Team Ru
Gentoo Linux Dev
mailto:alexxyum@gmail.com
mailto:alexxy@gentoo.org
mailto:alexxy@omrb.pnpi.spb.ru

Re: [gentoo-dev] rfc: using /libexec

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 388 bytes --]

On Wed, 07 Sep 2011 12:17:21 +0300
Alexey Shvetsov <alexxy@gentoo.org> wrote:

> Moving things as openrc to /usr/libexec will effectevely barake old 
> systems with separtae / and /usr. So it isnt good idea

Old systems should migrate to initramfs, like it was already pointed
out before. Breakage is already there, you just don't notice it.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] rfc: using /libexec

[Alexey Shvetsov]

On Wed, 7 Sep 2011 11:27:05 +0200, Michał Górny wrote:
> On Wed, 07 Sep 2011 12:17:21 +0300
> Alexey Shvetsov <alexxy@gentoo.org> wrote:
>
>> Moving things as openrc to /usr/libexec will effectevely barake old
>> systems with separtae / and /usr. So it isnt good idea
>
> Old systems should migrate to initramfs, like it was already pointed
> out before. Breakage is already there, you just don't notice it.

Almoust all of my systems have lvm and separated /usr. And all of them 
still boot fine
-- 
Best Regards,
Alexey 'Alexxy' Shvetsov
Petersburg Nuclear Physics Institute, Russia
Department of Molecular and Radiation Biophysics
Gentoo Team Ru
Gentoo Linux Dev
mailto:alexxyum@gmail.com
mailto:alexxy@gentoo.org
mailto:alexxy@omrb.pnpi.spb.ru

Re: [gentoo-dev] rfc: using /libexec

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 876 bytes --]

On Wed, 07 Sep 2011 12:32:05 +0300
Alexey Shvetsov <alexxy@gentoo.org> wrote:

> On Wed, 7 Sep 2011 11:27:05 +0200, Michał Górny wrote:
> > On Wed, 07 Sep 2011 12:17:21 +0300
> > Alexey Shvetsov <alexxy@gentoo.org> wrote:
> >
> >> Moving things as openrc to /usr/libexec will effectevely barake old
> >> systems with separtae / and /usr. So it isnt good idea
> >
> > Old systems should migrate to initramfs, like it was already pointed
> > out before. Breakage is already there, you just don't notice it.
> 
> Almoust all of my systems have lvm and separated /usr. And all of
> them still boot fine

There's a difference between 'booting fine' and 'booting without any
silent failures and retries which fix stuff, not to mention ugly hacks
necessary to get things working'. And it will be even worse, at some
point.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] rfc: using /libexec

[Rich Freeman]

[-- Attachment #1: Type: text/plain, Size: 910 bytes --]

On Wed, Sep 7, 2011 at 5:27 AM, Michał Górny <mgorny@gentoo.org> wrote:

> On Wed, 07 Sep 2011 12:17:21 +0300
> Alexey Shvetsov <alexxy@gentoo.org> wrote:
>
> > Moving things as openrc to /usr/libexec will effectevely barake old
> > systems with separtae / and /usr. So it isnt good idea
>
> Old systems should migrate to initramfs, like it was already pointed
> out before. Breakage is already there, you just don't notice it.
>
>
Agreed, and once the official docs are updated and a working initramfs is
available we can consider moving forward with things that break separate
/usr.  That seemed to be the general consensus on the other thread.

Right now migrating to initramfs won't do any good, as Gentoo doesn't have
an initramfs available which mounts /usr.  No doubt once Fedora gets theirs
working we'll be able to copy it (assuming it is FOSS), or we can write our
own.

Rich

[-- Attachment #2: Type: text/html, Size: 1304 bytes --]

Re: [gentoo-dev] rfc: using /libexec

[Amadeusz Żołnowski]

[-- Attachment #1: Type: text/plain, Size: 1118 bytes --]

Excerpts from Rich Freeman's message of 2011-09-07 13:22:46 +0200:
> On Wed, Sep 7, 2011 at 5:27 AM, Michał Górny <mgorny@gentoo.org>
> wrote:
> > Old systems should migrate to initramfs, like it was already pointed
> > out before. Breakage is already there, you just don't notice it.
>
> Agreed, and once the official docs are updated and a working initramfs
> is available we can consider moving forward with things that break
> separate /usr.  That seemed to be the general consensus on the other
> thread.
> 
> Right now migrating to initramfs won't do any good, as Gentoo doesn't
> have an initramfs available which mounts /usr.  No doubt once Fedora
> gets theirs working we'll be able to copy it (assuming it is FOSS), or
> we can write our own.

Dracut supports mounting /usr since 013 if it's defined in /etc/fstab on
destination rootfs.  I'm still busy with my diploma to write Gentoo docs
about it and push Dracut into stabilization process, but as soon as I
finish I can move it forward.

-- 
Amadeusz Żołnowski

PGP key fpr: C700 CEDE 0C18 212E 49DA  4653 F013 4531 E1DB FAB5

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] rfc: using /libexec

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1306 bytes --]

On Wed, Sep 07, 2011 at 07:22:46AM -0400, Rich Freeman wrote:
> On Wed, Sep 7, 2011 at 5:27 AM, Michał Górny <mgorny@gentoo.org> wrote:
> 
> > On Wed, 07 Sep 2011 12:17:21 +0300
> > Alexey Shvetsov <alexxy@gentoo.org> wrote:
> >
> > > Moving things as openrc to /usr/libexec will effectevely barake old
> > > systems with separtae / and /usr. So it isnt good idea
> >
> > Old systems should migrate to initramfs, like it was already pointed
> > out before. Breakage is already there, you just don't notice it.
> >
> >
> Agreed, and once the official docs are updated and a working initramfs is
> available we can consider moving forward with things that break separate
> /usr.  That seemed to be the general consensus on the other thread.
> 
> Right now migrating to initramfs won't do any good, as Gentoo doesn't have
> an initramfs available which mounts /usr.  No doubt once Fedora gets theirs
> working we'll be able to copy it (assuming it is FOSS), or we can write our
> own.

I actually have a skeleton for an initramfs that does this here, I just
haven't figured out the last step, making an ebuild for it.

I think we can do a very simple initramfs that just mounts /usr/and /var
without dracut, but if you are using lvm, etc, you will have to use
dracut.

William

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] rfc: using /libexec

[Robin H. Johnson]

On Wed, Sep 07, 2011 at 07:22:46AM -0400, Rich Freeman wrote:
> Right now migrating to initramfs won't do any good, as Gentoo doesn't have
> an initramfs available which mounts /usr.  No doubt once Fedora gets theirs
> working we'll be able to copy it (assuming it is FOSS), or we can write our
> own.
The options for this are looking like:
- static initramfs that I proposed (WilliamH has an early prototype)
- genkernel
- dracut

WilliamH's prototype seems to mostly work, I just want to polish it some
and then release it. I think we can offer it as an easy default to
users, since it doesn't need to be rebuilt when the kernel is rebuilt at
all.

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

Re: [gentoo-dev] rfc: using /libexec

[Amadeusz Żołnowski]

[-- Attachment #1: Type: text/plain, Size: 930 bytes --]

Excerpts from Robin H. Johnson's message of 2011-09-07 20:02:57 +0200:
> On Wed, Sep 07, 2011 at 07:22:46AM -0400, Rich Freeman wrote:
> > Right now migrating to initramfs won't do any good, as Gentoo
> > doesn't have an initramfs available which mounts /usr.  No doubt
> > once Fedora gets theirs working we'll be able to copy it (assuming
> > it is FOSS), or we can write our own.
> The options for this are looking like:
> - static initramfs that I proposed (WilliamH has an early prototype)
> - genkernel
> - dracut
> 
> WilliamH's prototype seems to mostly work, I just want to polish it
> some and then release it. I think we can offer it as an easy default
> to users, since it doesn't need to be rebuilt when the kernel is
> rebuilt at all.

Dracut doesn't need either if we skip to include kernel modules.


-- 
Amadeusz Żołnowski

PGP key fpr: C700 CEDE 0C18 212E 49DA  4653 F013 4531 E1DB FAB5

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] rfc: using /libexec

[Rich Freeman]

[-- Attachment #1: Type: text/plain, Size: 1134 bytes --]

On Wed, Sep 7, 2011 at 2:02 PM, Robin H. Johnson <robbat2@gentoo.org> wrote:

> On Wed, Sep 07, 2011 at 07:22:46AM -0400, Rich Freeman wrote:
> > Right now migrating to initramfs won't do any good, as Gentoo doesn't
> have
> > an initramfs available which mounts /usr.  No doubt once Fedora gets
> theirs
> > working we'll be able to copy it (assuming it is FOSS), or we can write
> our
> > own.
> The options for this are looking like:
> - static initramfs that I proposed (WilliamH has an early prototype)
> - genkernel
> - dracut
>
> WilliamH's prototype seems to mostly work, I just want to polish it some
> and then release it. I think we can offer it as an easy default to
> users, since it doesn't need to be rebuilt when the kernel is rebuilt at
> all.
>
>
Agreed on all the comments along these lines.  I just wanted to suggest that
we not let the effort of breaking separate /usr get out too far ahead of the
effort to un-break it.  :)  As we can see from the openrc/handbook situation
it is easy to let the docs get out of sync (not pointing fingers here -
coordination is just an issue anytime you have many hands).

Rich

[-- Attachment #2: Type: text/html, Size: 1501 bytes --]

Re: [gentoo-dev] rfc: using /libexec

[Joshua Kinard]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09/07/2011 05:27, Michał Górny wrote:

> On Wed, 07 Sep 2011 12:17:21 +0300 Alexey Shvetsov <alexxy@gentoo.org>

> wrote:

> 

>> Moving things as openrc to /usr/libexec will effectevely barake old 

>> systems with separtae / and /usr. So it isnt good idea

> 

> Old systems should migrate to initramfs, like it was already pointed out

> before. Breakage is already there, you just don't notice it.

> 








I've used a separate /usr on every system I've ever built on Gentoo, and
some have filesystems going back years.  Never once have I had any issues
with separate / and /usr, and none of them use an initramfs.  Our own
security guide has made this recommendation for as long as I can remember
(so one can mark /usr as read-only on production setups, for example).

As far as initramfs, is this something that would need to go into the
kernel?  I hand-build all of my kernels, so any such initramfs package might
be better off as a standalone package available on the FS at kernel build
time.  I also netboot some of my systems, and they have limits on the total
size of the kernel image (7.2MB on one, ~40MB on another, etc), hence the
need to keep this small or find another way to do things.

Are there possibilities about breaking off just a small piece of openrc and
putting that into /run (or /boot)?  Enough of the core scripts so that it
can find /usr and mount it before continuing?


- -- 
Joshua Kinard
Gentoo/MIPS
kumba@gentoo.org
4096R/D25D95E3 2011-03-28

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

- --Emperor Turhan, Centauri Republic
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)

iQIcBAEBAgAGBQJOZ+KrAAoJENsjoH7SXZXjagYP/A9eGlVOw8e0+uZFz7RMo3wD
VYP4/oeQ3WMg7MdFX6YH9fbItyifG4szML1k1gIzh3woZrt9l6GWV7Jd0MM9jd9D
s26pSe3OhoKTdDImFwSQfQmwX9K6kiDa8K9x/Tj9bD9Z+/513VhpQgN/VH70UarX
LW/aoeLFwXx6ppU6WXj2u15e7H/3vkYRMYI+jDKrRxWXybT/IMM55B8mBgpum6dc
6cMNtBy751hYzk4ibszBUuezkbOh+yx/GUFksuBP/1J3u1Vvre7ejH184zvWveMS
ZBQtxsaAFz6/fhhhV9QqKy0bQq7V6oTK4QE6DC+BpkhBPkuR2kJ01PyDzZcqr9Lg
luSBJMSxpntbfm68P/HH7aQU3VeomSfucBjWcFRAJExd+EFQSLk7Z2s7ijkv2YHk
RvMypR8ARxumSj3vQE2XhG9c9GxZWMXF+3X9J7BGqdfBFCJjgOa4sYLnwsAMTtcq
jtJHW/dJ+SsJw7wAUeNRZsg+moMCLWknvbgPhd6dcSY36P6TytMMBw4NPbPTs96l
wC0zAX6Dk0/rCcm6H0U8FUJw/9MjAgnGG1Jo54ed11e+ePWzTuvLIs4b3OICN0TL
Uxr67jsIz5r14JlyaBL0rNCQVMFvjrxO4lhKI62xvLFX334a7uimKReJZIHXOjdt
CfygZB6C4kK8hPPbgks1
=Y0sh
-----END PGP SIGNATURE-----

Re: [gentoo-dev] rfc: using /libexec

[Rich Freeman]

[-- Attachment #1: Type: text/plain, Size: 2577 bytes --]

On Wed, Sep 7, 2011 at 5:31 PM, Joshua Kinard <kumba@gentoo.org> wrote:

> Never once have I had any issues
> with separate / and /usr, and none of them use an initramfs.


Ditto here, but that doesn't mean that problems don't exist.  Right now the
problems are likely to be subtle, perhaps arising only with certain
combinations of hardware/etc.  Maybe if you had a bluetooth keyboard or
something it might not work, or maybe if /usr were mounted on a bluetooth
hard drive or something (do they even make those?).

However, long-term it seems likely that the problems will continue to grow,
as more and more upstream packages move away from supporting a /usr that
isn't available at boot.

My general suggestion has been to hold the line where it is until we have
better support for mount /usr in initramfs, and it sounds like this is well
underway.


> As far as initramfs, is this something that would need to go into the
> kernel?


Well, the kernel comes with code for making an initramfs, but most likely it
would be implemented in a separate package.  The initramfs isn't part of the
kernel - it is loaded by grub at boot time and its address is passed to the
kernel.  So, the file needs to be on /boot.

I also netboot some of my systems, and they have limits on the total
> size of the kernel image (7.2MB on one, ~40MB on another, etc), hence the
> need to keep this small or find another way to do things.
>

I think that pxelinux supports initramfs - I know it supports initrd at
least and I don't think it makes any difference at the bootloader level.  In
fact, things like network booting are one of the drivers behind the Fedora
project to have dracut mount /usr.  Their plan is to just move everything
into /usr, allow it to be NFS-mounted, and then with one mountpoint
everything the system needs is available.  Eventually in Fedora /lib and
/bin will just be symlinks into /usr.  That will work fine as long as dracut
mounts /usr.

Are there possibilities about breaking off just a small piece of openrc and
> putting that into /run (or /boot)?  Enough of the core scripts so that it
> can find /usr and mount it before continuing?
>
>
Well, it certainly could be done, but it doesn't seem to be the direction
anybody else is going.  Instead the plan is to just create a very minimal
initramfs that gets the job done.  Using it would just be a matter of
installing the file and editing the boot line to load it.  Or, you can use
something like dracut or genkernel and get a more robust one.

Disclaimer - I'm not speaking for anybody but myself here...

Rich

[-- Attachment #2: Type: text/html, Size: 3434 bytes --]

Re: [gentoo-dev] rfc: using /libexec

[Robin H. Johnson]

On Wed, Sep 07, 2011 at 08:35:46PM -0400, Rich Freeman wrote:
> On Wed, Sep 7, 2011 at 5:31 PM, Joshua Kinard <kumba@gentoo.org> wrote:
> > Never once have I had any issues
> > with separate / and /usr, and none of them use an initramfs.
> Ditto here, but that doesn't mean that problems don't exist.  Right now the
> problems are likely to be subtle, perhaps arising only with certain
> combinations of hardware/etc.  Maybe if you had a bluetooth keyboard or
> something it might not work, or maybe if /usr were mounted on a bluetooth
> hard drive or something (do they even make those?).
Bluetooth keyboard wanted during early boot (to put in the root password
for a fsck repair after a hard shutdown) is one that bit me already.

> > As far as initramfs, is this something that would need to go into the
> > kernel?
> Well, the kernel comes with code for making an initramfs, but most likely it
> would be implemented in a separate package.  The initramfs isn't part of the
> kernel - it is loaded by grub at boot time and its address is passed to the
> kernel.  So, the file needs to be on /boot.
That's not always true, see further down.

> I also netboot some of my systems, and they have limits on the total
> > size of the kernel image (7.2MB on one, ~40MB on another, etc), hence the
> > need to keep this small or find another way to do things.
> I think that pxelinux supports initramfs - I know it supports initrd at
> least and I don't think it makes any difference at the bootloader level.  In
> fact, things like network booting are one of the drivers behind the Fedora
> project to have dracut mount /usr.  Their plan is to just move everything
> into /usr, allow it to be NFS-mounted, and then with one mountpoint
> everything the system needs is available.  Eventually in Fedora /lib and
> /bin will just be symlinks into /usr.  That will work fine as long as dracut
> mounts /usr.
That's not quite as easy for Kumba... Some of the MIPS bootloaders are
very limited. At least one of them requires that the initramfs be built
INTO the kernel.

> 
> Are there possibilities about breaking off just a small piece of openrc and
> > putting that into /run (or /boot)?  Enough of the core scripts so that it
> > can find /usr and mount it before continuing?
> Well, it certainly could be done, but it doesn't seem to be the direction
> anybody else is going.  Instead the plan is to just create a very minimal
> initramfs that gets the job done. 
That's pretty much the only stuff in WilliamH's prototype. Just enough
to get /usr mounted (/run comes for almost free at that point basically,
it's just mounting tmpfs on /newroot/run/).

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

Re: [gentoo-dev] rfc: using /libexec

[Nathan Phillip Brink]

[-- Attachment #1: Type: text/plain, Size: 576 bytes --]

On Wed, Sep 07, 2011 at 05:31:23PM -0400, Joshua Kinard wrote:
> Are there possibilities about breaking off just a small piece of openrc and
> putting that into /run (or /boot)?  Enough of the core scripts so that it
> can find /usr and mount it before continuing?

Isn't /run something that's supposed to be mounted with tmpfs
eventually? Currently /var/run's job is to hold volatile
data... Unless if I've missed something, I'm confused about why it
makes sense to install scripts or binaries there.

-- 
binki

Look out for missing or extraneous apostrophes!

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] rfc: using /libexec

[Joshua Kinard]

[-- Attachment #1: Type: text/plain, Size: 5092 bytes --]

On 09/07/2011 20:35, Rich Freeman wrote:

> On Wed, Sep 7, 2011 at 5:31 PM, Joshua Kinard <kumba@gentoo.org> wrote:
> 
>> Never once have I had any issues
>> with separate / and /usr, and none of them use an initramfs.
> 
> 
> Ditto here, but that doesn't mean that problems don't exist.  Right now the
> problems are likely to be subtle, perhaps arising only with certain
> combinations of hardware/etc.  Maybe if you had a bluetooth keyboard or
> something it might not work, or maybe if /usr were mounted on a bluetooth
> hard drive or something (do they even make those?).


We should document these oddball hardware cases when they arise, but I
would wager that they are exceptions, not rules.  We shouldn't upend an
established concept (splitting /usr off) for what may possibly be
curious corner cases of hardware combos.  My general knowledge of Linux
always indicated /usr was entirely optional, from the standpoint of
reaching an operable console, I.e., single-user mode.  Granted, you
can't do much on a setup where /usr is on its own partition, yet
inaccessible due to some issue, but if lack of /usr doesn't hinder
recovery efforts (those needed to make the system capable of mounting
/usr), then things are okay.

If we need to look at moving additional tools or daemons into /bin or
/sbin to help with these cases, that's worth looking at, too.
Especially for things like wireless devices.


> However, long-term it seems likely that the problems will continue to grow,
> as more and more upstream packages move away from supporting a /usr that
> isn't available at boot.


Packages that do this need to have bugs filed against them and patches
need to be sent back upstream.


> Well, the kernel comes with code for making an initramfs, but most likely it
> would be implemented in a separate package.  The initramfs isn't part of the
> kernel - it is loaded by grub at boot time and its address is passed to the
> kernel.  So, the file needs to be on /boot.


Yes, very much aware about initramfs and all the fun it involves.  I've
always noticed a majority of distros, to keep their boot kernels small,
package non-critical modules in an initramfs that is stored in /boot.
Thing is, that has always been optional, too.  It should be entirely
possible for me to build and boot a modular or monolithic kernel that
needs nothing else to reach a usable userland shell.

The fun bit about Linux/UNIX, is there are way more than 9 ways to skin
a cat here.  So we need to make sure that all other options to solving
issues that arise when /usr is separate are looked at and all solutions
considered before rubber stamping something as fundamental a change as
no longer supporting separate /usr, forcing initramfs images, or crazier
things.


> I think that pxelinux supports initramfs - I know it supports initrd at
> least and I don't think it makes any difference at the bootloader level.  In
> fact, things like network booting are one of the drivers behind the Fedora
> project to have dracut mount /usr.  Their plan is to just move everything
> into /usr, allow it to be NFS-mounted, and then with one mountpoint
> everything the system needs is available.  Eventually in Fedora /lib and
> /bin will just be symlinks into /usr.  That will work fine as long as dracut
> mounts /usr.


Wrong arch :)  SGI systems had netboot capabilities from Day 1, 1994
(and probably earlier).  A LOT of non-x86 archs have had netboot support
of some kind as a native feature of the hardware.  X86/x64 stuff has
usually been the red-headed stepchild of the bunch by either excluding
it in the past, or requiring you to buy special PROM chips for your NIC.
 It's only been fairly recently (in terms of the last 6-8 years or so)
that PXE boot has become a standard feature of generic/consumer x86/x64
hardware.


> Well, it certainly could be done, but it doesn't seem to be the direction
> anybody else is going.  Instead the plan is to just create a very minimal
> initramfs that gets the job done.  Using it would just be a matter of
> installing the file and editing the boot line to load it.  Or, you can use
> something like dracut or genkernel and get a more robust one.


Whoever said we had to do what everyone else did?  We're Gentoo, not a
pack of lemmings.  If we have to, we should be able to create an
entirely new solution, never thought of before, that fixes the problem
for all parties involved, yet allows us to keep the bit in our security
guide about keeping /usr (and other partitions) separate.


PS, yell if using PGP/MIME messes this message up.  Thunderbird +
Enigmail apparently is very unfriendly to inlined PGP for some odd
reason.  The two fight over the bloody line-wrapping mechanics.

-- 
Joshua Kinard
Gentoo/MIPS
kumba@gentoo.org
4096R/D25D95E3 2011-03-28

"The past tempts us, the present confuses us, the future frightens us.
And our lives slip away, moment by moment, lost in that vast, terrible
in-between."

--Emperor Turhan, Centauri Republic


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 834 bytes --]

Re: [gentoo-dev] rfc: using /libexec

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 4975 bytes --]

On Thu, 08 Sep 2011 04:19:32 -0400
Joshua Kinard <kumba@gentoo.org> wrote:

> On 09/07/2011 20:35, Rich Freeman wrote:
> 
> > On Wed, Sep 7, 2011 at 5:31 PM, Joshua Kinard <kumba@gentoo.org>
> > wrote:
> > 
> >> Never once have I had any issues
> >> with separate / and /usr, and none of them use an initramfs.
> > 
> > 
> > Ditto here, but that doesn't mean that problems don't exist.  Right
> > now the problems are likely to be subtle, perhaps arising only with
> > certain combinations of hardware/etc.  Maybe if you had a bluetooth
> > keyboard or something it might not work, or maybe if /usr were
> > mounted on a bluetooth hard drive or something (do they even make
> > those?).
> 
> 
> We should document these oddball hardware cases when they arise, but I
> would wager that they are exceptions, not rules.  We shouldn't upend
> an established concept (splitting /usr off) for what may possibly be
> curious corner cases of hardware combos.  My general knowledge of
> Linux always indicated /usr was entirely optional, from the
> standpoint of reaching an operable console, I.e., single-user mode.
> Granted, you can't do much on a setup where /usr is on its own
> partition, yet inaccessible due to some issue, but if lack of /usr
> doesn't hinder recovery efforts (those needed to make the system
> capable of mounting /usr), then things are okay.
> 
> If we need to look at moving additional tools or daemons into /bin or
> /sbin to help with these cases, that's worth looking at, too.
> Especially for things like wireless devices.

I'd rather say we should do the work on real issues rather than
imaginate 'separate /usr' problem. Honestly, most of 'advantages' of
separate /usr are just hacks avoiding other problems.

For example, read-only /usr is just a hack to avoid moving runtime
writable files out of /etc.

> > However, long-term it seems likely that the problems will continue
> > to grow, as more and more upstream packages move away from
> > supporting a /usr that isn't available at boot.
> 
> 
> Packages that do this need to have bugs filed against them and patches
> need to be sent back upstream.

And what is the bug exactly? 'My software requires yours, and yours is
installed in /usr by me'?

> > Well, the kernel comes with code for making an initramfs, but most
> > likely it would be implemented in a separate package.  The
> > initramfs isn't part of the kernel - it is loaded by grub at boot
> > time and its address is passed to the kernel.  So, the file needs
> > to be on /boot.
> 
> 
> Yes, very much aware about initramfs and all the fun it involves.
> I've always noticed a majority of distros, to keep their boot kernels
> small, package non-critical modules in an initramfs that is stored
> in /boot. Thing is, that has always been optional, too.  It should be
> entirely possible for me to build and boot a modular or monolithic
> kernel that needs nothing else to reach a usable userland shell.

And it will be. The point is that is either you want to have
separate /usr, or tiny system.

> The fun bit about Linux/UNIX, is there are way more than 9 ways to
> skin a cat here.  So we need to make sure that all other options to
> solving issues that arise when /usr is separate are looked at and all
> solutions considered before rubber stamping something as fundamental
> a change as no longer supporting separate /usr, forcing initramfs
> images, or crazier things.

Remember Windows 9x? They didn't want to rubber stamp something as
fundamental as DOS.

> > Well, it certainly could be done, but it doesn't seem to be the
> > direction anybody else is going.  Instead the plan is to just
> > create a very minimal initramfs that gets the job done.  Using it
> > would just be a matter of installing the file and editing the boot
> > line to load it.  Or, you can use something like dracut or
> > genkernel and get a more robust one.
> 
> 
> Whoever said we had to do what everyone else did?  We're Gentoo, not a
> pack of lemmings.  If we have to, we should be able to create an
> entirely new solution, never thought of before, that fixes the problem
> for all parties involved, yet allows us to keep the bit in our
> security guide about keeping /usr (and other partitions) separate.

Yeah, we are not a pack of lemmings. And we should be able to decide
when reinventing the wheel is actually necessary, and when it's just a
waste of time.

As mentioned before, keeping /usr separate provides no real security.
It's just pretending things are better, and I see no reason to lie to
users like that.

> PS, yell if using PGP/MIME messes this message up.  Thunderbird +
> Enigmail apparently is very unfriendly to inlined PGP for some odd
> reason.  The two fight over the bloody line-wrapping mechanics.

Nope, it doesn't. PGP/MIME is much better than that ugly inlined stuff.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] rfc: using /libexec

[Eray Aslan]

[-- Attachment #1: Type: text/plain, Size: 1209 bytes --]

On 2011-09-08 11:19 AM, Joshua Kinard wrote:
> Whoever said we had to do what everyone else did?  We're Gentoo, not a
> pack of lemmings.  If we have to, we should be able to create an
> entirely new solution, never thought of before, that fixes the problem
> for all parties involved, yet allows us to keep the bit in our security
> guide about keeping /usr (and other partitions) separate.

I also certainly do not like this systemd crusade and having initramfs
and friends forced down our throats.  Solving it properly would give
Gentoo an advantage over other distros and I feel that this is the road
we should take.  Problem is this is more or less a doacracy.  We are
governed by the doers.  Choices come down to:

* Voice your concern and then hush up if noone takes it up
* Spend some non-trivial brain and cpu cycles, not to mention time, to
get to a proper solution
* Search for alternative, possibly non-Linux, solutions

> PS, yell if using PGP/MIME messes this message up.  Thunderbird +
> Enigmail apparently is very unfriendly to inlined PGP for some odd
> reason.  The two fight over the bloody line-wrapping mechanics.

Looks good.
-- 
Eray Aslan <eras@gentoo.org>


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 898 bytes --]

Re: [gentoo-dev] rfc: using /libexec

[Rich Freeman]

[-- Attachment #1: Type: text/plain, Size: 2209 bytes --]

On Thu, Sep 8, 2011 at 4:41 AM, Michał Górny <mgorny@gentoo.org> wrote:

>
> I'd rather say we should do the work on real issues rather than
> imaginate 'separate /usr' problem. Honestly, most of 'advantages' of
> separate /usr are just hacks avoiding other problems.
>
>
I guess the irony in my case was that having a separate /usr allowed me to
use raid5 without having an initramfs.  :)

It may have changed, but at least in the past you couldn't have root on a
raid5 without an initramfs - you definitely couldn't have it on LVM.  So, if
you wanted to run LVM on raid5, you had to have a separate root that was
raid1 with the older metadata that on-disk looks like a non-raid partition
superficially.

So, unless you want to waste half your diskspace you need to keep root
really small, since raid1 is a lot less space-efficient than raid5.  If you
want a small root you can't put /usr on it.

In any case, I think we need to pick our battles.  If every other distro
goes one way, then we need to consider whether being different is really
adding value, or if it is simply being different.

Most distros used an initramfs because they wanted to have one-size-fits-all
kernels.  Gentoo doesn't do it that way, and hasn't needed initramfs as much
as a result.  However, in the linux world initramfs has evolved from simply
being a way to modprobe the drivers needed to mount root to an extra
bootloader that allows for more complex partitioning schemes (btrfs, lvm,
raid, etc), disk encryption, and much smarter detection logic (mounting by
UUID and not by a device name that is not guaranteed to be stable).

I think the proposed direction is sensible.  If you have a monolithic kernel
and a separate /usr on an otherwise simple setup, then you'll probably just
need to emerge an extra package and cat some static file onto the end of
your kernel image, or reference it in your kernel config.  If you have a
complex system then you just run dracut and get automagic bootup logic.  If
you have /usr on root then you don't need to do anything.

The alternative is to spend huge amounts of time maintaining system packages
just so that we can be different.

Rich

[-- Attachment #2: Type: text/html, Size: 2692 bytes --]

Re: [gentoo-dev] rfc: using /libexec

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 709 bytes --]

On Thu, 08 Sep 2011 13:52:55 +0300
Eray Aslan <eras@gentoo.org> wrote:

> On 2011-09-08 11:19 AM, Joshua Kinard wrote:
> > Whoever said we had to do what everyone else did?  We're Gentoo,
> > not a pack of lemmings.  If we have to, we should be able to create
> > an entirely new solution, never thought of before, that fixes the
> > problem for all parties involved, yet allows us to keep the bit in
> > our security guide about keeping /usr (and other partitions)
> > separate.
> 
> I also certainly do not like this systemd crusade and having initramfs
> and friends forced down our throats.

Could you stick to facts rather than pointless accusations?

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] rfc: using /libexec

[Eray Aslan]

[-- Attachment #1: Type: text/plain, Size: 699 bytes --]

On 2011-09-08 6:58 PM, Michał Górny wrote:
> Could you stick to facts rather than pointless accusations?

It is not an accusation and it is not pointless.  For the last time:

Seperate /usr without initramfs used to work.  Now it doesn't.  What you
are proposing is going to make it well neigh impossible to correct later
on.  We could have done a proper fix instead of going with the flow.
But I am not the one doing the coding (or employ the one who does).  So,
it is not my call.  So, I am shutting up.

Please do not rehash the same arguments in every email.  Having an
opinion is fine but being opiniated is not.  And it is getting tiresome.
-- 
Eray Aslan <eras@gentoo.org>


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 898 bytes --]

Re: [gentoo-dev] rfc: using /libexec

[Joshua Kinard]

[-- Attachment #1: Type: text/plain, Size: 2828 bytes --]

On 09/08/2011 10:35, Rich Freeman wrote:

> It may have changed, but at least in the past you couldn't have root on a
> raid5 without an initramfs - you definitely couldn't have it on LVM.  So, if
> you wanted to run LVM on raid5, you had to have a separate root that was
> raid1 with the older metadata that on-disk looks like a non-raid partition
> superficially.


I think that changed a LONG time ago when mdadm was moved to /sbin.
Also, if you set your partition types to "Linux raid auto" (0xfd), the
kernel would auto-detect all raid drives and assemble them properly.  I
run my SGI systems with /usr as both a separate partition and split
across multiple drives, and they have always found and mounted all
partitions correctly.


> In any case, I think we need to pick our battles.  If every other distro
> goes one way, then we need to consider whether being different is really
> adding value, or if it is simply being different.


Sure, we just need to watch out for cliffs.  And make sure we don't
inadvertently lead anyone else off of one, either.


> Most distros used an initramfs because they wanted to have one-size-fits-all
> kernels.  Gentoo doesn't do it that way, and hasn't needed initramfs as much
> as a result.  However, in the linux world initramfs has evolved from simply
> being a way to modprobe the drivers needed to mount root to an extra
> bootloader that allows for more complex partitioning schemes (btrfs, lvm,
> raid, etc), disk encryption, and much smarter detection logic (mounting by
> UUID and not by a device name that is not guaranteed to be stable).


Windows has long done drive mounts by the drive serial # (or some number
is derives from them).  And sticks it into that abomination called the
registry.  I did a drive migration once in Windows, and it was far from
fun until I found the registry keys holding those serials and nuked them
so the thing would re-locate the drives and mount them.

I'm not against using initramfs this way, but I just want to raise
attention to the possibility that there might be other options out
there.  I would imagine that for simple setups, where encryption,
llvm/btrfs/etc, and other things beyond simple mdadm raid are not
needed, that we align our scripts to still make a separate /usr
possible.  Surely we can detect that with an initscript somewhere.


> The alternative is to spend huge amounts of time maintaining system packages
> just so that we can be different.


Isn't this what we do already? :)


-- 
Joshua Kinard
Gentoo/MIPS
kumba@gentoo.org
4096R/D25D95E3 2011-03-28

"The past tempts us, the present confuses us, the future frightens us.
And our lives slip away, moment by moment, lost in that vast, terrible
in-between."

--Emperor Turhan, Centauri Republic


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 834 bytes --]

Re: [gentoo-dev] rfc: using /libexec

[Joshua Kinard]

[-- Attachment #1: Type: text/plain, Size: 1025 bytes --]

On 09/08/2011 16:02, Eray Aslan wrote:

> Seperate /usr without initramfs used to work.  Now it doesn't.  What you
> are proposing is going to make it well neigh impossible to correct later
> on.  We could have done a proper fix instead of going with the flow.
> But I am not the one doing the coding (or employ the one who does).  So,
> it is not my call.  So, I am shutting up.


Under what setup does it not work now?  I would very much like to know
if some recent OpenRC thing just hosed something.  I'm dealing with
torrential rain here, thunderstorms, and I cannot predict when my next
power outage will be.  Last thing I need on my plate is a Linux box not
coming back online because separate /usr was suddenly deprecated.

-- 
Joshua Kinard
Gentoo/MIPS
kumba@gentoo.org
4096R/D25D95E3 2011-03-28

"The past tempts us, the present confuses us, the future frightens us.
And our lives slip away, moment by moment, lost in that vast, terrible
in-between."

--Emperor Turhan, Centauri Republic


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 834 bytes --]

Re: [gentoo-dev] rfc: using /libexec

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 542 bytes --]

On Wednesday, September 07, 2011 05:27:05 Michał Górny wrote:
> On Wed, 07 Sep 2011 12:17:21 +0300 Alexey Shvetsov wrote:
> > Moving things as openrc to /usr/libexec will effectevely barake old
> > systems with separtae / and /usr. So it isnt good idea
> 
> Old systems should migrate to initramfs, like it was already pointed
> out before. Breakage is already there, you just don't notice it.

brain dead behavior in other packages has no bearing on openrc.  openrc will 
never require crap like initramfs simply to boot.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] rfc: using /libexec

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1025 bytes --]

On Thursday, September 08, 2011 18:15:21 Joshua Kinard wrote:
> On 09/08/2011 16:02, Eray Aslan wrote:
> > Seperate /usr without initramfs used to work.  Now it doesn't.  What you
> > are proposing is going to make it well neigh impossible to correct later
> > on.  We could have done a proper fix instead of going with the flow.
> > But I am not the one doing the coding (or employ the one who does).  So,
> > it is not my call.  So, I am shutting up.
> 
> Under what setup does it not work now?  I would very much like to know
> if some recent OpenRC thing just hosed something.  I'm dealing with
> torrential rain here, thunderstorms, and I cannot predict when my next
> power outage will be.  Last thing I need on my plate is a Linux box not
> coming back online because separate /usr was suddenly deprecated.

it has nothing to do with openrc.  if there is something in openrc that doesnt 
work with a split /usr or /var, then file a bug because it is a bug.  i dont 
know of anything right now.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] rfc: using /libexec

[Eray Aslan]

[-- Attachment #1: Type: text/plain, Size: 986 bytes --]

On 2011-09-09 1:15 AM, Joshua Kinard wrote:
> Under what setup does it not work now?  I would very much like to know
> if some recent OpenRC thing just hosed something.  I'm dealing with
> torrential rain here, thunderstorms, and I cannot predict when my next
> power outage will be.  Last thing I need on my plate is a Linux box not
> coming back online because separate /usr was suddenly deprecated.

Sorry, I should have qualified it as "it doesn't work reliably for all
use cases now".  Nothing to do with OpenRC.  Mostly, it is udev or
rather the binaries that its rules want to run that are in /usr or
linked against libraries in /usr before /usr is mounted.  Check the
archives.  There was a discussion I believe.

As a side note, most of this discussion seems to result from different
paradigms of end users (and companies that cater to them) vs server
admins.  Priorities and what is important hence their solutions differ.
-- 
Eray Aslan <eras@gentoo.org>


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 898 bytes --]