[gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?

[gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?

[Samuli Suominen]

Since running separate /usr without mounting it from initramfs on top of
/ before init is and has been broken with udev for a long time now[1][2][3]

[1] http://bugs.gentoo.org/show_bug.cgi?id=364235
[2] http://fedoraproject.org/wiki/Features/UsrMove#Move_all_to_.2Fusr
[3] http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken

Can we warn users about not doing the separate /usr mistake in the handbook?

Re: [gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?

[Rich Freeman]

On Sat, Jul 30, 2011 at 3:27 AM, Samuli Suominen <ssuominen@gentoo.org> wrote:
> Since running separate /usr without mounting it from initramfs on top of
> / before init is and has been broken with udev for a long time now[1][2][3]
>
> [1] http://bugs.gentoo.org/show_bug.cgi?id=364235
> [2] http://fedoraproject.org/wiki/Features/UsrMove#Move_all_to_.2Fusr
> [3] http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken
>
> Can we warn users about not doing the separate /usr mistake in the handbook?

My feeling is that we should still consider this a supported
configuration, so any warning should be along the lines of "note that
we're still having issues making this work properly so be careful for
now."  Or, better still explain how to configure the initramfs to
mount /usr.

I actually run this configuration without an initramfs and haven't had
issues so far.  If you want to run with a small root partition I don't
see much alternative.

Does the genkernel initramfs mount /usr currently?

Rich

Re: [gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?

[Rich Freeman]

On Sat, Jul 30, 2011 at 3:27 AM, Samuli Suominen <ssuominen@gentoo.org> wrote:
> Since running separate /usr without mounting it from initramfs on top of
> / before init is and has been broken with udev for a long time now[1][2][3]
>
> [1] http://bugs.gentoo.org/show_bug.cgi?id=364235
> [2] http://fedoraproject.org/wiki/Features/UsrMove#Move_all_to_.2Fusr
> [3] http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken
>
> Can we warn users about not doing the separate /usr mistake in the handbook?

My feeling is that we should still consider this a supported
configuration, so any warning should be along the lines of "note that
we're still having issues making this work properly so be careful for
now."  Or, better still explain how to configure the initramfs to
mount /usr.

I actually run this configuration without an initramfs and haven't had
issues so far.  If you want to run with a small root partition I don't
see much alternative.

Does the genkernel initramfs mount /usr currently?

Rich

Re: [gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?

[Ciaran McCreesh]

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

On Sat, 30 Jul 2011 10:27:27 +0300
Samuli Suominen <ssuominen@gentoo.org> wrote:
> Since running separate /usr without mounting it from initramfs on top
> of / before init is and has been broken with udev for a long time
> now[1][2][3]
> 
> [1] http://bugs.gentoo.org/show_bug.cgi?id=364235
> [2] http://fedoraproject.org/wiki/Features/UsrMove#Move_all_to_.2Fusr
> [3]
> http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken
> 
> Can we warn users about not doing the separate /usr mistake in the
> handbook?

It's important to consider the timeline here. Separate /usr was
accidentally broken by a sudden increase in dependencies from base
system packages to desktopy things. It was only later that certain
people decided that "oh, separate /usr is a bad idea anyway", and they
did so because they couldn't figure out how to fix the mess they'd
caused. This is very much a case of carelessly letting the horse escape
and then trying to convince everyone that no-one needs a horse anyway...

-- 
Ciaran McCreesh

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

[gentoo-dev] Re: Warn users not to do separate /usr partition without proper initramfs in the handbook?

[Duncan]

Ciaran McCreesh posted on Sat, 30 Jul 2011 11:46:00 +0100 as excerpted:

> It's important to consider the timeline here. Separate /usr was
> accidentally broken by a sudden increase in dependencies from base
> system packages to desktopy things. It was only later that certain
> people decided that "oh, separate /usr is a bad idea anyway", and they
> did so because they couldn't figure out how to fix the mess they'd
> caused. This is very much a case of carelessly letting the horse escape
> and then trying to convince everyone that no-one needs a horse anyway...

++

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

Re: [gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?

[Samuli Suominen]

On 07/30/2011 01:46 PM, Ciaran McCreesh wrote:
> On Sat, 30 Jul 2011 10:27:27 +0300
> Samuli Suominen <ssuominen@gentoo.org> wrote:
>> Since running separate /usr without mounting it from initramfs on top
>> of / before init is and has been broken with udev for a long time
>> now[1][2][3]
>>
>> [1] http://bugs.gentoo.org/show_bug.cgi?id=364235
>> [2] http://fedoraproject.org/wiki/Features/UsrMove#Move_all_to_.2Fusr
>> [3]
>> http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken
>>
>> Can we warn users about not doing the separate /usr mistake in the
>> handbook?
> 
> It's important to consider the timeline here. Separate /usr was
> accidentally broken by a sudden increase in dependencies from base
> system packages to desktopy things. It was only later that certain
> people decided that "oh, separate /usr is a bad idea anyway", and they
> did so because they couldn't figure out how to fix the mess they'd
> caused. This is very much a case of carelessly letting the horse escape
> and then trying to convince everyone that no-one needs a horse anyway...
> 

Someone mentioned NFS mount on /usr.  Do we have other reasons?  How
many users that might be?

I dislike the documentation not being clear on separate /usr, that it
should only be used if you *really* need it due to the potential problems

I dislike the IUSE="+static" some packages are currently doing to
workaround this, instead of moving the needed shared libs to /

I dislike the idea of pciutils and usbutils database(s) in non-standard
location in / to keep udev working

I dislike the idea of moving libglib-2.0, libdbus-1, libdbus-glib-1, and
couple of dozen more libs to /

I dislike the idea of maintaining and keeping track of the files in /
using files from /usr. Does any of the PMs have check for this, like
NEEDED entries? I can imagine this getting past the maintainers easily
otherwise

Most likely still not seeing the full picture here, and just scratching
the surface...
Despite that, I don't have any strong opinion on any of this, just need
to know if I should start moving the files over

Re: [gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?

[Chí-Thanh Christopher Nguyễn]

Samuli Suominen schrieb:
> 
> Someone mentioned NFS mount on /usr.  Do we have other reasons?  How
> many users that might be?

If you have / encrypted, then you can leave /usr unencrypted as it
contains no secrets. Also /usr can remain mounted read-only most of the
time, so there is a reduced chance of accidental corruption.
I don't know the number of users who might want this, and I imagine it
is difficult to count them.

> I dislike the idea of moving libglib-2.0, libdbus-1, libdbus-glib-1, and
> couple of dozen more libs to /

If you say that /usr must be on the same filesystem as /, then there is
no real reason to not just make a symlink /usr -> .


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?

[Rich Freeman]

On Sat, Jul 30, 2011 at 9:55 AM, Samuli Suominen <ssuominen@gentoo.org> wrote:
> Someone mentioned NFS mount on /usr.  Do we have other reasons?  How
> many users that might be?
>
> I dislike the documentation not being clear on separate /usr, that it
> should only be used if you *really* need it due to the potential problems

Well, I ended up that way from following the official documentation
the better part of a decade ago:
http://www.gentoo.org/doc/en/gentoo-x86+raid+lvm2-quickinstall.xml

Sure, I guess I could try to move root to the lvm as well to expand it
enough and switch over to genkernel.

You know, maybe a way around all of this would be for all of the
various distros and major FOSS packages to get together and come up
with some kind of standard for what goes in what directory.  Maybe we
could call it something like the "Filesystem Hierarchy Standard."
Then we don't have to argue on mailing lists about whether it is
appropriate to rely on file in /usr during boot.

It seems like the proper solution is for all packages in the tree to
be FHS-compliant, either because we patched them and bug upstream
about it, or because we exclude them.  That said, there is little
point if we're the only distro doing this.

How many packages are we actually talking about?  Is there any kind of
consensus in the FOSS community beyond Gentoo that FHS has had its
day?  What is the policy for other distros?

Rich

Re: [gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?

[Samuli Suominen]

On 07/30/2011 05:28 PM, Chí-Thanh Christopher Nguyễn wrote:
> Samuli Suominen schrieb:
>>
>> Someone mentioned NFS mount on /usr.  Do we have other reasons?  How
>> many users that might be?
> 
> If you have / encrypted, then you can leave /usr unencrypted as it
> contains no secrets. Also /usr can remain mounted read-only most of the
> time, so there is a reduced chance of accidental corruption.
> I don't know the number of users who might want this, and I imagine it
> is difficult to count them.

That is still possible, since separate /usr would still be an option if
it's mounted from the initramfs before init.

Quote from #gentoo-dev today:

11:39 <@aidecoe> dracut has module fstab-sys. You might check this out
to mount additional stuff before switching to root.

Re: [gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?

[Rich Freeman]

On Sat, Jul 30, 2011 at 10:59 AM, Samuli Suominen <ssuominen@gentoo.org> wrote:
> 11:39 <@aidecoe> dracut has module fstab-sys. You might check this out
> to mount additional stuff before switching to root.

If we want to make /usr required on boot we should build this
capability into genkernel.  Or, we should have genkernel invoke
dracut, or just make dracut the official initramfs tool and document
it accordingly.  Or, at the very least we should update our lvm+raid
howto to actually work in a supported fashion - probably some of the
things above in the process.

I'm not completely opposed to just ditching the FHS if its day has
passed, but this isn't something we should consider lightly and we
should at least document the proper way to configure a Gentoo system
that has almost all of its data on lvm+raid.

Rich

Re: [gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?

[Amadeusz Żołnowski]

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

Excerpts from Rich Freeman's message of 2011-07-30 17:10:14 +0200:
> On Sat, Jul 30, 2011 at 10:59 AM, Samuli Suominen
> <ssuominen@gentoo.org> wrote:
> > 11:39 <@aidecoe> dracut has module fstab-sys. You might check this
> > out to mount additional stuff before switching to root.
> 
> If we want to make /usr required on boot we should build this
> capability into genkernel.  Or, we should have genkernel invoke
> dracut,

It's on my responsibilities list and a progress has been made.  I'm
currently overloaded since few months, but it is eventually going to be.
(It's not so simple as just invoking dracut.  Integration is a bit more
complicated.)


> or just make dracut the official initramfs tool and document
> it accordingly.

It will take some time to finally integrate dracut into genkernel, but
making dracut more official tool until this time is possible to
accomplish in the nearest future.  Although first we need to introduce
/run into stable baselayout.  If you all decide on the matter and the
way through dracut is chosen, just let me know and I'll try stabilize
and write docs about dracut as soon as possible.


Despite it's easily possible to workaround the problem with initramfs,
it's really bad issue that the world is breaking FHS instead of
designing something new.  (Yes, I know it's so big deal that's
impossible… but… doh…)


-- 
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] Warn users not to do separate /usr partition without proper initramfs in the handbook?

[David Leverton]

On Saturday 30 July 2011 14:55:23 Samuli Suominen wrote:
> Someone mentioned NFS mount on /usr.  Do we have other reasons?  How
> many users that might be?

From /etc/conf.d/fsck, seems like a reason to keep the / FS as small as 
possible to reduce the amount of time spent waiting during boot:

# fsck_shutdown causes fsck to trigger during shutdown as well as startup.
# The end result of this is that if any periodic non-root filesystem checks are
# scheduled, under normal circumstances the actual check will happen during
# shutdown rather than at next boot.
# This is useful when periodic filesystem checks are causing undesirable
# delays at startup, but such delays at shutdown are acceptable.
fsck_shutdown="YES"

Re: [gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?

[Rich Freeman]

On Sat, Jul 30, 2011 at 1:20 PM, David Leverton
<levertond@googlemail.com> wrote:
> On Saturday 30 July 2011 14:55:23 Samuli Suominen wrote:
>> Someone mentioned NFS mount on /usr.  Do we have other reasons?  How
>> many users that might be?
>
> From /etc/conf.d/fsck, seems like a reason to keep the / FS as small as
> possible to reduce the amount of time spent waiting during boot:

Well, that only really has a benefit if the system can do something
useful between the time that root is mounted and /usr is mounted,
which is probably a "no."

In any case, I see this whole situation as being a bit of laziness -
individual packages are just breaking the rules rather than trying to
reform them.  However, if this is the way of the universe I'd be fine
with just updating our docs and tools to handle /usr mounted by
initramfs.  Almost all other distros use initramfs 100% of the time -
Gentoo is a bit unusual in that I'd say a good chunk of our users
don't use one at all.

Rich

Re: [gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?

[Ciaran McCreesh]

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

On Sat, 30 Jul 2011 13:38:55 -0400
Rich Freeman <rich0@gentoo.org> wrote:
> > From /etc/conf.d/fsck, seems like a reason to keep the / FS as
> > small as possible to reduce the amount of time spent waiting during
> > boot:
> 
> Well, that only really has a benefit if the system can do something
> useful between the time that root is mounted and /usr is mounted,
> which is probably a "no."

Bring up networking?

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?

[David Leverton]

On Saturday 30 July 2011 18:38:55 Rich Freeman wrote:
> On Sat, Jul 30, 2011 at 1:20 PM, David Leverton
> > From /etc/conf.d/fsck, seems like a reason to keep the / FS as small as
> > possible to reduce the amount of time spent waiting during boot:
> Well, that only really has a benefit if the system can do something
> useful between the time that root is mounted and /usr is mounted,
> which is probably a "no."

Not quite sure what you mean there... I meant that OpenRC lets you move non-/ 
fscks to shutdown, but you still have to wait for / to be checked during boot 
whenever it's due, so it's good to have it small so you don't have to wait too 
long.

Re: [gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?

[Michał Górny]

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

On Sat, 30 Jul 2011 16:28:54 +0200
Chí-Thanh Christopher Nguyễn <chithanh@gentoo.org> wrote:

> Samuli Suominen schrieb:
> > 
> > Someone mentioned NFS mount on /usr.  Do we have other reasons?  How
> > many users that might be?
> 
> If you have / encrypted, then you can leave /usr unencrypted as it
> contains no secrets.

That's doing things upside-down. You should encrypt the data needing
encryption, not the other way. This usually means /home which is
separate more often than /usr.

> Also /usr can remain mounted read-only most of the time, so there is
> a reduced chance of accidental corruption. I don't know the number of
> users who might want this, and I imagine it is difficult to count
> them.

Is this actually possible now? Last time I tried doing things like this
X11 failed to set keyboard mappings trying to store compiled ones
in /usr.

> > I dislike the idea of moving libglib-2.0, libdbus-1,
> > libdbus-glib-1, and couple of dozen more libs to /
> 
> If you say that /usr must be on the same filesystem as /, then there
> is no real reason to not just make a symlink /usr -> .

That's a joke, right?

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?

[DarKRaveR]

Certainly a good point - you don't want to spoil a SSD-RAID-set's
performance by encrypting /usr but there is surely a strong need to
encrypt /etc and thus /, which has a rather neglectable impact on
performance of a system.
I'd even say that in a lot of environments splitting / and /usr is more
common and useful than putting them on the same FS.
Just accepting the need to have / and /usr on the same FS because packages
are severly broken and badly designed should not really an argument to
consider.

Kind Regards

-Sven

P.S.: In this respect I second Ciaran's POV and what he said.

On Sat, July 30, 2011 16:28, Chí-Thanh Christopher Nguyễn wrote:
> Samuli Suominen schrieb:
>>
>> Someone mentioned NFS mount on /usr.  Do we have other reasons?  How
>> many users that might be?
>
> If you have / encrypted, then you can leave /usr unencrypted as it
> contains no secrets. Also /usr can remain mounted read-only most of the
> time, so there is a reduced chance of accidental corruption.
> I don't know the number of users who might want this, and I imagine it
> is difficult to count them.
>
>
> Best regards,
> Chí-Thanh Christopher Nguyễn
>
>

Re: [gentoo-dev] Re: Warn users not to do separate /usr partition without proper initramfs in the handbook?

[William Hubbs]

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

On Sat, Jul 30, 2011 at 11:57:14AM +0000, Duncan wrote:
> Ciaran McCreesh posted on Sat, 30 Jul 2011 11:46:00 +0100 as excerpted:
> 
> > It's important to consider the timeline here. Separate /usr was
> > accidentally broken by a sudden increase in dependencies from base
> > system packages to desktopy things. It was only later that certain
> > people decided that "oh, separate /usr is a bad idea anyway", and they
> > did so because they couldn't figure out how to fix the mess they'd
> > caused. This is very much a case of carelessly letting the horse escape
> > and then trying to convince everyone that no-one needs a horse anyway...
> 
> ++

I tend to agree with this due to the reasons posted in this thread. I
think we should be very cautious about making a change that requires an
initrd just for separate /usr.

I'm a co maintainer of udev, so let me see if I can come up with
something when the next udev is released. I want to try to work out a way
to do this in udev-postmount.

William


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

Re: [gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?

[Chí-Thanh Christopher Nguyễn]

Michał Górny schrieb:
>> If you have / encrypted, then you can leave /usr unencrypted as it
>> contains no secrets.
> 
> That's doing things upside-down. You should encrypt the data needing
> encryption, not the other way. This usually means /home which is
> separate more often than /usr.

That is precisely what is done here. On a typical system I assume that
secrets can be in /etc, /home and /var. Encrypting /usr might not give
you a security gain and just consume resources.

>> Also /usr can remain mounted read-only most of the time, so there is
>> a reduced chance of accidental corruption. I don't know the number of
>> users who might want this, and I imagine it is difficult to count
>> them.
> 
> Is this actually possible now? Last time I tried doing things like this
> X11 failed to set keyboard mappings trying to store compiled ones
> in /usr.

I have not seen any machine running X have read-only /usr yet. Maybe it
is something that could be investigated. If I have time, I'll experiment
what happens when I do a read-only bind-mount of /usr on itself.

>> If you say that /usr must be on the same filesystem as /, then there
>> is no real reason to not just make a symlink /usr -> .
> 
> That's a joke, right?

There are folks who seriously take this into consideration. I don't
necessarily agree with them, though.


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?

[William Hubbs]

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

On Sat, Jul 30, 2011 at 10:27:27AM +0300, Samuli Suominen wrote:
> Since running separate /usr without mounting it from initramfs on top of
> / before init is and has been broken with udev for a long time now[1][2][3]
> 
> [1] http://bugs.gentoo.org/show_bug.cgi?id=364235
> [2] http://fedoraproject.org/wiki/Features/UsrMove#Move_all_to_.2Fusr
> [3] http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken
> 
> Can we warn users about not doing the separate /usr mistake in the handbook?

There are actually two options for us according to upstream. One is the
one you are talking about -- mounting /usr from an initramfs before / is
mounted. The other is to mount local file systems, if setups are simple
enough, before we start udev. I could set this one up easily enough just
by moving localmount to the boot runlevel.

Can we discuss both options?

William


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

[gentoo-dev] Re: Warn users not to do separate /usr partition without proper initramfs in the handbook?

[Duncan]

Rich Freeman posted on Sat, 30 Jul 2011 10:28:56 -0400 as excerpted:

> Is there any kind of
> consensus in the FOSS community beyond Gentoo that FHS has had its
> day?  What is the policy for other distros?

From what I see on the general blogs, yes, /current/ FHS has had its 
day.  HOWEVER, one thing the systemd hubbub /has/ been effective in doing 
is getting discussion on the topic going again, and there's a new version 
in the works (with /run suggested, and presumably updated to include 
/sys, etc), instead of simply ignoring the problem and working around it 
with distro-specific solutions or non-solutions as the case may be, which 
was the situation for rather too long.

What I do /not/ know is the status of the update, or an ETA on a final 
version.  But if there's no one already, it'd be useful to have at least 
one gentoo rep in on the discussions, for sure.  Otherwise, the new FHS 
could well be defined by binary distros and assume systemd, either in FHS 
itself or in the LSB layer above, just as the LSB standardized on rpm.

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

Re: [gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?

[Jorge Manuel B. S. Vicetto]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 30-07-2011 22:17, William Hubbs wrote:
> On Sat, Jul 30, 2011 at 10:27:27AM +0300, Samuli Suominen wrote:
>> Since running separate /usr without mounting it from initramfs on
>> top of / before init is and has been broken with udev for a long
>> time now[1][2][3]
>> 
>> [1] http://bugs.gentoo.org/show_bug.cgi?id=364235 [2]
>> http://fedoraproject.org/wiki/Features/UsrMove#Move_all_to_.2Fusr 
>> [3]
>> http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken
>>
>>
>> 
Can we warn users about not doing the separate /usr mistake in the handbook?
> 
> There are actually two options for us according to upstream. One is
> the one you are talking about -- mounting /usr from an initramfs
> before / is mounted. The other is to mount local file systems, if
> setups are simple enough, before we start udev. I could set this one
> up easily enough just by moving localmount to the boot runlevel.
> 
> Can we discuss both options?

If there's any option that allows the use of a separate /usr partition
without an initramfs, then let's explore it. I don't feel like having to
use an initramfs just because I want a small / without /usr on it.
As others have said, having /usr as a separate partition worked for
years until some people started trying to "shove" bloat on everyone's
systems and then they want us to believe that having /usr as a separate
partition is stupid.

> William

- -- 
Regards,

Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJONKjzAAoJEC8ZTXQF1qEPLjEP/i8oGv6aP3RH1SokVG5llfuq
j0pckRZOTcqcHl4CM7ZfvYvixLR8XZK1ZSRk3DnysxUQCrI6fNvYr1/8EqJUIB9j
wM5XRshkyOwh8VpwdTdd/y0XhcE1MaAqwXOXOO2FrnuH6cd6RR0YFbeVVbL62kni
PdTV+DNY2Wbo1fn8xAY0lRANMqghNXPGBK4/5kYuwCBME1xaV/cRkbDrtUnznWbq
dsCshhm5m2ertOHuRZzDQfpUOlS0J5RiE8zvAqyasC1stT3TcegcnTL/M8zxOoF8
jxcPJCIsVx/WfKrDXT9qgSOo9/E2X182dLN/6br2prV/Yvjb0nMcC1orsueHDnVo
WHvYCEZ7ZlLIMw6boiWycqzRcxSrz24XQLufyWwcYUpWdxHmToNPW6dOQvM+ZcNz
QAOs3fAR7NinGHMRkl9AehCbK1PiKBBmiZU/KXcCffBabWsUuwWEwhxz0BNGvLgZ
62NgPM1HbF3+azq+mqre2tp2mu3s4cVUiu12Zf5SBXTJP98FCIX9Q+vpypoQGhjv
R1JtlozfOunPYnLaEBT0pz/Rev9HrdxIpslKcQug6N3u/1Z0+COUSEatr9xJDSOb
fXD6c+Cm4zFcJx1hiZ2+qyidhcX57uC+2Y6GIVGhHKOBwJSFna0DGsQw8iMbNk8Y
OQ2x6i+JYAqyUKZdJLP3
=bxvJ
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?

[Samuli Suominen]

On 07/31/2011 03:59 AM, Jorge Manuel B. S. Vicetto wrote:
> On 30-07-2011 22:17, William Hubbs wrote:
>> On Sat, Jul 30, 2011 at 10:27:27AM +0300, Samuli Suominen wrote:
>>> Since running separate /usr without mounting it from initramfs on
>>> top of / before init is and has been broken with udev for a long
>>> time now[1][2][3]
>>>
>>> [1] http://bugs.gentoo.org/show_bug.cgi?id=364235 [2]
>>> http://fedoraproject.org/wiki/Features/UsrMove#Move_all_to_.2Fusr 
>>> [3]
>>> http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken
>>>
>>>
>>>
> Can we warn users about not doing the separate /usr mistake in the handbook?
> 
>> There are actually two options for us according to upstream. One is
>> the one you are talking about -- mounting /usr from an initramfs
>> before / is mounted. The other is to mount local file systems, if
>> setups are simple enough, before we start udev. I could set this one
>> up easily enough just by moving localmount to the boot runlevel.
> 
>> Can we discuss both options?
> If there's any option that allows the use of a separate /usr partition
> without an initramfs, then let's explore it. I don't feel like having to
> use an initramfs just because I want a small / without /usr on it.

The message is really missing all the context without explanation for
WHY you want it.

Re: [gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?

[William Hubbs]

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

On Sun, Jul 31, 2011 at 04:40:33AM +0300, Samuli Suominen wrote:
> On 07/31/2011 03:59 AM, Jorge Manuel B. S. Vicetto wrote:
> > On 30-07-2011 22:17, William Hubbs wrote:
> >> On Sat, Jul 30, 2011 at 10:27:27AM +0300, Samuli Suominen wrote:
> >>> Since running separate /usr without mounting it from initramfs on
> >>> top of / before init is and has been broken with udev for a long
> >>> time now[1][2][3]
> >>>
> >>> [1] http://bugs.gentoo.org/show_bug.cgi?id=364235 [2]
> >>> http://fedoraproject.org/wiki/Features/UsrMove#Move_all_to_.2Fusr 
> >>> [3]
> >>> http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken
> >>>
> >>>
> >>>
> > Can we warn users about not doing the separate /usr mistake in the handbook?
> > 
> >> There are actually two options for us according to upstream. One is
> >> the one you are talking about -- mounting /usr from an initramfs
> >> before / is mounted. The other is to mount local file systems, if
> >> setups are simple enough, before we start udev. I could set this one
> >> up easily enough just by moving localmount to the boot runlevel.
> > 
> >> Can we discuss both options?
> > If there's any option that allows the use of a separate /usr partition
> > without an initramfs, then let's explore it. I don't feel like having to
> > use an initramfs just because I want a small / without /usr on it.
> 
> The message is really missing all the context without explanation for
> WHY you want it.
 
 Here is a good argument for supporting this.

 http://tldp.org/LDP/lame/LAME/linux-admin-made-easy/install-partitioning.html

 You can hose your system easier with one big file system with / and
 /usr combined than you can with multiple partitions.

 William


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

Re: [gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?

[netfab]

Le 31/07/11 à 04:40, Samuli a tapoté :
> > If there's any option that allows the use of a separate /usr
> > partition without an initramfs, then let's explore it. I don't feel
> > like having to use an initramfs just because I want a small /
> > without /usr on it.
> 
> The message is really missing all the context without explanation for
> WHY you want it.
> 

System reactivity. I have an old setup with multiple partitions on
multiple hard-drives mounted on multiple system directories. When the
system is busy, it is responsiveness.

Re: [gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?

[Samuli Suominen]

On 07/31/2011 10:20 AM, netfab wrote:
> Le 31/07/11 à 04:40, Samuli a tapoté :
>>> If there's any option that allows the use of a separate /usr
>>> partition without an initramfs, then let's explore it. I don't feel
>>> like having to use an initramfs just because I want a small /
>>> without /usr on it.
>>
>> The message is really missing all the context without explanation for
>> WHY you want it.
>>
> 
> System reactivity. I have an old setup with multiple partitions on
> multiple hard-drives mounted on multiple system directories. 

And why is both using an initramfs or migrating /usr to / an problem?

> When the system is busy, it is responsiveness.

I can guess. Suboptimal ordering of disks per speed and usage?

Or what was your point?

Re: [gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?

[Christopher Head]

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

On Sun, 31 Jul 2011 04:40:33 +0300
Samuli Suominen <ssuominen@gentoo.org> wrote:

> >> Can we discuss both options?
> > If there's any option that allows the use of a separate /usr
> > partition without an initramfs, then let's explore it. I don't feel
> > like having to use an initramfs just because I want a small /
> > without /usr on it.
> 
> The message is really missing all the context without explanation for
> WHY you want it.

(As an interested non-developer)

My own rationale is as follows:

1. I do regular backups of /home. I would prefer to have them run in
the background while I continue using the system, so the filesystem
won't be idle. For consistency, that means I want /home in LVM, so I
can create a snapshot and back that up instead—it will be at least as
consistent as an instantaneous power failure would be, which things
tend to be pretty good at recovering from (both the filesystem and
anything above it that uses a journal of some sort, like sqlite).

2. /home is big. /usr is big. When I first install a system, it's not
clear exactly how big each one will be. It's really nice to be able to
share space between them without any manual intervention, which is what
happens if you put both on the same filesystem. Thus, if /home is in
LVM, then /usr must also be in LVM, on the same LV.

3. Booting with / on LVM requires an initramfs. It's much easier to not
use an initramfs than to use one. So I keep / outside LVM as a small
ordinary partition, typically ~250MB (no need for a separate /boot
partition in this case).

That said, I hadn't ever actually noticed that putting /usr on a
separate filesystem was broken in the first place. It's served me well
enough. I'd just like it if it would continue to do so. If I have no
choice I suppose I will have to switch to using an initramfs, but I
prefer not having to poke the early boot sequences of machines it's a
PITA to get physical access to that have been working fine for years.

Chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)

iEYEARECAAYFAk41E38ACgkQXUF6hOTGP7emFACfYeoq2vSxk8B1I+URk5ohGbvJ
soYAoJZ1p2cm4IjoEFvdfzkQNlxERCv1
=yZkv
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?

[netfab]

Le 31/07/11 à 11:15, Samuli a tapoté :
> > System reactivity. I have an old setup with multiple partitions on
> > multiple hard-drives mounted on multiple system directories. 
> 
> And why is both using an initramfs [...] an problem?
>

No problem for me. If I have to do it, I will. In fact I already use
an initramfs for uvesafb and v86d [1]. I was simply answer you on WHY I
want a separate /usr partition.

> And why is both [...] migrating /usr to / an problem?

This depend on your setup. Mine is basically like this :
 - /tmp and /var are still on the root partition.
 - everything else have their own partition, this includes :
   - official dirs : /usr /portage/trees /portage/distpack /home /opt
   -   custom dirs : /data and raid arrays.

For example, when running emerge -uDN world, /var is intensively used
during compilation. If /usr is on a separate partition on another hard
drive, launching multiple applications during the system update will
necessarily be faster than if /usr is on /.

> 
> > When the system is busy, it is responsiveness.
> 
> I can guess. Suboptimal ordering of disks per speed and usage?
> 

Yes.

[1] http://dev.gentoo.org/~spock/projects/uvesafb/

Re: [gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?

[Samuli Suominen]

On 07/31/2011 04:56 AM, William Hubbs wrote:
> On Sun, Jul 31, 2011 at 04:40:33AM +0300, Samuli Suominen wrote:
>> On 07/31/2011 03:59 AM, Jorge Manuel B. S. Vicetto wrote:
>>> On 30-07-2011 22:17, William Hubbs wrote:
>>>> On Sat, Jul 30, 2011 at 10:27:27AM +0300, Samuli Suominen wrote:
>>>>> Since running separate /usr without mounting it from initramfs on
>>>>> top of / before init is and has been broken with udev for a long
>>>>> time now[1][2][3]
>>>>>
>>>>> [1] http://bugs.gentoo.org/show_bug.cgi?id=364235 [2]
>>>>> http://fedoraproject.org/wiki/Features/UsrMove#Move_all_to_.2Fusr 
>>>>> [3]
>>>>> http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken
>>>>>
>>>>>
>>>>>
>>> Can we warn users about not doing the separate /usr mistake in the handbook?
>>>
>>>> There are actually two options for us according to upstream. One is
>>>> the one you are talking about -- mounting /usr from an initramfs
>>>> before / is mounted. The other is to mount local file systems, if
>>>> setups are simple enough, before we start udev. I could set this one
>>>> up easily enough just by moving localmount to the boot runlevel.
>>>
>>>> Can we discuss both options?
>>> If there's any option that allows the use of a separate /usr partition
>>> without an initramfs, then let's explore it. I don't feel like having to
>>> use an initramfs just because I want a small / without /usr on it.
>>
>> The message is really missing all the context without explanation for
>> WHY you want it.
>  
>  Here is a good argument for supporting this.
> 
>  http://tldp.org/LDP/lame/LAME/linux-admin-made-easy/install-partitioning.html

The documentation seems to lack any arguments, bad or good, for the
separate /usr issue. Any chance you could highlight it out?

>  You can hose your system easier with one big file system with / and
>  /usr combined than you can with multiple partitions.

Too vague. Did you mean to compare filesystem size with the amount of
errors and it's capability to recover? To what effect, and same for
every filesystem type? Details please.

:-/

- Samuli

Re: [gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?

[Kacper Kowalik]

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

W dniu 30.07.2011 15:55, Samuli Suominen pisze:
> On 07/30/2011 01:46 PM, Ciaran McCreesh wrote:
>> On Sat, 30 Jul 2011 10:27:27 +0300
>> Samuli Suominen <ssuominen@gentoo.org> wrote:
>>> Since running separate /usr without mounting it from initramfs on top
>>> of / before init is and has been broken with udev for a long time
>>> now[1][2][3]
>>>
>>> [1] http://bugs.gentoo.org/show_bug.cgi?id=364235
>>> [2] http://fedoraproject.org/wiki/Features/UsrMove#Move_all_to_.2Fusr
>>> [3]
>>> http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken
>>>
>>> Can we warn users about not doing the separate /usr mistake in the
>>> handbook?
>>
>> It's important to consider the timeline here. Separate /usr was
>> accidentally broken by a sudden increase in dependencies from base
>> system packages to desktopy things. It was only later that certain
>> people decided that "oh, separate /usr is a bad idea anyway", and they
>> did so because they couldn't figure out how to fix the mess they'd
>> caused. This is very much a case of carelessly letting the horse escape
>> and then trying to convince everyone that no-one needs a horse anyway...
>>
> 
> Someone mentioned NFS mount on /usr.  Do we have other reasons?  How
> many users that might be?

That covers headless/diskless clusters and I suspect many people still
do that.
Cheers,
Kacper



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

Re: [gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?

[Michał Górny]

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

On Sat, 30 Jul 2011 16:55:23 +0300
Samuli Suominen <ssuominen@gentoo.org> wrote:

> I dislike the IUSE="+static" some packages are currently doing to
> workaround this, instead of moving the needed shared libs to /
> 
> I dislike the idea of pciutils and usbutils database(s) in
> non-standard location in / to keep udev working
> 
> I dislike the idea of moving libglib-2.0, libdbus-1, libdbus-glib-1,
> and couple of dozen more libs to /
> 
> I dislike the idea of maintaining and keeping track of the files in /
> using files from /usr. Does any of the PMs have check for this, like
> NEEDED entries? I can imagine this getting past the maintainers easily
> otherwise
> 
> Most likely still not seeing the full picture here, and just
> scratching the surface...
> Despite that, I don't have any strong opinion on any of this, just
> need to know if I should start moving the files over

Honestly, I'd rather see system libs and apps being moved to /usr
rather than the opposite. IMO the benefit of getting a clear tree is
greater than benefits of having separate fs for 'system' and
'non-system' packages which actually tend to randomly depend one on
another.

What's the point of having shared /usr if you need to keep /bin, /lib,
/sbin in sync anyway? And considering the above, the number of files to
keep separate & synced is growing, and thus our potential / gets bigger
and bigger.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?

[Chris Coleman]

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

On 30 July 2011 08:27, Samuli Suominen <ssuominen@gentoo.org> wrote:

> Since running separate /usr without mounting it from initramfs on top of
> / before init is and has been broken with udev for a long time now[1][2][3]
>
> [1] http://bugs.gentoo.org/show_bug.cgi?id=364235
> [2] http://fedoraproject.org/wiki/Features/UsrMove#Move_all_to_.2Fusr
> [3]
> http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken
>
> Can we warn users about not doing the separate /usr mistake in the
> handbook?
>

I reported this to bugzilla[1] in June. There was no resolution, but the
discussion was interesting and worth reading. To summarize, changing the
handbook would be a start, but it doesn't solve the larger problem, and
separate /usr will be supported for as long as it is practical to do so.

I don't know how to resolve the situation, but I'm relieved to hear that
other people care.

[1] https://bugs.gentoo.org/show_bug.cgi?id=372317

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

Re: [gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?

[Samuli Suominen]

On 07/31/2011 02:22 PM, Kacper Kowalik wrote:
> W dniu 30.07.2011 15:55, Samuli Suominen pisze:
>> On 07/30/2011 01:46 PM, Ciaran McCreesh wrote:
>>> On Sat, 30 Jul 2011 10:27:27 +0300
>>> Samuli Suominen <ssuominen@gentoo.org> wrote:
>>>> Since running separate /usr without mounting it from initramfs on top
>>>> of / before init is and has been broken with udev for a long time
>>>> now[1][2][3]
>>>>
>>>> [1] http://bugs.gentoo.org/show_bug.cgi?id=364235
>>>> [2] http://fedoraproject.org/wiki/Features/UsrMove#Move_all_to_.2Fusr
>>>> [3]
>>>> http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken
>>>>
>>>> Can we warn users about not doing the separate /usr mistake in the
>>>> handbook?
>>>
>>> It's important to consider the timeline here. Separate /usr was
>>> accidentally broken by a sudden increase in dependencies from base
>>> system packages to desktopy things. It was only later that certain
>>> people decided that "oh, separate /usr is a bad idea anyway", and they
>>> did so because they couldn't figure out how to fix the mess they'd
>>> caused. This is very much a case of carelessly letting the horse escape
>>> and then trying to convince everyone that no-one needs a horse anyway...
>>>
>>
>> Someone mentioned NFS mount on /usr.  Do we have other reasons?  How
>> many users that might be?
> 
> That covers headless/diskless clusters and I suspect many people still
> do that.
> Cheers,
> Kacper
> 
> 

I haven't tested but it seems this is not a problem afterall:

USE="nbd" for dracut enables the NFS support:

http://fedoraproject.org/wiki/Dracut/Options#NFS

Re: [gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?

[Samuli Suominen]

On 07/31/2011 05:23 PM, Michał Górny wrote:
> On Sat, 30 Jul 2011 16:55:23 +0300
> Samuli Suominen <ssuominen@gentoo.org> wrote:
> 
>> I dislike the IUSE="+static" some packages are currently doing to
>> workaround this, instead of moving the needed shared libs to /
>>
>> I dislike the idea of pciutils and usbutils database(s) in
>> non-standard location in / to keep udev working
>>
>> I dislike the idea of moving libglib-2.0, libdbus-1, libdbus-glib-1,
>> and couple of dozen more libs to /
>>
>> I dislike the idea of maintaining and keeping track of the files in /
>> using files from /usr. Does any of the PMs have check for this, like
>> NEEDED entries? I can imagine this getting past the maintainers easily
>> otherwise
>>
>> Most likely still not seeing the full picture here, and just
>> scratching the surface...
>> Despite that, I don't have any strong opinion on any of this, just
>> need to know if I should start moving the files over
> 
> Honestly, I'd rather see system libs and apps being moved to /usr
> rather than the opposite. IMO the benefit of getting a clear tree is
> greater than benefits of having separate fs for 'system' and
> 'non-system' packages which actually tend to randomly depend one on
> another.

that's my impression now too since nobody has managed to provide useful
case for separate /usr, or they have been very vague like adding 1+1 on
/ and /usr filesystem sizes and counting the risk of corrupted
filesystem from that (one word: backup)
and even then they can go with dracut and have the initramfs mount the
/usr before init
dracut with it's externsive modules covers the other mentioned cases too

so pursuing for getting rid of shared/static -workarounds and / files
depending on /usr files constistency

not to mention avoiding moving a lot of files to / for pursuing that
otherwise

this is starting to look good:

http://fedoraproject.org/wiki/Features/UsrMove#Move_all_to_.2Fusr


> 
> What's the point of having shared /usr if you need to keep /bin, /lib,
> /sbin in sync anyway? And considering the above, the number of files to
> keep separate & synced is growing, and thus our potential / gets bigger
> and bigger.
> 

Re: [gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?

[Chí-Thanh Christopher Nguyễn]

Samuli Suominen schrieb:

> that's my impression now too since nobody has managed to provide useful
> case for separate /usr, or they have been very vague like adding 1+1 on
> / and /usr filesystem sizes and counting the risk of corrupted
> filesystem from that (one word: backup)

Maybe I have to explain in more detail:
When is there a risk of data corruption involving /usr? For example,
when the filesystem which contains /usr is being written to while the
power fails or the kernel panics. But /usr is almost never written to,
it is the other directories like /home, /var or the upcoming /run.

Backup is orthogonal to this question.


Best regards,
Chí-Thanh Christopher Nguyen

Re: [gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?

[Michał Górny]

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

On Mon, 01 Aug 2011 10:23:07 +0300
Samuli Suominen <ssuominen@gentoo.org> wrote:

> this is starting to look good:
> 
> http://fedoraproject.org/wiki/Features/UsrMove#Move_all_to_.2Fusr

Honestly, that seems like a poor draft to me. First of all, I don't see
a reason to move /sbin to /usr/bin instead of /usr/sbin.

Second of all, the benefits are much smaller if we still have to
symlink all the dirs. I'd rather keep /bin (and maybe /sbin) on rootfs,
and just symlink a few compat tools (like sh). Then we should start
looking heavily for unnecessarily hardcoded paths.

I don't think keeping /lib* is absolutely necessary. That one should be
pretty easy to move.

Of course, the largest problem is migrating existing systems with
split / and /usr.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?

[Samuli Suominen]

On 08/01/2011 10:45 AM, Chí-Thanh Christopher Nguyễn wrote:
> Samuli Suominen schrieb:
> 
>> that's my impression now too since nobody has managed to provide useful
>> case for separate /usr, or they have been very vague like adding 1+1 on
>> / and /usr filesystem sizes and counting the risk of corrupted
>> filesystem from that (one word: backup)
> 
> Maybe I have to explain in more detail:
> When is there a risk of data corruption involving /usr? For example,
> when the filesystem which contains /usr is being written to while the
> power fails or the kernel panics. But /usr is almost never written to,
> it is the other directories like /home, /var or the upcoming /run.
> 
> Backup is orthogonal to this question.

should think this inverse; make separate partitions for the data
directories such as /home or /var
have /usr on /
so when / goes down, you still keep your data

right?

Re: [gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?

[Chí-Thanh Christopher Nguyễn]

Samuli Suominen schrieb:
> should think this inverse; make separate partitions for the data
> directories such as /home or /var
> have /usr on /
> so when / goes down, you still keep your data

Putting /home and /var on separate partitions can increase isolation
even further, that is true.

On desktop systems, directories outside /usr and /home contribute not
much to the total disk space used. So if you have one / and one /usr
partition, the total amount of data that would be exposed to corruption
is not much different from having all of /, /home, /usr and /var
separate.
On servers, it might make sense to keep /var separate depending on which
services write there.


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?

[Eray Aslan]

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

On 2011-08-01 10:23 AM, Samuli Suominen wrote:
> that's my impression now too since nobody has managed to provide useful
> case for separate /usr, or they have been very vague

I will switch if I have to but saying / and /usr on the same filesystem
is the better technical solution just annoys me.

I understand if going against upstream and keeping them seperate is not
worth the hassle and noone steps up to do it.  But then we should say
so.  Please don't kid yourself (or others).
-- 
Eray Aslan <eras@gentoo.org>


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

Re: [gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?

[Michał Górny]

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

On Mon, 01 Aug 2011 10:22:02 +0200
Chí-Thanh Christopher Nguyễn <chithanh@gentoo.org> wrote:

> Samuli Suominen schrieb:
> > should think this inverse; make separate partitions for the data
> > directories such as /home or /var
> > have /usr on /
> > so when / goes down, you still keep your data
> 
> Putting /home and /var on separate partitions can increase isolation
> even further, that is true.
> 
> On desktop systems, directories outside /usr and /home contribute not
> much to the total disk space used. So if you have one / and one /usr
> partition, the total amount of data that would be exposed to
> corruption is not much different from having all of /, /home, /usr
> and /var separate.

On desktop systems, it is common to have random hacks around. Sometimes
large amounts of data are in /var, sometimes somewhere in /mnt,
sometimes in /home. I don't think that setup is really worth
considering deeply.

> On servers, it might make sense to keep /var separate depending on
> which services write there.

BTW is the /srv concept dead already?

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?

[Jorge Manuel B. S. Vicetto]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 01-08-2011 08:31, Eray Aslan wrote:
> On 2011-08-01 10:23 AM, Samuli Suominen wrote:
>> that's my impression now too since nobody has managed to provide
>> useful case for separate /usr, or they have been very vague
> 
> I will switch if I have to but saying / and /usr on the same
> filesystem is the better technical solution just annoys me.
> 
> I understand if going against upstream and keeping them seperate is
> not worth the hassle and noone steps up to do it.  But then we should
> say so.  Please don't kid yourself (or others).

I agree with Eray. Furthermore, please stop trying to reverse "the
game". It's those that want to break existing policies and conventions
that have to justify why they want to do that, not those that want to
keep using what has worked for years. You may not need or like it, but I
want to be able to use partition schemes like the following without
needing to use an initramfs:

/dev/md4                /boot
/dev/md2                /
/dev/sda1               swap
/dev/sdb1               swap

/dev/vg/home            /home
/dev/vg/usr             /usr
/dev/vg/portage         /usr/portage
/dev/vg/distfiles       /usr/portage/distfiles
/dev/vg/var             /var
/dev/vg/vtmp            /var/tmp
/dev/vg/www             /var/www
/dev/vg/repos           /home/repositories
/dev/vg/release         /home/release

Also, desktop users that don't split the /usr path might not like the
"stress" that /usr/portage will add to the / partition - not to talk
about the size and inode constraints.

With the above design, I have on a system the following disk space use:

Filesystem                Size  Used Avail Use% Mounted on
rootfs                    9,4G  262M  8,7G   3% /

I'm growing tired of how complex and over-designed desktop technologies
that hide stuff from the users keep trying to break the "unix way" and
convince us they're "awesome". No, I don't need or want *kit, groups
exist for something. No, applications that do "magic stuff" with dbus
and xml (and I like xml) on the users back and hide how X work aren't a
"good thing(tm)".

Finally, Gentoo's init system is and will likely be for a long time
openrc, so stop trying to push crazy or experimental init systems - most
with a seemingly "poor design" and unable to do what an init system
needs to do (start and stop services).

- -- 
Regards,

Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJONm+6AAoJEC8ZTXQF1qEP10wP/ifqJFPJxbpbhJfMc2+UpvAj
Danv5I4hRhOhixfz5ni63Kw++kFmxJ2o0oSxmPOMUuIZgdakDAQFAMPhGnTZc6l6
/cqrraZjM215fcJLq3mzq2KfC+c6l45gLv87sagmwuTLLSDnFbXllY2vNo2KgQ/u
Brf1IxqBMQeesC21gVNyewnLpWe/hPLqoigIYepBQt4Fg3GxhRYQuVcKC/oE9mO2
Z/0pOJW42fE5i5+VZRPUb7q9WC2bAlVQymRDc+Lt/b6f6VUIFa+SVgcCAkE2HoPo
Xue+jiMNCDAvWuqmGeRGySDmAp3VtqobHjaaVkLXDJOG14u0HmP3qXK9oLtSA3Fz
FUaL8yNjfjlZ94ntRZax2WCFat66tX03pF4QC/EQfnVx+8dgMUH3sop/s8Ay1pLX
Q05sXhoEIyNMOfo04IJt6aQqgLqKHuxL9dTu+q1dN7pnQ5CGZ027W6XCe8251UIe
6wmyVwaQPQKSZ0N7j0LkqujFmCjPoFRCAN9QRPMM9g4rYTuVsjm49BjgFFFegQ+y
qTM3lvriQR34a1x1khnnb44g+1611q92CuTjcr6B9Ho1IY6Osqk68y3hA2WTZ0+p
S6+cKiBlnA1Q6+2lqcVP89Fb5WP44LHc5xmAvyzfx5LJsQ3XvINgrrx9kGbvgge7
wIY+OXxnZD8oW0MpiYO2
=ybUS
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?

[Dale]

Jorge Manuel B. S. Vicetto wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 01-08-2011 08:31, Eray Aslan wrote:
>    
>> On 2011-08-01 10:23 AM, Samuli Suominen wrote:
>>      
>>> that's my impression now too since nobody has managed to provide
>>> useful case for separate /usr, or they have been very vague
>>>        
>> I will switch if I have to but saying / and /usr on the same
>> filesystem is the better technical solution just annoys me.
>>
>> I understand if going against upstream and keeping them seperate is
>> not worth the hassle and noone steps up to do it.  But then we should
>> say so.  Please don't kid yourself (or others).
>>      
> I agree with Eray. Furthermore, please stop trying to reverse "the
> game". It's those that want to break existing policies and conventions
> that have to justify why they want to do that, not those that want to
> keep using what has worked for years. You may not need or like it, but I
> want to be able to use partition schemes like the following without
> needing to use an initramfs:
>
> /dev/md4                /boot
> /dev/md2                /
> /dev/sda1               swap
> /dev/sdb1               swap
>
> /dev/vg/home            /home
> /dev/vg/usr             /usr
> /dev/vg/portage         /usr/portage
> /dev/vg/distfiles       /usr/portage/distfiles
> /dev/vg/var             /var
> /dev/vg/vtmp            /var/tmp
> /dev/vg/www             /var/www
> /dev/vg/repos           /home/repositories
> /dev/vg/release         /home/release
>
> Also, desktop users that don't split the /usr path might not like the
> "stress" that /usr/portage will add to the / partition - not to talk
> about the size and inode constraints.
>
> With the above design, I have on a system the following disk space use:
>
> Filesystem                Size  Used Avail Use% Mounted on
> rootfs                    9,4G  262M  8,7G   3% /
>
> I'm growing tired of how complex and over-designed desktop technologies
> that hide stuff from the users keep trying to break the "unix way" and
> convince us they're "awesome". No, I don't need or want *kit, groups
> exist for something. No, applications that do "magic stuff" with dbus
> and xml (and I like xml) on the users back and hide how X work aren't a
> "good thing(tm)".
>
> Finally, Gentoo's init system is and will likely be for a long time
> openrc, so stop trying to push crazy or experimental init systems - most
> with a seemingly "poor design" and unable to do what an init system
> needs to do (start and stop services).
>
> - -- 
> Regards,
>
> Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
> Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.17 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>    

As a user, I have /usr/portge on a separate partition as well.  I was 
also planning to have a separate /usr partition soon when I redo my 
drive layout.  It sounds like Gentoo is telling me I no longer have that 
option without having a initramfs.  I guess I will have to decide 
whether I want to add one more thing to break to have a separate /usr or 
leave /usr on the / partition.

I thought Gentoo was about choices?  It seems one choice is being 
removed or is it?

Dale

:-)  :-)

Re: [gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?

[Ciaran McCreesh]

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

On Mon, 01 Aug 2011 05:58:49 -0500
Dale <rdalek1967@gmail.com> wrote:
> I thought Gentoo was about choices?  It seems one choice is being 
> removed or is it?

Gentoo might be, but Fedora isn't. This is a decision that was made by
one Fedora developer.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?

[Marc Schiffbauer]

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

* Samuli Suominen schrieb am 01.08.11 um 09:23 Uhr:
> On 07/31/2011 05:23 PM, Michał Górny wrote:
> > On Sat, 30 Jul 2011 16:55:23 +0300
> > Samuli Suominen <ssuominen@gentoo.org> wrote:
> > 
> >> I dislike the IUSE="+static" some packages are currently doing to
> >> workaround this, instead of moving the needed shared libs to /
> >>
> >> I dislike the idea of pciutils and usbutils database(s) in
> >> non-standard location in / to keep udev working
> >>
> >> I dislike the idea of moving libglib-2.0, libdbus-1, libdbus-glib-1,
> >> and couple of dozen more libs to /
> >>
> >> I dislike the idea of maintaining and keeping track of the files in /
> >> using files from /usr. Does any of the PMs have check for this, like
> >> NEEDED entries? I can imagine this getting past the maintainers easily
> >> otherwise
> >>
> >> Most likely still not seeing the full picture here, and just
> >> scratching the surface...
> >> Despite that, I don't have any strong opinion on any of this, just
> >> need to know if I should start moving the files over
> > 
> > Honestly, I'd rather see system libs and apps being moved to /usr
> > rather than the opposite. IMO the benefit of getting a clear tree is
> > greater than benefits of having separate fs for 'system' and
> > 'non-system' packages which actually tend to randomly depend one on
> > another.
> 
> that's my impression now too since nobody has managed to provide useful
> case for separate /usr, or they have been very vague like adding 1+1 on
> / and /usr filesystem sizes and counting the risk of corrupted
> filesystem from that (one word: backup)
> and even then they can go with dracut and have the initramfs mount the
> /usr before init
> dracut with it's externsive modules covers the other mentioned cases too


I always keep /usr seperate from / for isolation reasons.

IMO there are some good reasons to do so:

* For example if a filesystem fills 100%. Imagine your /usr is 100%
  full by accident.

  If you have a seperate / you always can still write to /etc or /root
  which might save your life.

  Sometimes a system might not even be bootable if / has no space
  left.

  Sure, this is not the case normally and never should be. But if it
  happens to you, you will be happy to have them seperated.

* IMO its a good idea to seperate mostly static filesystems from
  those with many writes 

* Some people want a read-only /usr

* /usr/portage can get very huge and is often written to. With
  / and /usr being on the same FS you really want to have
  /usr/portage on a seperate FS then

I am sure there are some other reasons too. 

Just my 2¢

-Marc
-- 
8AAC 5F46 83B4 DB70 8317  3723 296C 6CCA 35A6 4134

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

Re: [gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?

[Pacho Ramos]

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

El lun, 01-08-2011 a las 13:12 +0200, Marc Schiffbauer escribió:
[...]
> * /usr/portage can get very huge and is often written to. With
>   / and /usr being on the same FS you really want to have
>   /usr/portage on a seperate FS then
> 
> I am sure there are some other reasons too. 
> 
> Just my 2¢
> 
> -Marc

Having /usr/portage on a different partition will still be supported if
I understood correctly (at least, it still works fine for me even having
the rest of /usr under / partition)

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

Re: [gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?

[Marc Schiffbauer]

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

* Jorge Manuel B. S. Vicetto schrieb am 01.08.11 um 11:19 Uhr:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> On 01-08-2011 08:31, Eray Aslan wrote:
> > On 2011-08-01 10:23 AM, Samuli Suominen wrote:
> >> that's my impression now too since nobody has managed to provide
> >> useful case for separate /usr, or they have been very vague
> > 
> > I will switch if I have to but saying / and /usr on the same
> > filesystem is the better technical solution just annoys me.
> > 
> > I understand if going against upstream and keeping them seperate is
> > not worth the hassle and noone steps up to do it.  But then we should
> > say so.  Please don't kid yourself (or others).
> 
> I agree with Eray. Furthermore, please stop trying to reverse "the
> game". It's those that want to break existing policies and conventions
> that have to justify why they want to do that, not those that want to
> keep using what has worked for years. You may not need or like it, but I
> want to be able to use partition schemes like the following without
> needing to use an initramfs:
> 
> /dev/md4                /boot
> /dev/md2                /
> /dev/sda1               swap
> /dev/sdb1               swap
> 
> /dev/vg/home            /home
> /dev/vg/usr             /usr
> /dev/vg/portage         /usr/portage
> /dev/vg/distfiles       /usr/portage/distfiles
> /dev/vg/var             /var
> /dev/vg/vtmp            /var/tmp
> /dev/vg/www             /var/www
> /dev/vg/repos           /home/repositories
> /dev/vg/release         /home/release
> 
> Also, desktop users that don't split the /usr path might not like the
> "stress" that /usr/portage will add to the / partition - not to talk
> about the size and inode constraints.
> 
> With the above design, I have on a system the following disk space use:
> 
> Filesystem                Size  Used Avail Use% Mounted on
> rootfs                    9,4G  262M  8,7G   3% /
> 
> I'm growing tired of how complex and over-designed desktop technologies
> that hide stuff from the users keep trying to break the "unix way" and
> convince us they're "awesome". No, I don't need or want *kit, groups
> exist for something. No, applications that do "magic stuff" with dbus
> and xml (and I like xml) on the users back and hide how X work aren't a
> "good thing(tm)".
> 
> Finally, Gentoo's init system is and will likely be for a long time
> openrc, so stop trying to push crazy or experimental init systems - most
> with a seemingly "poor design" and unable to do what an init system
> needs to do (start and stop services).


I fully agree with you here!

I always considered systems with just one big / as badly designed.

It's simply not the unix way. Sure it makes some things easier in the
first place. But that does not mean that it is a better technical
solution.

-Marc
-- 
8AAC 5F46 83B4 DB70 8317  3723 296C 6CCA 35A6 4134

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

Re: [gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?

[Marc Schiffbauer]

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

* Pacho Ramos schrieb am 01.08.11 um 13:19 Uhr:
> El lun, 01-08-2011 a las 13:12 +0200, Marc Schiffbauer escribió:
> [...]
> > * /usr/portage can get very huge and is often written to. With
> >   / and /usr being on the same FS you really want to have
> >   /usr/portage on a seperate FS then
> > 
> > I am sure there are some other reasons too. 
> > 
> > Just my 2¢
> > 
> > -Marc
> 
> Having /usr/portage on a different partition will still be supported if
> I understood correctly (at least, it still works fine for me even having
> the rest of /usr under / partition)

yes. My point was, that if you have a separate /usr you may be ok
with no seperate /usr/portage

-Marc
-- 
8AAC 5F46 83B4 DB70 8317  3723 296C 6CCA 35A6 4134

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

Re: [gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?

[Kacper Kowalik]

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

W dniu 01.08.2011 13:12, Marc Schiffbauer pisze:
> * Samuli Suominen schrieb am 01.08.11 um 09:23 Uhr:
>> On 07/31/2011 05:23 PM, Michał Górny wrote:
>>> On Sat, 30 Jul 2011 16:55:23 +0300
>>> Samuli Suominen <ssuominen@gentoo.org> wrote:
>>>
>>>> I dislike the IUSE="+static" some packages are currently doing to
>>>> workaround this, instead of moving the needed shared libs to /
>>>>
>>>> I dislike the idea of pciutils and usbutils database(s) in
>>>> non-standard location in / to keep udev working
>>>>
>>>> I dislike the idea of moving libglib-2.0, libdbus-1, libdbus-glib-1,
>>>> and couple of dozen more libs to /
>>>>
>>>> I dislike the idea of maintaining and keeping track of the files in /
>>>> using files from /usr. Does any of the PMs have check for this, like
>>>> NEEDED entries? I can imagine this getting past the maintainers easily
>>>> otherwise
>>>>
>>>> Most likely still not seeing the full picture here, and just
>>>> scratching the surface...
>>>> Despite that, I don't have any strong opinion on any of this, just
>>>> need to know if I should start moving the files over
>>>
>>> Honestly, I'd rather see system libs and apps being moved to /usr
>>> rather than the opposite. IMO the benefit of getting a clear tree is
>>> greater than benefits of having separate fs for 'system' and
>>> 'non-system' packages which actually tend to randomly depend one on
>>> another.
>>
>> that's my impression now too since nobody has managed to provide useful
>> case for separate /usr, or they have been very vague like adding 1+1 on
>> / and /usr filesystem sizes and counting the risk of corrupted
>> filesystem from that (one word: backup)
>> and even then they can go with dracut and have the initramfs mount the
>> /usr before init
>> dracut with it's externsive modules covers the other mentioned cases too
> 

I'm responding to this particular mail cause it's last in queue and
because it replicates things already mentioned before.

I am a zeleous follower of having seperate /usr partition, thus seeing
moot arguments that goes "in favour" of "my" case is pretty annoying.

> * For example if a filesystem fills 100%. Imagine your /usr is 100%
>   full by accident.
Thats bs, cause / can fill out even when you have /usr seperate. Even
faster cause usually you've got very small / like <<1Gb. You miss one
thing that accidentally writes to / and you're as much toasted.

> * IMO its a good idea to seperate mostly static filesystems from
>   those with many writes 
How mering / and /usr increase that? What prevents you having separate
partition for heavy write areas inside /usr ?

> * Some people want a read-only /usr
Yes, that's only reasonable argument here.

> * /usr/portage can get very huge and is often written to. With
>   / and /usr being on the same FS you really want to have
>   /usr/portage on a seperate FS then
Even with separate /usr it's good to have separate partition for
/usr/portage. You can have partition with small blocks and large no. of
inodes this way. How does that prevents merging / and /usr ?

Cheers,
Kacper


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

Re: [gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?

[Pacho Ramos]

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

El lun, 01-08-2011 a las 13:30 +0200, Marc Schiffbauer escribió:
> * Pacho Ramos schrieb am 01.08.11 um 13:19 Uhr:
> > El lun, 01-08-2011 a las 13:12 +0200, Marc Schiffbauer escribió:
> > [...]
> > > * /usr/portage can get very huge and is often written to. With
> > >   / and /usr being on the same FS you really want to have
> > >   /usr/portage on a seperate FS then
> > > 
> > > I am sure there are some other reasons too. 
> > > 
> > > Just my 2¢
> > > 
> > > -Marc
> > 
> > Having /usr/portage on a different partition will still be supported if
> > I understood correctly (at least, it still works fine for me even having
> > the rest of /usr under / partition)
> 
> yes. My point was, that if you have a separate /usr you may be ok
> with no seperate /usr/portage
> 
> -Marc

Well, I guess it depends on every administrator :-), for example in my
case I use a separate partition for it to have it mounted without
"notail" reiserfs option (as "tail" is slower in "normal" conditions),
allowing me to spend around 300 MB on it instead of 3,5G. That way, I
would have it in a separate partition even having /usr on a separate
one.

But this is probably a bit off-topic :-)

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

Re: [gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?

[Marc Schiffbauer]

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

* Kacper Kowalik schrieb am 01.08.11 um 13:32 Uhr:
> 
> I'm responding to this particular mail cause it's last in queue and
> because it replicates things already mentioned before.
> 
> I am a zeleous follower of having seperate /usr partition, thus seeing
> moot arguments that goes "in favour" of "my" case is pretty annoying.
> 
> > * For example if a filesystem fills 100%. Imagine your /usr is 100%
> >   full by accident.
> Thats bs, cause / can fill out even when you have /usr seperate. Even
> faster cause usually you've got very small / like <<1Gb. You miss one
> thing that accidentally writes to / and you're as much toasted.
> 

The point is that /usr/* has much more load and changes than /
alone. ANd a full /usr is much more common than a full / if it is
seperated.

> > * IMO its a good idea to seperate mostly static filesystems from
> >   those with many writes 
> How mering / and /usr increase that? What prevents you having separate
> partition for heavy write areas inside /usr ?

Nothing prevents me. But just having /usr seperat is much easier to
maintain.

And well, the FHS clearly allows a sepearte /usr. Everything that is
required to boot belongs to / until other filesystems get mounted.

> 
> > * Some people want a read-only /usr
> Yes, that's only reasonable argument here.
> 
> > * /usr/portage can get very huge and is often written to. With
> >   / and /usr being on the same FS you really want to have
> >   /usr/portage on a seperate FS then
> Even with separate /usr it's good to have separate partition for
> /usr/portage. You can have partition with small blocks and large no. of
> inodes this way. How does that prevents merging / and /usr ?

I agree with you here. My point was that with a seperate /usr you
can go well without seperate /usr/portage where you cannot without.




-Marc
PS,OT: /usr/portage always seemed special to me.
Would'nt /var/lib/portage be a better place for it?
-- 
8AAC 5F46 83B4 DB70 8317  3723 296C 6CCA 35A6 4134

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

Re: [gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?

[Samuli Suominen]

On 08/01/2011 02:32 PM, Kacper Kowalik wrote:
> W dniu 01.08.2011 13:12, Marc Schiffbauer pisze:
>> * Samuli Suominen schrieb am 01.08.11 um 09:23 Uhr:
>>> On 07/31/2011 05:23 PM, Michał Górny wrote:
>>>> On Sat, 30 Jul 2011 16:55:23 +0300

[ .. ]

> I am a zeleous follower of having seperate /usr partition, thus seeing
> moot arguments that goes "in favour" of "my" case is pretty annoying.

need to have a verifiable reason in order to block a feature that would
add, not remove, functionality.

trying to find an right answer to wrong question, and preventing "what
could be progress" for selfish reasons can be annoying too. that is, in
addition to the hatemail with no actual point in them.

>> * Some people want a read-only /usr
> Yes, that's only reasonable argument here.

see $subject, " ... without proper initramfs"

using a separate /usr would still be possible read-only, with an
initramfs created by dracut

> 
> Cheers,
> Kacper
> 

Re: [gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?

[Samuli Suominen]

On 08/01/2011 03:25 PM, Samuli Suominen wrote:
> On 08/01/2011 02:32 PM, Kacper Kowalik wrote:
>> W dniu 01.08.2011 13:12, Marc Schiffbauer pisze:
>>> * Samuli Suominen schrieb am 01.08.11 um 09:23 Uhr:
>>>> On 07/31/2011 05:23 PM, Michał Górny wrote:
>>>>> On Sat, 30 Jul 2011 16:55:23 +0300
> 
> [ .. ]
> 
>> I am a zeleous follower of having seperate /usr partition, thus seeing
>> moot arguments that goes "in favour" of "my" case is pretty annoying.
> 
> need to have a verifiable reason in order to block a feature that would
> add, not remove, functionality.
> 
> trying to find an right answer to wrong question, and preventing "what
> could be progress" for selfish reasons can be annoying too. that is, in
> addition to the hatemail with no actual point in them.

just to clarify, that wasn't in anyway for you, or anyone in particular...

> 
>>> * Some people want a read-only /usr
>> Yes, that's only reasonable argument here.
> 
> see $subject, " ... without proper initramfs"
> 
> using a separate /usr would still be possible read-only, with an
> initramfs created by dracut

http://fedoraproject.org/wiki/Features/UsrMove
http://fedoraproject.org/wiki/Features/UsrMove#Example_F15

"Provide a way of mounting /usr read-only and share it between multiple
hosts to save maintenance and space."

"There is no way to reliably bring up a modern system with an empty
/usr, there are two alternatives to fix it: copy /usr back to the rootfs
or use an initramfs which can hide the split-off from the system."

"Historically /bin, /sbin, /lib had the purpose to contain the utilities
to mount /usr. This role can now be taken by the initramfs. Because the
initramfs knows, where to find the root partition (which includes /etc),
it can parse /etc/fstab and other configuration files and mount /usr
before it finally switches the root partition and executes
/usr/bin/init. From this point on init mounts the remaining partitions
in /etc/fstab and the system starts as usual."

>>
>> Cheers,
>> Kacper
>>
> 
> 

Re: [gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?

[Ciaran McCreesh]

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

On Mon, 01 Aug 2011 15:45:26 +0300
Samuli Suominen <ssuominen@gentoo.org> wrote:
> "There is no way to reliably bring up a modern system with an empty
> /usr, there are two alternatives to fix it: copy /usr back to the
> rootfs or use an initramfs which can hide the split-off from the
> system."

To be clear here: by "modern" system they mean one that's running dbus,
systemd, ConsoleKit, Gnome etc.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?

[Samuli Suominen]

* Jorge Manuel B. S. Vicetto schrieb am 01.08.11 um 11:19 Uhr:
> I agree with Eray. Furthermore, please stop trying to reverse "the
> game". It's those that want to break existing policies and conventions
> that have to justify why they want to do that, not those that want to
> keep using what has worked for years.

I wouldn't call the current static -workarounds, and files from / using
files from /usr, neither a clean solution or working

The separation is unnecessary maintaince burden for something that has
maintaince free replacement

> You may not need or like it, but I want to be able to use
> partition  schemes like the following without needing to use
> an initramfs:

Sorry for dismissing the lines below that ":" mark then. Feel free to
ignore me, no offense taken, but I'll be disappointed if you won't
provide a reasoning for resisting part of the solution

> Also, desktop users that don't split the /usr path might not like the
> "stress" that /usr/portage will add to the / partition - not to talk
> about the size and inode constraints.

Good point, so handbook will need a patch for /usr/portage partition
recommendation after the fact

> I'm growing tired of how complex and over-designed desktop technologies
> that hide stuff from the users keep trying to break the "unix way" and
> convince us they're "awesome". No, I don't need or want *kit, groups
> exist for something. No, applications that do "magic stuff" with dbus
> and xml (and I like xml) on the users back and hide how X work aren't a
> "good thing(tm)".

Then one should do something about it, like providing an alternative or
at very least, provide upstreams with patches for making the new stacks
optional

> Finally, Gentoo's init system is and will likely be for a long time
> openrc, so stop trying to push crazy or experimental init systems - most
> with a seemingly "poor design" and unable to do what an init system
> needs to do (start and stop services).

This isn't about systemd, but indeed it will solve one compability
obstacle for them too. No harm there.

Re: [gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?

[Ciaran McCreesh]

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

On Mon, 01 Aug 2011 17:10:27 +0300
Samuli Suominen <ssuominen@gentoo.org> wrote:
> This isn't about systemd, but indeed it will solve one compability
> obstacle for them too. No harm there.

Right, it's about the Gnome operating system, of which systemd is but
one strongly coupled part.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?

[Michał Górny]

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

On Mon, 01 Aug 2011 17:10:27 +0300
Samuli Suominen <ssuominen@gentoo.org> wrote:

> * Jorge Manuel B. S. Vicetto schrieb am 01.08.11 um 11:19 Uhr:
> > I agree with Eray. Furthermore, please stop trying to reverse "the
> > game". It's those that want to break existing policies and
> > conventions that have to justify why they want to do that, not
> > those that want to keep using what has worked for years.
> 
> I wouldn't call the current static -workarounds, and files from /
> using files from /usr, neither a clean solution or working

Not to mention there are no 'libexec' nor 'share' directories in
rootfs which means files get randomly misplaced. And I don't really
think that introducing new directories in / is a good solution.

One thing we should consider as well is /opt. It seems like moving data
from it into /usr should be a good idea too. This is also annoying to
separate /usr users wanting to have a small rootfs -- as they either
have to hack /opt out of rootfs or introduce just an another filesystem
for it.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?

[Michał Górny]

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

On Mon, 1 Aug 2011 13:30:37 +0200
Marc Schiffbauer <mschiff@gentoo.org> wrote:

> * Pacho Ramos schrieb am 01.08.11 um 13:19 Uhr:
> > Having /usr/portage on a different partition will still be
> > supported if I understood correctly (at least, it still works fine
> > for me even having the rest of /usr under / partition)
> 
> yes. My point was, that if you have a separate /usr you may be ok
> with no seperate /usr/portage

Don't really think so. /usr/portage is a very specific fs, and it's
better to always keep it separated. That's one thing which can be
restored with a simple 'emerge --sync'.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?

[Francesco Riosa]

2011/8/1 Michał Górny <mgorny@gentoo.org>:
> On Mon, 1 Aug 2011 13:30:37 +0200
> Marc Schiffbauer <mschiff@gentoo.org> wrote:
>
>> * Pacho Ramos schrieb am 01.08.11 um 13:19 Uhr:
>> > Having /usr/portage on a different partition will still be
>> > supported if I understood correctly (at least, it still works fine
>> > for me even having the rest of /usr under / partition)
>>
>> yes. My point was, that if you have a separate /usr you may be ok
>> with no seperate /usr/portage
>
> Don't really think so. /usr/portage is a very specific fs, and it's
> better to always keep it separated. That's one thing which can be
> restored with a simple 'emerge --sync'.

everything about portage is very specific and should be separated, I
would like to see an addition of one root directory "gentoo" where
${PKGMANAGER} keep all it's stuff.
Some of these are already moveable with ${*DIR} variables in
make.conf, others are not

20K     /gentoo/tmp
20K     /gentoo/overlays
639M    /gentoo/portage
3.1G    /gentoo/distfiles
4.1M    /gentoo/var/log
36K     /gentoo/var/lib/portage
43M     /gentoo/var/db/pkg
940K    /gentoo/var/cache/edb
2.7M    /gentoo/packages

Re: [gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?

[Ciaran McCreesh]

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

On Mon, 1 Aug 2011 19:22:15 +0200
Francesco Riosa <vivo75@gmail.com> wrote:
> everything about portage is very specific and should be separated, I
> would like to see an addition of one root directory "gentoo" where
> ${PKGMANAGER} keep all it's stuff.

Doesn't really fit in nicely with the build directory being arbitrarily
removable, caches like distdir being removable if you need space, repos
like gentoo-x86 being not really removable and repos like vdb being
totally not removable at all.

There's a reason Unix has /usr, /var etc, not /Applications/Blah/ .

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?

[Zac Medico]

On 08/01/2011 07:10 AM, Samuli Suominen wrote:
> * Jorge Manuel B. S. Vicetto schrieb am 01.08.11 um 11:19 Uhr:
>> I agree with Eray. Furthermore, please stop trying to reverse "the
>> game". It's those that want to break existing policies and conventions
>> that have to justify why they want to do that, not those that want to
>> keep using what has worked for years.
> 
> I wouldn't call the current static -workarounds, and files from / using
> files from /usr, neither a clean solution or working
> 
> The separation is unnecessary maintaince burden for something that has
> maintaince free replacement

Right. The root problem at the core of this whole discussion is that
separating / and /usr is really a dependency satisfaction problem that
requires maintenance.

It seems absurd to manage this kind of dependency problem by hand when
we can use the package manager to do it. For example, we could have
packages that install into / set something like
PROPERTIES="available-when-init-starts" (of course we'd use a shorter
name), and the package manager would then be able to trigger a QA
warning if one of these packages depends on a package that does not have
PROPERTIES="available-when-init-starts" set.
-- 
Thanks,
Zac

Re: [gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?

[Brian Harring]

On Mon, Aug 01, 2011 at 12:55:02PM -0700, Zac Medico wrote:
> On 08/01/2011 07:10 AM, Samuli Suominen wrote:
> > * Jorge Manuel B. S. Vicetto schrieb am 01.08.11 um 11:19 Uhr:
> >> I agree with Eray. Furthermore, please stop trying to reverse "the
> >> game". It's those that want to break existing policies and conventions
> >> that have to justify why they want to do that, not those that want to
> >> keep using what has worked for years.
> > 
> > I wouldn't call the current static -workarounds, and files from / using
> > files from /usr, neither a clean solution or working
> > 
> > The separation is unnecessary maintaince burden for something that has
> > maintaince free replacement
> 
> Right. The root problem at the core of this whole discussion is that
> separating / and /usr is really a dependency satisfaction problem that
> requires maintenance.
> 
> It seems absurd to manage this kind of dependency problem by hand when
> we can use the package manager to do it. For example, we could have
> packages that install into / set something like
> PROPERTIES="available-when-init-starts" (of course we'd use a shorter
> name), and the package manager would then be able to trigger a QA
> warning if one of these packages depends on a package that does not have
> PROPERTIES="available-when-init-starts" set.

RESTRICT=limit-to-init is a bit more inline w/ our norms.

Easy enough set of checks to add either way.
~brian

Re: [gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?

[Michał Górny]

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

On Sat, 30 Jul 2011 16:28:54 +0200
Chí-Thanh Christopher Nguyễn <chithanh@gentoo.org> wrote:

> Samuli Suominen schrieb:
> > 
> > Someone mentioned NFS mount on /usr.  Do we have other reasons?  How
> > many users that might be?
> 
> If you have / encrypted, then you can leave /usr unencrypted as it
> contains no secrets. Also /usr can remain mounted read-only most of
> the time, so there is a reduced chance of accidental corruption.
> I don't know the number of users who might want this, and I imagine it
> is difficult to count them.

BTW doesn't encrypting rootfs require initramfs anyway?

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?

[Rich Freeman]

On Tue, Aug 2, 2011 at 4:02 AM, Michał Górny <mgorny@gentoo.org> wrote:
> BTW doesn't encrypting rootfs require initramfs anyway?
>

Yup.

On a side note.  I've been experimenting with Dracut+LVM+RAID5 and
have found that it actually works pretty transparently.  Now, I
haven't tried it with /usr not on the rootfs - I can tell that Dracut
is definitely parsing my /etc/fstab to mount my root, but I'm not sure
if it tries to mount anything else by default.  It is fairly slick -
it mounts root any way it can read-only to get to the fstab, and then
remounts it following the options in fstab.  (Which means that you
need to make sure fstab is accurate since it actually gets used for
the rootfs now.)

I also found that the dracut initramfs is MUCH faster than the
genkernel one - it does a good job of only loading drivers necessary
to find the root, and it can take hints to speed that up.  It also
required less configuration - the only required kernel parameter even
for mdadm+lvm is root= (which takes device, UUID, or label).

I got it working with an old-metadata /boot (probably need to mess
with grub v2 to avoid that, assuming that even works), and then
everything else including root on mdadm-raid5+LVM.

So, my feeling is that while we should support minimal (ie
non-gnome/etc) configurations that follow FHS and don't require an
initramfs, I don't really see leveraging dracut as a big problem as
long as we update our documentation to make the preferred approach
clear.

Everybody should also read that Fedora link earlier in the thread:
http://fedoraproject.org/wiki/Features/UsrMove

I'm not suggesting that we should do this, but this does seem like a
legitimate use-case.  It is a bit more suited to binary distros with
release cycles, but I could see in a datacenter how it might be nice
to NFS-mount just about everything including /usr, /bin, /lib, etc.
Such a setup would actually be pretty easy to accomplish with Gentoo -
in theory you can just create symlinks for the various root
directories into /usr and let the package manager install the files
into them.  In practice it might run into issues (I know that symlinks
for some of the top-level directories were not liked by some of the
package managers in the past - I had to use bind mounts to accomplish
this, and that might be a better solution though I have no idea if
Dracut can figure that out in fstab).

Rich

Re: [gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?

[Michał Górny]

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

On Sat, 30 Jul 2011 10:27:27 +0300
Samuli Suominen <ssuominen@gentoo.org> wrote:

> Since running separate /usr without mounting it from initramfs on top
> of / before init is and has been broken with udev for a long time
> now[1][2][3]
> 
> [1] http://bugs.gentoo.org/show_bug.cgi?id=364235
> [2] http://fedoraproject.org/wiki/Features/UsrMove#Move_all_to_.2Fusr
> [3]
> http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken
> 
> Can we warn users about not doing the separate /usr mistake in the
> handbook?

So, let's sum up a little.

The most common argument against separate /usr requiring a proper
initramfs is 'it works now, thus it's great'. That is practically
understandable that people don't like to switch things upside down like
that, especially when machines are not locally reachable.

What's the exact differences between an initramfs and an early bootup
setup in rootfs? As I see it:
- initramfs is a small fs which is used for a short while on boot, to
  setup the system necessarily for the early bootup sequence,
- while initial rootfs is a rather large piece of fs which is supposed
  to contain random stuff necessary for the early bootup to be able to
  proceed and mount the necessary remaining stuff before the actual
  bootup begins. And we're mostly stuck with it for the whole runtime.

As I see it, I see no reason to keep forcing things like complete glibc,
ncurses and the whole other lot of libraries for the early bootup if
all needed is some kind of minimal 'mount' program (for instance).

In the ol' days I tried building a NFS-shared system and the main
problem was that some of early run tools relied heavily on the local
system libs and files before they were replaced by NFS mounts. And I
had to keep them in sync manually which is not the most comfortable
thing.

I don't see how trying to fit the best set of libs and files into
rootfs can solve it. You either want for the system to be clean or
weirdly split to support various possible configurations. And decide
which are not 'weird enough' not to support.

And really, most of the things about separate /usr are hacks which were
introduced because the system was incapable of a proper rootfs.
Read-only /usr should be read-only rootfs with writable mounts on top
of it. NFS-mounted /usr should be the whole system part network-mounted
(which would be easier if everything went into /usr rather than being
split).

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?

[Samuli Suominen]

On 08/04/2011 05:30 AM, Michał Górny wrote:
> On Sat, 30 Jul 2011 10:27:27 +0300
> Samuli Suominen <ssuominen@gentoo.org> wrote:
> 
>> Since running separate /usr without mounting it from initramfs on top
>> of / before init is and has been broken with udev for a long time
>> now[1][2][3]
>>
>> [1] http://bugs.gentoo.org/show_bug.cgi?id=364235
>> [2] http://fedoraproject.org/wiki/Features/UsrMove#Move_all_to_.2Fusr
>> [3]
>> http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken
>>
>> Can we warn users about not doing the separate /usr mistake in the
>> handbook?
> 
> So, let's sum up a little.
> 
> The most common argument against separate /usr requiring a proper
> initramfs is 'it works now, thus it's great'. That is practically
> understandable that people don't like to switch things upside down like
> that, especially when machines are not locally reachable.
> 
> What's the exact differences between an initramfs and an early bootup
> setup in rootfs? As I see it:
> - initramfs is a small fs which is used for a short while on boot, to
>   setup the system necessarily for the early bootup sequence,
> - while initial rootfs is a rather large piece of fs which is supposed
>   to contain random stuff necessary for the early bootup to be able to
>   proceed and mount the necessary remaining stuff before the actual
>   bootup begins. And we're mostly stuck with it for the whole runtime.
> 
> As I see it, I see no reason to keep forcing things like complete glibc,
> ncurses and the whole other lot of libraries for the early bootup if
> all needed is some kind of minimal 'mount' program (for instance).
> 
> In the ol' days I tried building a NFS-shared system and the main
> problem was that some of early run tools relied heavily on the local
> system libs and files before they were replaced by NFS mounts. And I
> had to keep them in sync manually which is not the most comfortable
> thing.
> 
> I don't see how trying to fit the best set of libs and files into
> rootfs can solve it. You either want for the system to be clean or
> weirdly split to support various possible configurations. And decide
> which are not 'weird enough' not to support.
> 
> And really, most of the things about separate /usr are hacks which were
> introduced because the system was incapable of a proper rootfs.
> Read-only /usr should be read-only rootfs with writable mounts on top
> of it. NFS-mounted /usr should be the whole system part network-mounted
> (which would be easier if everything went into /usr rather than being
> split).
> 

It seems what we need is an migration plan.   Sending out a Portage News
item, and correcting documentation as first step.

Then giving people enough time to migrate. This would give us plenty of
time to work on the details for moving the files over from / to /usr.

It seems non-problematic for new installs, as stages could ship the
symlinks and files get installed to /usr through them, even before the
packages are changed.

Re: [gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?

[Jorge Manuel B. S. Vicetto]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 04-08-2011 07:55, Samuli Suominen wrote:
> On 08/04/2011 05:30 AM, Michał Górny wrote:
>> On Sat, 30 Jul 2011 10:27:27 +0300
<snip>
>> So, let's sum up a little.
>> 
>> The most common argument against separate /usr requiring a proper 
>> initramfs is 'it works now, thus it's great'. That is practically 
>> understandable that people don't like to switch things upside down
>> like that, especially when machines are not locally reachable.
>> 
>> What's the exact differences between an initramfs and an early
>> bootup setup in rootfs? As I see it: - initramfs is a small fs
>> which is used for a short while on boot, to setup the system
>> necessarily for the early bootup sequence, - while initial rootfs
>> is a rather large piece of fs which is supposed to contain random
>> stuff necessary for the early bootup to be able to proceed and
>> mount the necessary remaining stuff before the actual bootup
>> begins. And we're mostly stuck with it for the whole runtime.
>> 
>> As I see it, I see no reason to keep forcing things like complete
>> glibc, ncurses and the whole other lot of libraries for the early
>> bootup if all needed is some kind of minimal 'mount' program (for
>> instance).
>> 
>> In the ol' days I tried building a NFS-shared system and the main 
>> problem was that some of early run tools relied heavily on the
>> local system libs and files before they were replaced by NFS
>> mounts. And I had to keep them in sync manually which is not the
>> most comfortable thing.
>> 
>> I don't see how trying to fit the best set of libs and files into 
>> rootfs can solve it. You either want for the system to be clean or 
>> weirdly split to support various possible configurations. And
>> decide which are not 'weird enough' not to support.
>> 
>> And really, most of the things about separate /usr are hacks which
>> were introduced because the system was incapable of a proper
>> rootfs. Read-only /usr should be read-only rootfs with writable
>> mounts on top of it. NFS-mounted /usr should be the whole system
>> part network-mounted (which would be easier if everything went into
>> /usr rather than being split).

> It seems what we need is an migration plan.   Sending out a Portage
> News item, and correcting documentation as first step.
> 
> Then giving people enough time to migrate. This would give us plenty
> of time to work on the details for moving the files over from / to
> /usr.

Again, not all of us are willing to migrate away from a separate /usr
partition, least of all when that is being "imposed" by some people
trying to "shove" their pet projects to others and when we don't agree
with or acknowledge the arguments.

> It seems non-problematic for new installs, as stages could ship the 
> symlinks and files get installed to /usr through them, even before
> the packages are changed.

The symlinks will have to be part of baselayout as files get into stages
through packages and not through catalyst.

- -- 
Regards,

Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJOOn/LAAoJEC8ZTXQF1qEPOQsP+we6tifTVnCXqr46ajXa2Xft
NqXhJfxmONGbbhfDYPhoNiGK5ovojpoDncKEE0t158X35QfLRjqFqrudbPDUNzrh
/zEJmQYacZckyMT866PE2iJBovEA5ZBnXB8y6RBHJLH3ky5/dO8R92jHSnNihi1y
u639+dpRHP6cRQIk9i2sEHaph+bZo6e3X+GCT6FL63m4sNDSBfJGo4wtMewp/aDD
HS2Ya41WAt+SYA131QLcVwLhyDz7sRdQm1iR7W06iScMxgE/mKHF9S25NKMYf+H+
Qtd+PF1SLcxC1lKztPsmNTr1lpDLlAoO5OQzpOnXoPmCWvuzBVyrHfSPo+cxQOFM
6VA0mjdNODS4gbEL5Fu8Q/Asf3/byJ7gBOfLNuHkMksMfLSy/O0KXjx3fnmpj1a0
yXlt+iuer7z5rwuz7ZfXNCmw0DWzuMOUimz1jz0pUwTzXDD9zZJXKHOt/RR4oQb8
NLldmh8YBcl17r6l60H49GWyL8YiIhQetBZuNi9+Pm72o3vVsKmCnyXHP1Cf0CsQ
ziVy4+Lub2qSSQfndrTHnJ6rDIDFSLT4iZYRDJmlf6Mhrk7abogze/s0Vgfkfrfl
yJVNVPG3Evk4d1qIFROSmQhhu44EOkufhijYvytpCHeNLvWUupeaMZOchX6QUXp4
4FhE/udxLI1zpQtTHLbJ
=DhRY
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?

[Dale]

Jorge Manuel B. S. Vicetto wrote:
>
> Again, not all of us are willing to migrate away from a separate /usr
> partition, least of all when that is being "imposed" by some people
> trying to "shove" their pet projects to others and when we don't agree
> with or acknowledge the arguments.
>
>    

+1

 From a users perspective.  Could it not be possible to have some USE 
flag, or other setting, that would tell portage that a separate /usr 
partition is being used then have the needed files placed elsewhere on / 
?  I'm not a dev and I don't play one on TV but I do like options and 
being able to customize some things.  It is one of the things Gentoo is 
about.

I find it sort of ironic that I was planning to redo my partitions and 
have a separate /usr and now finding out that it is basically no longer 
a option on Gentoo.  At least I am reading this now instead of 
afterwards.  No, initramfs is not something I want to have to deal with 
either.

Dale

:-)  :-)

Re: [gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?

[Rich Freeman]

On Thu, Aug 4, 2011 at 7:49 AM, Dale <rdalek1967@gmail.com> wrote:
> From a users perspective.  Could it not be possible to have some USE flag,
> or other setting, that would tell portage that a separate /usr partition is
> being used then have the needed files placed elsewhere on / ?  I'm not a dev
> and I don't play one on TV but I do like options and being able to customize
> some things.  It is one of the things Gentoo is about.
>

I don't see what a USE flag gets us:

1.  If you have a separate /usr then either booting without an
initramfs will work or it won't work - largely depending on how
complex your environment is.  Booting with an initramfs will work
reliably (well, if we sort out the initramfs situation - having done
some more tests I have one virtual machine which was pretty easy to
get running, and one physical box that for whatever reason wouldn't
detect/start the RAID).

2.  If you don't have a separate /usr than booting will always work
regardless of where the files are, since the system will always find
them.

Unless what is being proposed is to actually do the Fedora thing and
make /bin, /lib, etc a symlink into /usr/bin, /usr/lib, etc than there
isn't anything at package-install time for the flag to affect.  If we
do want to do the Fedora thing would a flag even work, since those
directories get created from the stage3?  It seems to me that if you
want the symlinks you just need to set them up when doing the install
(or from a rescue disk), and then the package manager should follow
the links when doing subsequent installs.  Oh, and not all package
managers like the top-level directories to be symlinks.

I think that as was the case with the use of bash vs sh we may need to
have a policy decision made here.  Right now the general policy has
been to conform to FHS, and the Fedora/etc proposal does not do this
(and apparently we are already a bit out of compliance).  I think that
moving in a different direction is a big decision.

And, if we do decide to move in that direction, I agree with Samuli
that we need a transition plan.  Packages can't just start breaking
initrd-less setups left and right overnight.  To start, we need to get
dracut/etc configurable to mount any necessary directories (I checked
- it is fairly smart (though not 100% effective) at finding root, but
does not try to mount anything else).  Then we need to update our
documentation.  Then we need to communicate the change to users, and
give them time to migrate.  Only then can packages have the freedom to
require usr to be available at boot.

I don't propose that if we move in this direction that we "fix"
anything that isn't currently FHS-compliant - the damage is already
done.  We just should avoid propagating the situation until users are
ready.

Rich

Re: [gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?

[William Hubbs]

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

On Thu, Aug 04, 2011 at 06:49:36AM -0500, Dale wrote:
> Jorge Manuel B. S. Vicetto wrote:
> >
> > Again, not all of us are willing to migrate away from a separate /usr
> > partition, least of all when that is being "imposed" by some people
> > trying to "shove" their pet projects to others and when we don't agree
> > with or acknowledge the arguments.
> >
> >    
> 
> +1

Add another to the list of folks who disagree with this and with the
approach being taken.

I don't blame gentoo devs per se, but I do feel like this is being
forced down everyone's throats without any regard to the *nix philosophy
of having separate /usr which has worked for years, and if people would
fix their bugs correctly would continue to work.

William


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

Re: [gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?

[David Abbott]

Looks like the Linux Foundation has a;
<quote>
Call for Participation

The LSB workgroup is preparing FHS 3.0, which will be the first FHS
release since 2004. As part of that release, we are soliciting
contributions from all interested parties.
</quote>

http://www.linuxfoundation.org/collaborate/workgroups/lsb/fhs

-- 
David Abbott (dabbott)
Gentoo
http://dev.gentoo.org/~dabbott/

Re: [gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?

[Sven Vermeulen]

On Thu, Aug 04, 2011 at 09:31:07AM -0500, William Hubbs wrote:
> Add another to the list of folks who disagree with this and with the
> approach being taken.
> 
> I don't blame gentoo devs per se, but I do feel like this is being
> forced down everyone's throats without any regard to the *nix philosophy
> of having separate /usr which has worked for years, and if people would
> fix their bugs correctly would continue to work.

Same here. I do consider the situation to be a bug and, even if the damage
is already done, it doesn't mean we should help with debolishing what is
left.

If anything, we should make it clear to users when and why an initramfs is
needed. Saying "because you have a /usr on a separate file system" is not
only a lie, it also covers the truth beneath it. Rather, why not identify in
which situation(s) you will need an initramfs and work from there?

I personally have /usr on a separate partition too (using LVM) without an
initramfs or initrd. Works just fine. And I'd like to keep it that way,
since it is simple and very manageable.

Wkr,
	Sven Vermeulen

Re: [gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?

[Rich Freeman]

On Thu, Aug 4, 2011 at 10:42 AM, David Abbott <dabbott@gentoo.org> wrote:
> The LSB workgroup is preparing FHS 3.0, which will be the first FHS
> release since 2004. As part of that release, we are soliciting
> contributions from all interested parties.

More interesting was this thread on their mailing list:
https://lists.linux-foundation.org/pipermail/fhs-discuss/2011-July/000326.html

There was no further reply - so unless this is isolated thinking the
intent of FHS is not to dictate what is available during boot.  Oh,
and that anybody not using initramfs is a nutcase or something...  :)

Rich

Re: [gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?

[Greg KH]

On Thu, Aug 04, 2011 at 09:31:07AM -0500, William Hubbs wrote:
> On Thu, Aug 04, 2011 at 06:49:36AM -0500, Dale wrote:
> > Jorge Manuel B. S. Vicetto wrote:
> > >
> > > Again, not all of us are willing to migrate away from a separate /usr
> > > partition, least of all when that is being "imposed" by some people
> > > trying to "shove" their pet projects to others and when we don't agree
> > > with or acknowledge the arguments.
> > >
> > >    
> > 
> > +1
> 
> Add another to the list of folks who disagree with this and with the
> approach being taken.
> 
> I don't blame gentoo devs per se, but I do feel like this is being
> forced down everyone's throats without any regard to the *nix philosophy
> of having separate /usr which has worked for years, and if people would
> fix their bugs correctly would continue to work.

The problem is that it really _hasn't_ worked for years, you just never
saw the problem.

And that's fine, but when things start randomly breaking in the future,
if you persist in this type of setup, then you at least will know who to
blame :)

Also, again, this is an upstream issue, based on the packages you have
installed, not anything that has changed in the distro itself.  Upstream
is also working to resolve the issue already, by mounting /usr from the
initramfs, to keep this sane, so people shouldn't really have to worry
about this too much, unless they don't use an initramfs...

good luck,

greg k-h

Re: [gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?

[Rich Freeman]

On Thu, Aug 4, 2011 at 11:46 AM, Greg KH <gregkh@gentoo.org> wrote:
> Also, again, this is an upstream issue, based on the packages you have
> installed, not anything that has changed in the distro itself.  Upstream
> is also working to resolve the issue already, by mounting /usr from the
> initramfs, to keep this sane, so people shouldn't really have to worry
> about this too much, unless they don't use an initramfs...

Agree.  The news was a little shocking to me actually - I had no idea
people were doing this.  I suspect it just happened as things like
udev went from enhancements used when you inserted something in a
pcmcia slot to core features used to get everything from your hard
drive to your mouse to work.

The more I think about it, the more it seems like we're stuck going
the initramfs route unless we want to become Gentoo vs the world.
Dropping support for udev clearly isn't going to be a practical
option, and the number of changes we'd have to make to get it and its
dependencies out of /usr is going to be a challenge.

I suspect that in the end we're either going to end up requiring
initramfs, or we're going to end up implementing what is otherwise in
dracut in openrc to get those drives mounted much earlier.

Gentoo is a bit unusual in not requiring initramfs in the first place.
 We can get away it mostly because everybody customizes their
kernels/grub/etc anyway.  If you're a binary distro and want a one
bzImage/grub.conf fits all then you need a fancy initramfs to make it
work.

Rich

[gentoo-dev] /usr vs. initramfs redux

[Robin H. Johnson]

I've mainly said out of this discussion until now, because I've been
quite busy.

The root problem here is that there are starting to be a lot of cases
where rule run by udev require that /usr [1] and potentially /var [2] or
more are available when the udev rule runs.

To the best of my knowledge, udev has no way of knowing that the
relevant directory structures might not yet be available.

Moving the binaries out of /usr into / is a band-aid at best, and
potentially a giant nightmare because we have to trace down every binary
run by every rule. Then data-files also need to be considered.

There are only two solutions available, one of which has two variants.
1. Allow udev to delay running a rule until the volumes are available.
2. Ensure /usr and /var are available when udev starts, two possible
   ways:
2.1. Merge /usr and /var to /.
2.2. Initramfs to mount them.

Gregkh et al can speak to #1, and I think they will concur with me that
it's not a reasonable change to put in udev (it belongs in whatever is
starting the services and mounting those directory structures).

That leaves the only reasonable solution as #2. In terms of minimal
impact, I propose that we offer users with a static system an absolutely
minimal initramfs, that _just_ mounts the required directories. No
modules, no LVM, no MD, no crypto etc - if you want that functionality,
go and use genkernel or dracut. If your fstab contains a line like:
/dev/sdXN /usr ...
Then this initramfs is for you.

The minimal initramfs would do the following.

1. Mount devtmpfs/sysfs/procfs as needed to access devices.
2. Mount real_root to /newroot
3. Read /newroot/etc/initramfs.mount and /newroot/etc/fstab
4.1. If /newroot/etc/initramfs.mount does not exist
     Assume it contains only: /usr /var
5. Mount the combined items from said files
6. pivot_root.

This initramfs explicitly needs to be rebuilt extremely seldom, because
it reads everything from the real root. (Having the debug interface like
genkernel initramfs would be nice in case the user breaks their fstab,
but isn't required).

There's a couple of other tweaks/improvements that might be useful, like
supporting UUIDs and LABELs for devices.

[1]:
Besides the binaries run from /usr, I've seen broken rules because they
failed USB/PCI identification, because /usr/share/misc/pci.ids and
/usr/share/misc/usb.ids were on /usr.

[2]:
These are the ones on my desktop that reference /var:
app-admin/system-config-printer-common: /lib/udev/udev-configure-printer
sys-fs/udev: /lib/udev/udev-acl
sci-geosciences/gpsd: /lib/udev/gpsd.hotplug
/lib/udev/rules.d/90-alsa-restore.rules: 
- alsactl restore needs /var/lib/alsa/asound.state




On Thu, Aug 04, 2011 at 12:00:09PM -0400, Rich Freeman wrote:
> On Thu, Aug 4, 2011 at 11:46 AM, Greg KH <gregkh@gentoo.org> wrote:
> > Also, again, this is an upstream issue, based on the packages you have
> > installed, not anything that has changed in the distro itself.  Upstream
> > is also working to resolve the issue already, by mounting /usr from the
> > initramfs, to keep this sane, so people shouldn't really have to worry
> > about this too much, unless they don't use an initramfs...
> 
> Agree.  The news was a little shocking to me actually - I had no idea
> people were doing this.  I suspect it just happened as things like
> udev went from enhancements used when you inserted something in a
> pcmcia slot to core features used to get everything from your hard
> drive to your mouse to work.
> 
> The more I think about it, the more it seems like we're stuck going
> the initramfs route unless we want to become Gentoo vs the world.
> Dropping support for udev clearly isn't going to be a practical
> option, and the number of changes we'd have to make to get it and its
> dependencies out of /usr is going to be a challenge.
> 
> I suspect that in the end we're either going to end up requiring
> initramfs, or we're going to end up implementing what is otherwise in
> dracut in openrc to get those drives mounted much earlier.
> 
> Gentoo is a bit unusual in not requiring initramfs in the first place.
>  We can get away it mostly because everybody customizes their
> kernels/grub/etc anyway.  If you're a binary distro and want a one
> bzImage/grub.conf fits all then you need a fancy initramfs to make it
> work.
> 
> Rich
> 

-- 
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] /usr vs. initramfs redux

[Marc Schiffbauer]

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

* Robin H. Johnson schrieb am 05.08.11 um 02:46 Uhr:
[...]
> That leaves the only reasonable solution as #2. In terms of minimal
> impact, I propose that we offer users with a static system an absolutely
> minimal initramfs, that _just_ mounts the required directories.  No
> modules, no LVM, no MD, no crypto etc - if you want that functionality,
> go and use genkernel or dracut. If your fstab contains a line like:
> /dev/sdXN /usr ...
> Then this initramfs is for you.
> 
> The minimal initramfs would do the following.
> 
> 1. Mount devtmpfs/sysfs/procfs as needed to access devices.
> 2. Mount real_root to /newroot
> 3. Read /newroot/etc/initramfs.mount and /newroot/etc/fstab
> 4.1. If /newroot/etc/initramfs.mount does not exist
>      Assume it contains only: /usr /var
> 5. Mount the combined items from said files
> 6. pivot_root.
> 

That sounds like a good compromise to me!

Another thing to consider:

/etc/init.d/localmount should check whats already mounted and leave
that out. But it will act as fallback if the minimal initramfs fails
to mount /usr or /var for any reason.

That way anybody migrating to that "minitramfs" will not risc an
unbootable system.

-Marc
-- 
8AAC 5F46 83B4 DB70 8317  3723 296C 6CCA 35A6 4134

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

Re: [gentoo-dev] /usr vs. initramfs redux

[Rich Freeman]

On Fri, Aug 5, 2011 at 6:16 AM, Marc Schiffbauer <mschiff@gentoo.org> wrote:
> * Robin H. Johnson schrieb am 05.08.11 um 02:46 Uhr:
> [...]
>> That leaves the only reasonable solution as #2. In terms of minimal
>> impact, I propose that we offer users with a static system an absolutely
>> minimal initramfs, that _just_ mounts the required directories.  No
>> modules, no LVM, no MD, no crypto etc - if you want that functionality,
>> go and use genkernel or dracut. If your fstab contains a line like:
>> /dev/sdXN /usr ...
>> Then this initramfs is for you.
>>
>> The minimal initramfs would do the following.
>>
>> 1. Mount devtmpfs/sysfs/procfs as needed to access devices.
>> 2. Mount real_root to /newroot
>> 3. Read /newroot/etc/initramfs.mount and /newroot/etc/fstab
>> 4.1. If /newroot/etc/initramfs.mount does not exist
>>      Assume it contains only: /usr /var
>> 5. Mount the combined items from said files
>> 6. pivot_root.
>>
>
> That sounds like a good compromise to me!

Why would we build yet another initramfs vs just making dracut work
reliably?  You can already build dracut without support for
lvm+raid+luks/etc.

If we're going to require an initramfs then we should make sure that
ALL gentoo-provided solutions work before we expand the need for a
mounted /usr.  The genkernel team already mentioned that they plan to
switch to dracut, so we really just need to get dracut working
properly.

That said, nobody is preventing anybody from re-inventing the wheel if
they wish to do so.  I just wouldn't just offer it up as an example of
a perfectly acceptable migration strategy, when we've had a lvm+raid
howto for years that wouldn't be compatible with it.

Rich

Re: [gentoo-dev] /usr vs. initramfs redux

[Marc Schiffbauer]

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

* Rich Freeman schrieb am 05.08.11 um 14:42 Uhr:
> On Fri, Aug 5, 2011 at 6:16 AM, Marc Schiffbauer <mschiff@gentoo.org> wrote:
> > * Robin H. Johnson schrieb am 05.08.11 um 02:46 Uhr:
> > [...]
> >> That leaves the only reasonable solution as #2. In terms of minimal
> >> impact, I propose that we offer users with a static system an absolutely
> >> minimal initramfs, that _just_ mounts the required directories.  No
> >> modules, no LVM, no MD, no crypto etc - if you want that functionality,
> >> go and use genkernel or dracut. If your fstab contains a line like:
> >> /dev/sdXN /usr ...
> >> Then this initramfs is for you.
> >>
> >> The minimal initramfs would do the following.
> >>
> >> 1. Mount devtmpfs/sysfs/procfs as needed to access devices.
> >> 2. Mount real_root to /newroot
> >> 3. Read /newroot/etc/initramfs.mount and /newroot/etc/fstab
> >> 4.1. If /newroot/etc/initramfs.mount does not exist
> >>      Assume it contains only: /usr /var
> >> 5. Mount the combined items from said files
> >> 6. pivot_root.
> >>
> >
> > That sounds like a good compromise to me!
> 
> Why would we build yet another initramfs vs just making dracut work
> reliably?  You can already build dracut without support for
> lvm+raid+luks/etc.

If dracut will have some sort of minimalistic mode where it would
generate such an initrd that would be ok IMO.

OTOH the initrd that Robin described would be a very static solution
with almost no dependencies, so if genkernel had a USE flag like
"dracut" it would be possible to build it without dracut
dependency and thus would allow for smaller systems.

-Marc
-- 
8AAC 5F46 83B4 DB70 8317  3723 296C 6CCA 35A6 4134

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

Re: [gentoo-dev] /usr vs. initramfs redux

[Matthew Summers]

On Fri, Aug 5, 2011 at 7:42 AM, Rich Freeman <rich0@gentoo.org> wrote:
> On Fri, Aug 5, 2011 at 6:16 AM, Marc Schiffbauer <mschiff@gentoo.org> wrote:
>> * Robin H. Johnson schrieb am 05.08.11 um 02:46 Uhr:
>> [...]
>>> That leaves the only reasonable solution as #2. In terms of minimal
>>> impact, I propose that we offer users with a static system an absolutely
>>> minimal initramfs, that _just_ mounts the required directories.  No
>>> modules, no LVM, no MD, no crypto etc - if you want that functionality,
>>> go and use genkernel or dracut. If your fstab contains a line like:
>>> /dev/sdXN /usr ...
>>> Then this initramfs is for you.
>>>
>>> The minimal initramfs would do the following.
>>>
>>> 1. Mount devtmpfs/sysfs/procfs as needed to access devices.
>>> 2. Mount real_root to /newroot
>>> 3. Read /newroot/etc/initramfs.mount and /newroot/etc/fstab
>>> 4.1. If /newroot/etc/initramfs.mount does not exist
>>>      Assume it contains only: /usr /var
>>> 5. Mount the combined items from said files
>>> 6. pivot_root.
>>>
>>
>> That sounds like a good compromise to me!
>
> Why would we build yet another initramfs vs just making dracut work
> reliably?  You can already build dracut without support for
> lvm+raid+luks/etc.
>
> If we're going to require an initramfs then we should make sure that
> ALL gentoo-provided solutions work before we expand the need for a
> mounted /usr.  The genkernel team already mentioned that they plan to
> switch to dracut, so we really just need to get dracut working
> properly.
>
> That said, nobody is preventing anybody from re-inventing the wheel if
> they wish to do so.  I just wouldn't just offer it up as an example of
> a perfectly acceptable migration strategy, when we've had a lvm+raid
> howto for years that wouldn't be compatible with it.
>
> Rich
>
>

In point of fact all modern Linux kernels have an initramfs built in
now, that when empty is effectively bypassed, so there is no wheel
reinvention. To quote the docs [1]
"
All 2.6 Linux kernels contain a gzipped "cpio" format archive, which is
extracted into rootfs when the kernel boots up.  After extracting, the kernel
checks to see if rootfs contains a file "init", and if so it executes it as PID
1.  If found, this init process is responsible for bringing the system the
rest of the way up, including locating and mounting the real root device (if
any).  If rootfs does not contain an init program after the embedded cpio
archive is extracted into it, the kernel will fall through to the older code
to locate and mount a root partition, then exec some variant of /sbin/init
out of that.
"
[1] /usr/src/linux/Documentation/filesystems/ramfs-rootfs-initramfs.txt

While dracut may help with the process of creating the initramfs, its
really not a terribly complicated endeavor, and from further reading
(specifically as related to the desired removal of md autodetection),
it is the full intention of the kernel upstream that initramfs be the
new path forward in handling things such as separate /usr, raid
volumes, and so on. Further, dracut will introduce yet another dep in
base-system (I am guessing here), that is not more than perhaps a
convenience. I note here, that I have not used dracut as the well
documented method of creating an initramfs is straight forward enough
that I did not require anything too fancy to handle mounting raid1
volumes, and providing a recovery environment with networking and ssh.

This, at least to me, seems like an excellent opportunity to nicely
document what can be done with an initramfs (in basic and advanced
forms, as there are some really fancy things one can do with
initramfs's), and how Gentoo is recommending their usage in the cases
outlined by Robin and others.

So, I am +1 on robbat2's solution and -1 on dracut. That said, I am
fully willing to alter my position when presented with a better
argument. Lastly, I do have a few minor concerns about how this
"default" initramfs will be dealt with, however those can wait.
Mainly, I simply desire the flexibility to replace the Gentoo-shipped
version with a custom version easily.

Thanks and kind regards,
Matt

-- 
Matthew W. Summers
Gentoo Foundation Inc.

Re: [gentoo-dev] /usr vs. initramfs redux

[Samuli Suominen]

On 08/05/2011 04:12 PM, Marc Schiffbauer wrote:
> * Rich Freeman schrieb am 05.08.11 um 14:42 Uhr:
>> On Fri, Aug 5, 2011 at 6:16 AM, Marc Schiffbauer <mschiff@gentoo.org> wrote:
>>> * Robin H. Johnson schrieb am 05.08.11 um 02:46 Uhr:
>>> [...]
>>>> That leaves the only reasonable solution as #2. In terms of minimal
>>>> impact, I propose that we offer users with a static system an absolutely
>>>> minimal initramfs, that _just_ mounts the required directories.  No
>>>> modules, no LVM, no MD, no crypto etc - if you want that functionality,
>>>> go and use genkernel or dracut. If your fstab contains a line like:
>>>> /dev/sdXN /usr ...
>>>> Then this initramfs is for you.
>>>>
>>>> The minimal initramfs would do the following.
>>>>
>>>> 1. Mount devtmpfs/sysfs/procfs as needed to access devices.
>>>> 2. Mount real_root to /newroot
>>>> 3. Read /newroot/etc/initramfs.mount and /newroot/etc/fstab
>>>> 4.1. If /newroot/etc/initramfs.mount does not exist
>>>>      Assume it contains only: /usr /var
>>>> 5. Mount the combined items from said files
>>>> 6. pivot_root.
>>>>
>>>
>>> That sounds like a good compromise to me!
>>
>> Why would we build yet another initramfs vs just making dracut work
>> reliably?  You can already build dracut without support for
>> lvm+raid+luks/etc.
> 
> If dracut will have some sort of minimalistic mode where it would
> generate such an initrd that would be ok IMO.
> 
> OTOH the initrd that Robin described would be a very static solution
> with almost no dependencies, so if genkernel had a USE flag like
> "dracut" it would be possible to build it without dracut
> dependency and thus would allow for smaller systems.
> 
> -Marc

To clarify,

By dependencies in dracut you mean udev? And by smaller systems you mean
systems without udev?

Then yes, such minimal initramfs should propably be covered in the
embedded's documentation, but otherwise trying to avoid dracut is
reinventing the wheel...

Re: [gentoo-dev] /usr vs. initramfs redux

[Rich Freeman]

On Fri, Aug 5, 2011 at 9:25 AM, Matthew Summers
<quantumsummers@gentoo.org> wrote:
> In point of fact all modern Linux kernels have an initramfs built in
> now, that when empty is effectively bypassed, so there is no wheel
> reinvention. To quote the docs [1]

Yes, but that embedded initramfs doesn't actually do much of anything
right now.  It may exist from an architecture standpoint, but it
doesn't mean that there isn't a lot of work to be done which would be
redundant with work already done elsewhere.

I can see where you might want a simpler solution than dracut as an
alternative for more embedded setups/etc.  It probably would be
cleaner to just create a new solution than modify dracut to get rid of
udev/etc.

In any case, as long as a solution exists for md+lvm+luks+/usr before
we start breaking more stuff than is already broken, then we should be
fine.  Having more than one optional solution is fine.  While I don't
think that gentoo needs to be another Ubuntu, having reasonable
out-of-the-box support for one of the major desktop environments
running on md+lvm+luks seems pretty useful.

Rich

Re: [gentoo-dev] /usr vs. initramfs redux

[Sven Vermeulen]

On Fri, Aug 05, 2011 at 08:25:19AM -0500, Matthew Summers wrote:
> This, at least to me, seems like an excellent opportunity to nicely
> document what can be done with an initramfs (in basic and advanced
> forms, as there are some really fancy things one can do with
> initramfs's), and how Gentoo is recommending their usage in the cases
> outlined by Robin and others.

I'm all in favor of documenting what an initramfs does (or at least what it
is supposed to do), how it works, how to create one, how to debug issues
while booting with one, etc.

That said, I'm a bit hesitant to describing that we "recommend" it
regardless of the situation. What is wrong with describing when? At least
inform our users that the udev rules have evolved to more than just "detect
and mknod" scripts and that they are now relying on files and binaries
available in other locations, like /usr and /var.

How does the tool that creates an initramfs know which files to copy from
/usr and /var anyhow? 

Also, how well does this play with all our profiles (so not only the popular
architectures)? What about SELinux and/or grSecurity's RBAC model? Are these
supported throughout the initramfs?

Wkr,
	Sven Vermeulen

Re: [gentoo-dev] /usr vs. initramfs redux

[Robin H. Johnson]

On Fri, Aug 05, 2011 at 09:57:08AM -0400, Rich Freeman wrote:
> In any case, as long as a solution exists for md+lvm+luks+/usr before
> we start breaking more stuff than is already broken, then we should be
> fine.  Having more than one optional solution is fine.  While I don't
> think that gentoo needs to be another Ubuntu, having reasonable
> out-of-the-box support for one of the major desktop environments
> running on md+lvm+luks seems pretty useful.

My proposed minimal initramfs is an alternative to dracut for users with
trivial systems. For _ALL_ of the other cases, genkernel/dracut should
be used. Patches to add any of that other support to the minimal
initramfs will be rejected.

Definition of a trivial system:
/, /usr, /var are contained on or within device nodes available in
devtmpfs at the time the kernel invokes the initramfs.

Examples of non-trivial systems:
- {/, /usr, /var} on any of LVM, LUKS, NFS, iSCSI
- {/, /usr, /var} on MD that is not auto-assembled by the kernel [1].
- etc.

The initramfs would be rebuilt extremely infrequently, since it doesn't
contain any kernel modules, and reads the actual configuration from the
real root fs.

[1]: Upstream MD kernel folk have said everybody wanting to do MD
detection should migrate to initramfs for detection, as there at lot of
corner cases in detection where userspace is needed to make a sane
decision. Also if you use non-msdos partition tables, or large MDs.

-- 
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] /usr vs. initramfs redux

[William Hubbs]

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

Hi,

my knowledge of booting from an initramfs is limited right now, so keep
that in mind. However, I will attempt to answer some of your questions.

On Fri, Aug 05, 2011 at 10:06:48PM +0200, Sven Vermeulen wrote:
> I'm all in favor of documenting what an initramfs does (or at least what it
> is supposed to do), how it works, how to create one, how to debug issues
> while booting with one, etc.
> 
> That said, I'm a bit hesitant to describing that we "recommend" it
> regardless of the situation. What is wrong with describing when? At least
> inform our users that the udev rules have evolved to more than just "detect
> and mknod" scripts and that they are now relying on files and binaries
> available in other locations, like /usr and /var.

It looks like the situation where we will have to have one is if /usr
and /var are not on the same file system as /, because of how udev has
evolved.

> How does the tool that creates an initramfs know which files to copy from
> /usr and /var anyhow? 
 
 My understanding is that nothing gets copied from /usr and /var, and it
 doesn't have to.

 Here is my basic understanding of how the boot sequence works:

 1) rootfs is mounted on /. Rootfs contains the contents of the
	initramfs.
2) the init program inside  the initramfs is run.
3) This init program will mount the real /usr and /var.
4) This init program will then mount the real root on top of rootfs.
(there is a call that does this, but I'll need to look that up again). I
vaguely remember reading that you don't mount the real root on /newroot
then pivet_root as mentioned earlier in this thread; I think that is
part of the old initrd method.
5) This init program will now run /sbin/init or which ever init program
the user wants to run.

> Also, how well does this play with all our profiles (so not only the popular
> architectures)? What about SELinux and/or grSecurity's RBAC model? Are these
> supported throughout the initramfs?
 
 This one I can't answer.

Regards,

William


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

Re: [gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?

[DarKRaveR]

Historically those DIRs contained all utils/tools to manage the system
and fix problems etc. when you are unable to get /usr up, i.e. when it's
remote. The rootfs basically contained all the core system-tools minus
all the apps, which usually were managed centrally. 

With bbox of course one could mimic this to a certain point easily
within an initramfs though.

Regards

-Sven


On Mon, 2011-08-01 at 15:45 +0300, Samuli Suominen wrote:

> "Historically /bin, /sbin, /lib had the purpose to contain the utilities
> to mount /usr. This role can now be taken by the initramfs. Because the
> initramfs knows, where to find the root partition (which includes /etc),
> it can parse /etc/fstab and other configuration files and mount /usr
> before it finally switches the root partition and executes
> /usr/bin/init. From this point on init mounts the remaining partitions
> in /etc/fstab and the system starts as usual."
> 
> >>
> >> Cheers,
> >> Kacper
> >>
> > 
> > 
> 
> 

Re: [gentoo-dev] /usr vs. initramfs redux

[Rich Freeman]

On Fri, Aug 5, 2011 at 8:42 PM, William Hubbs <williamh@gentoo.org> wrote:
> On Fri, Aug 05, 2011 at 10:06:48PM +0200, Sven Vermeulen wrote:
>> How does the tool that creates an initramfs know which files to copy from
>> /usr and /var anyhow?
>
>  My understanding is that nothing gets copied from /usr and /var, and it
>  doesn't have to.
>
>  Here is my basic understanding of how the boot sequence works:
>
>  1) rootfs is mounted on /. Rootfs contains the contents of the
>        initramfs.

Ok, so the initfs is typically in /boot, though it need not be.  It
needs to be someplace the bootloader can find it, and with grub legacy
that typically means on a bare hard drive partition, or one using md
raid-1 with older metadata.  The initramfs doesn't need to find itself
- the bootloader loads it into ram and passes its address to the
kernel when executing it.

> 2) the init program inside  the initramfs is run.
> 3) This init program will mount the real /usr and /var.

So, this is the chicken and egg bit that led to the question about how
the tool that creates initramfs knows what to copy from /usr, etc.  If
/usr can be mounted without any files from /usr, then clearly booting
without /usr mounted shouldn't be a problem (just mount it early).  If
it does need files from /usr, then the initramfs has to contain those
files since /usr isn't mounted yet.

The answer isn't that complicated - the tool just knows what files are
needed from a hardcoded list/etc.  It might also use some static
linked tools.  It might also use a subset of the regular udev/etc
tools - it doesn't need to configure your video capture card and mouse
- it just needs to find anything that could contain the root
filesystem (and now /usr as well).

Keep in mind the initramfs does not need to fully initialize the
system, and it doesn't need to do it in a way compatible with anything
that will subsequently load.  It doesn't need to populate /dev the way
the rest of the stuff in the distro expects it to be, since the /dev
it is populating will get unmounted/wiped/etc before switching roots.
Initramfs just has to quickly operate in a scratch filesystem, mount
the real filesystems, then wipe itself out and chroot.  It doesn't
need to be compatible with the latest version of
dbus/hal/X11/openrc/etc - it just needs to be internally
self-consistent.

For whatever reason it still isn't working for me (using dracut) - for
some bizarre reason it can't auto-detect my raid, even though running
mdadm --assemble --scan and exiting the dash shell allows it to boot.
Oh well - I'm sure I'll work it out.  Then of course somebody needs to
patch it to mount /usr as well, or grab a copy of whatever Fedora is
doing if it is open source.

And as previously stated I'm fine with a more minimal initramfs being
provided as well, although my feeling is that if the dracut solution
works reliably it seems redundant.  In fact, dracut -H creates a
host-only solution that should only have minimal drivers installed,
and once it finishes running it should free any RAM it is using and
not leave any processes around.

Rich

[gentoo-dev] Re: /usr vs. initramfs redux

[Duncan]

Rich Freeman posted on Fri, 05 Aug 2011 21:04:50 -0400 as excerpted:

> On Fri, Aug 5, 2011 at 8:42 PM, William Hubbs <williamh@gentoo.org>
> wrote:
>> On Fri, Aug 05, 2011 at 10:06:48PM +0200, Sven Vermeulen wrote:
>>> How does the tool that creates an initramfs know which files to copy
>>> from /usr and /var anyhow?
>>
>>  My understanding is that nothing gets copied from /usr and /var, and
>>  it doesn't have to.
>>
>>  Here is my basic understanding of how the boot sequence works:
>>
>>  1) rootfs is mounted on /. Rootfs contains the contents of the
>>        initramfs.
> 
> Ok, so the initfs is typically in /boot, though it need not be.  It
> needs to be someplace the bootloader can find it, and with grub legacy
> that typically means on a bare hard drive partition, or one using md
> raid-1 with older metadata.  The initramfs doesn't need to find itself -
> the bootloader loads it into ram and passes its address to the kernel
> when executing it.

With a personal knowledge caveat similar to that of williamh's, I believe 
tha above to be incorrect.

AFAIK, the distinction between initrd and initramfs is the following:

initrd:  An initrd is a file separate from the kernel, so yes, the 
bootloader needs to know about and pass its information to the kernel.

initramfs:  An initramfs, as alluded to in the quote from the 
documentation in an earlier post, is a cpio archive appended to the 
kernel image itself -- no separate initrd file, and the kernel knows to 
look for the compressed image as loaded into memory after the end of the 
kernel code itself.  At kernel build time, if this feature is configured 
the kernel make process will check to see if a suitable prebuild cpio 
archive is available and append it to the kernel image if so.  If the cpio 
archive is not available yet but there's a configuration for building it, 
it'll be built, then appended to the kernel image.

As such, the bootloader doesn't need to point the kernel at the initramfs 
since the kernel already knows where to find it as loaded into memory as 
part of the kernel image file, and certain kernel commandline options 
(AFAIK root=, init=) that would normally apply to the initrd if one was 
used, apply to the final "realroot" instead.

An initramfs thus has less "to go wrong", since it's appended to the 
kernel image as part of the same file at build time, so the two are 
always kept together.  While it's still possible that the kernel fails to 
update its initramfs image at build-time, once that's correct, the boot 
loader can't accidentally be pointed at the wrong initrd, since an 
initramfs becomes part of the same kernel file as the kernel image itself.

(I've read that it's possible to have both an initramfs as appended to 
the kernel image, and an initrd as configured on the kernel command line 
by the boot loader, thus effectively creating a three-stage boot, 
initramfs, initrd, realroot.  I've no idea whether that's true or not, 
but the idea of trying to keep track of what belongs in one vs. the other 
strikes me as way more complex than it'd be worth for most gentoo users, 
altho I can see that it might be useful for users of binary distros with 
prebuilt kernel images, who wish to do additional stuff in an initrd, 
without messing with the prebuilt and presumably supported kernel image 
as distributed by their distro, with its own prebuilt initramfs 
appended.  It could also be useful for certain gentoo users, for instance 
those doing remote-boot kernels with the basics applying to most 
instances found in the initramfs, while any necessary configuration 
specific to only a subset could be loaded as an initrd.)

>> 2) the init program inside  the initramfs is run.
>> 3) This init program will mount the real /usr and /var.
> 
> So, this is the chicken and egg bit that led to the question about how
> the tool that creates initramfs knows what to copy from /usr, etc.  If
> /usr can be mounted without any files from /usr, then clearly booting
> without /usr mounted shouldn't be a problem (just mount it early).  If
> it does need files from /usr, then the initramfs has to contain those
> files since /usr isn't mounted yet.
> 
> The answer isn't that complicated - the tool just knows what files are
> needed from a hardcoded list/etc.

No quibbles with this or the rest of what you wrote, and indeed, I agree 
that the question needed asked/answered.  (It still hasn't been answered 
in any detail, but I'm not sure if that was the intent of asking the 
question.  The general "it's hardcoded" answer is sufficient at a 
suitably high level.)

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

Re: [gentoo-dev] /usr vs. initramfs redux

[William Hubbs]

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

Hi Rich,

On Fri, Aug 05, 2011 at 09:04:50PM -0400, Rich Freeman wrote:
> On Fri, Aug 5, 2011 at 8:42 PM, William Hubbs <williamh@gentoo.org> wrote:
> > On Fri, Aug 05, 2011 at 10:06:48PM +0200, Sven Vermeulen wrote:
> >> How does the tool that creates an initramfs know which files to copy from
> >> /usr and /var anyhow?
> >
> >  My understanding is that nothing gets copied from /usr and /var, and it
> >  doesn't have to.
> >
> >  Here is my basic understanding of how the boot sequence works:
> >
> >  1) rootfs is mounted on /. Rootfs contains the contents of the
> >        initramfs.
> 
> Ok, so the initfs is typically in /boot, though it need not be.  It
> needs to be someplace the bootloader can find it, and with grub legacy
> that typically means on a bare hard drive partition, or one using md
> raid-1 with older metadata.  The initramfs doesn't need to find itself
> - the bootloader loads it into ram and passes its address to the
> kernel when executing it.

Not quite. It is actually inside the kernel binary. You are thinking of
an initrd.

Look at these files:

/usr/src/linux/Documentation/filesystems/ramfs-rootfs-initramfs.txt.
/usr/src/linux/Documentation/early-userspace/README

> 
> > 2) the init program inside  the initramfs is run.
> > 3) This init program will mount the real /usr and /var.
> 
> So, this is the chicken and egg bit that led to the question about how
> the tool that creates initramfs knows what to copy from /usr, etc.  If
> /usr can be mounted without any files from /usr, then clearly booting
> without /usr mounted shouldn't be a problem (just mount it early).  If
> it does need files from /usr, then the initramfs has to contain those
> files since /usr isn't mounted yet.
 
 All we are trying to do is get /usr and /var mounted before running
 udev. All you really need in the initramfs is whatever is necessary to
 get the file systems mounted.

> Keep in mind the initramfs does not need to fully initialize the
> system, and it doesn't need to do it in a way compatible with anything
> that will subsequently load.  It doesn't need to populate /dev the way
> the rest of the stuff in the distro expects it to be, since the /dev
> it is populating will get unmounted/wiped/etc before switching roots.

Actually the /dev in the initramfs will not be wiped; it will become
/dev in the running system.

The other thing we will need is to have CONFIG_DEVTMPFS set to y in the
kernel config. This will create a tmpfs containing all devices that the
kernel knows about, which should be mounted on /dev. This
CONFIG_DEVTMPFS=y setting is also preferred by upstream udev.

> Initramfs just has to quickly operate in a scratch filesystem, mount
> the real filesystems, then wipe itself out and chroot.  It doesn't
> need to be compatible with the latest version of
> dbus/hal/X11/openrc/etc - it just needs to be internally
> self-consistent.

My understanding is it doesn't do anything like a chroot. Instead, it
mounts the real root directly on top of itself.

> For whatever reason it still isn't working for me (using dracut) - for
> some bizarre reason it can't auto-detect my raid, even though running
> mdadm --assemble --scan and exiting the dash shell allows it to boot.
> Oh well - I'm sure I'll work it out.  Then of course somebody needs to
> patch it to mount /usr as well, or grab a copy of whatever Fedora is
> doing if it is open source.

I think it is more simple than this; I will be looking into the steps to
make a trivial initramfs soon.

William


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

Re: [gentoo-dev] /usr vs. initramfs redux

[Mike Gilbert]

On Fri, Aug 5, 2011 at 10:37 PM, William Hubbs <williamh@gentoo.org> wrote:
> Hi Rich,
>
> On Fri, Aug 05, 2011 at 09:04:50PM -0400, Rich Freeman wrote:
>> On Fri, Aug 5, 2011 at 8:42 PM, William Hubbs <williamh@gentoo.org> wrote:
>> > On Fri, Aug 05, 2011 at 10:06:48PM +0200, Sven Vermeulen wrote:
>> >> How does the tool that creates an initramfs know which files to copy from
>> >> /usr and /var anyhow?
>> >
>> >  My understanding is that nothing gets copied from /usr and /var, and it
>> >  doesn't have to.
>> >
>> >  Here is my basic understanding of how the boot sequence works:
>> >
>> >  1) rootfs is mounted on /. Rootfs contains the contents of the
>> >        initramfs.
>>
>> Ok, so the initfs is typically in /boot, though it need not be.  It
>> needs to be someplace the bootloader can find it, and with grub legacy
>> that typically means on a bare hard drive partition, or one using md
>> raid-1 with older metadata.  The initramfs doesn't need to find itself
>> - the bootloader loads it into ram and passes its address to the
>> kernel when executing it.
>
> Not quite. It is actually inside the kernel binary. You are thinking of
> an initrd.
>
> Look at these files:
>
> /usr/src/linux/Documentation/filesystems/ramfs-rootfs-initramfs.txt.
> /usr/src/linux/Documentation/early-userspace/README
>

The initramfs cpio archive does not HAVE to be inside the kernel
binary. It may be assembled as a separate file (perhaps in /boot), and
passed to the kernel by the bootloader, just as Rich describes.

See the section "External initramfs images" in ramfs-rootfs-initramfs.txt.

Re: [gentoo-dev] /usr vs. initramfs redux

[Sven Vermeulen]

On Fri, Aug 05, 2011 at 07:42:29PM -0500, William Hubbs wrote:
> On Fri, Aug 05, 2011 at 10:06:48PM +0200, Sven Vermeulen wrote:
> > That said, I'm a bit hesitant to describing that we "recommend" it
> > regardless of the situation. What is wrong with describing when? At least
> > inform our users that the udev rules have evolved to more than just "detect
> > and mknod" scripts and that they are now relying on files and binaries
> > available in other locations, like /usr and /var.
> 
> It looks like the situation where we will have to have one is if /usr
> and /var are not on the same file system as /, because of how udev has
> evolved.

This isn't always true. I have /usr and /var on separate logical volumes
(and as such, separate file systems) yet I don't use DEVTMPFS nor an
initrd/initramfs, so I'm sure that the answer is a bit more specific.

Wkr,
	Sven Vermeulen

Re: [gentoo-dev] /usr vs. initramfs redux

[Marc Schiffbauer]

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

* Samuli Suominen schrieb am 05.08.11 um 15:43 Uhr:
> On 08/05/2011 04:12 PM, Marc Schiffbauer wrote:
> > OTOH the initrd that Robin described would be a very static solution
> > with almost no dependencies, so if genkernel had a USE flag like
> > "dracut" it would be possible to build it without dracut
> > dependency and thus would allow for smaller systems.
> > 
> To clarify,
> 
> By dependencies in dracut you mean udev? 

For example yes.

> And by smaller systems you mean
> systems without udev?

No.

> 
> Then yes, such minimal initramfs should propably be covered in the
> embedded's documentation, but otherwise trying to avoid dracut is
> reinventing the wheel...

You may be right, but to my understanding such a minimalistic initrd
would really do nothing special. Possibly a small shell script run
in a static busybox would do the job, Given some required conditions
like having a "normal" boot device like /dev/sda is given this
thingy would just mount the rootfs, read some config,, then mount
other things like /usr and thats it. Not to forget pivot_root and
starting the real init of course.

Maybe something like:
<pseudo shell mode>
#!/bin/sh
mount -t proc proc /proc
rootfs=`sed 's/.*root=\([^ ]*\)/\$1` /proc/cmdline
mount $rootfs /newroot
while read device mnt fstype; do
  mount -t $fstype $device $mnt
done < /newroot/etc/initramfs.mount
cd /newroot
pivot_root . /oldroot
exec chroot . /sbin/init
# END


-Marc
-- 
8AAC 5F46 83B4 DB70 8317  3723 296C 6CCA 35A6 4134

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

[gentoo-dev] Re: /usr vs. initramfs redux

[Steven J Long]

Sven Vermeulen wrote:

> On Fri, Aug 05, 2011 at 07:42:29PM -0500, William Hubbs wrote:
>> On Fri, Aug 05, 2011 at 10:06:48PM +0200, Sven Vermeulen wrote:
>> > That said, I'm a bit hesitant to describing that we "recommend" it
>> > regardless of the situation. What is wrong with describing when? At
>> > least inform our users that the udev rules have evolved to more than
>> > just "detect and mknod" scripts and that they are now relying on files
>> > and binaries available in other locations, like /usr and /var.

That seems reasonable.
>> 
>> It looks like the situation where we will have to have one is if /usr
>> and /var are not on the same file system as /, because of how udev has
>> evolved.
> 
> This isn't always true. I have /usr and /var on separate logical volumes
> (and as such, separate file systems) yet I don't use DEVTMPFS nor an
> initrd/initramfs, so I'm sure that the answer is a bit more specific.
> 
I have the same setup and no issues either. I think the problem is for other 
devices, eg someone mentioned having a bluetooth adapter in their laptop 
which gets picked up at boot by udev, but needs helpers in /usr.

According to https://bugs.gentoo.org/show_bug.cgi?id=364235#c1 udev marks 
(or marked) failing probers as missing devices, not failed, so udev-
postmount doesn't pick on them as needing to be rescanned.

I'm not sure if that bug's been fixed or not; the call to util_run_program 
is no longer in that function at: 
http://git.kernel.org/?p=linux/hotplug/udev.git;a=blob_plain;f=udev/udev-
rules.c;hb=HEAD
..but it might well have the same logical error for all I know.

I don't get why we can't allow udev to need localmount, as described in the 
bug, with CONFIG_DEVTMPFS creating nodes needed to mount /usr /var etc, 
especially as that setting is now being recommended by upstream. (And ofc we 
don't have to use it if it's not needed.)

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

[gentoo-dev] Re: /usr vs. initramfs redux

[Steven J Long]

Mike Gilbert wrote:

> On Fri, Aug 5, 2011 at 10:37 PM, William Hubbs <williamh@gentoo.org>
> wrote:
>> Not quite. It is actually inside the kernel binary. You are thinking of
>> an initrd.
>>
>> Look at these files:
>>
>> /usr/src/linux/Documentation/filesystems/ramfs-rootfs-initramfs.txt.
>> /usr/src/linux/Documentation/early-userspace/README
>>
> 
> The initramfs cpio archive does not HAVE to be inside the kernel
> binary. It may be assembled as a separate file (perhaps in /boot), and
> passed to the kernel by the bootloader, just as Rich describes.
> 
> See the section "External initramfs images" in ramfs-rootfs-initramfs.txt.

There's a great doc at: http://en.gentoo-wiki.com/wiki/Initramfs

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

Re: [gentoo-dev] /usr vs. initramfs redux

[Michał Górny]

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

On Sat, 6 Aug 2011 17:52:54 +0200
Marc Schiffbauer <mschiff@gentoo.org> wrote:

> > Then yes, such minimal initramfs should propably be covered in the
> > embedded's documentation, but otherwise trying to avoid dracut is
> > reinventing the wheel...
> 
> You may be right, but to my understanding such a minimalistic initrd
> would really do nothing special. Possibly a small shell script run

You just transformed a minimalistic initrd into awfully complex command
interpreter...

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] Re: /usr vs. initramfs redux

[Chris Coleman]

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

On 6 August 2011 20:22, Steven J Long <slong@rathaus.eclipse.co.uk> wrote:

> I don't get why we can't allow udev to need localmount, as described in the
> bug, with CONFIG_DEVTMPFS creating nodes needed to mount /usr /var etc,
> especially as that setting is now being recommended by upstream. (And ofc
> we
> don't have to use it if it's not needed.)
>

Personally, I need udev to start before localmount so that localmount can
mount my LVM volumes. I have CONFIG_DEVTMPFS enabled too, and I like how it
made my initramfs simpler, but it doesn't read rules from userspace. But
udev does.

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

Re: [gentoo-dev] /usr vs. initramfs redux

[Chris Coleman]

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

On 6 August 2011 20:52, Michał Górny <mgorny@gentoo.org> wrote:

> > > Then yes, such minimal initramfs should propably be covered in the
> > > embedded's documentation, but otherwise trying to avoid dracut is
> > > reinventing the wheel...
> >
> > You may be right, but to my understanding such a minimalistic initrd
> > would really do nothing special. Possibly a small shell script run
>
> You just transformed a minimalistic initrd into awfully complex command
> interpreter...
>

The /init on the initramfs should be a shell script, shouldn't it? If this
initramfs is going to be recommended in the handbook, we need to provide an
initramfs that isn't going to be too difficult to understand. Like one that
can be simply extracted, tweaked, and re-compressed.

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

Re: [gentoo-dev] Re: /usr vs. initramfs redux

[William Hubbs]

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

On Sat, Aug 06, 2011 at 08:22:23PM +0100, Steven J Long wrote:
> I have the same setup and no issues either. I think the problem is for other 
> devices, eg someone mentioned having a bluetooth adapter in their laptop 
> which gets picked up at boot by udev, but needs helpers in /usr.
> 
> According to https://bugs.gentoo.org/show_bug.cgi?id=364235#c1 udev marks 
> (or marked) failing probers as missing devices, not failed, so udev-
> postmount doesn't pick on them as needing to be rescanned.
> 
> I'm not sure if that bug's been fixed or not; the call to util_run_program 
> is no longer in that function at: 
> http://git.kernel.org/?p=linux/hotplug/udev.git;a=blob_plain;f=udev/udev-
> rules.c;hb=HEAD
> ..but it might well have the same logical error for all I know.

The concern about udev-postmount is the line that says:

udevadm trigger --type=failed

The --type=failed option is going away and upstream is getting rid of
the failed marking eventually; there will be no more "failed" events
either.

William


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

Re: [gentoo-dev] /usr vs. initramfs redux

[William Hubbs]

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

On Fri, Aug 05, 2011 at 12:46:04AM +0000, Robin H. Johnson wrote:
> The minimal initramfs would do the following.
> 
> 1. Mount devtmpfs/sysfs/procfs as needed to access devices.
> 2. Mount real_root to /newroot
> 3. Read /newroot/etc/initramfs.mount and /newroot/etc/fstab
> 4.1. If /newroot/etc/initramfs.mount does not exist
>      Assume it contains only: /usr /var
> 5. Mount the combined items from said files

Should these be mounted rread-only or just mounted? Also, will
fsck still work if they are mounted?

I am concerned about /var being included in this because of the
potential of filling up the root partition. Upstream is only talking
about /usr as stated earlier in this thread, so how are we getting /var
involved?

William


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

Re: [gentoo-dev] /usr vs. initramfs redux

[Robin H. Johnson]

On Wed, Aug 10, 2011 at 11:49:38AM -0500, William Hubbs wrote:
> On Fri, Aug 05, 2011 at 12:46:04AM +0000, Robin H. Johnson wrote:
> > The minimal initramfs would do the following.
> > 
> > 1. Mount devtmpfs/sysfs/procfs as needed to access devices.
> > 2. Mount real_root to /newroot
> > 3. Read /newroot/etc/initramfs.mount and /newroot/etc/fstab
> > 4.1. If /newroot/etc/initramfs.mount does not exist
> >      Assume it contains only: /usr /var
> > 5. Mount the combined items from said files
> 
> Should these be mounted rread-only or just mounted? Also, will
> fsck still work if they are mounted?
read-only. Yes, this does mean that the fsck code needs some improving,
and potentially if it makes changes on a ro-mounted disk, the disk needs
to be umounted & remounted, or a reboot needs to happen. Basically what
we do for / now needs to extend to the other mountpoints as well.

> I am concerned about /var being included in this because of the
> potential of filling up the root partition.
Err, I don't follow. How does mounting /var fill up the root partition?

> Upstream is only talking about /usr as stated earlier in this thread,
> so how are we getting /var involved?
See my other notes on stuff in udev rules that require /var before they
can complete successfully.

-- 
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] /usr vs. initramfs redux

[Dale]

Robin H. Johnson wrote:
> On Wed, Aug 10, 2011 at 11:49:38AM -0500, William Hubbs wrote:
>    
>
>> I am concerned about /var being included in this because of the
>> potential of filling up the root partition.
>>      
> Err, I don't follow. How does mounting /var fill up the root partition?
>
>    

If you take /var off its own partition and put it on /, then it will 
fill up / instead of /var.  Filling up /var, not the end of the world.  
Filling up / is a bad thing.

BTW, I have /var on its own partition.  This moving things to / and not 
being able to have /usr, /var and such makes me really nervous.  I have 
about double the needed space on /var and I still have had it fill up 
not once but several times.  Think OOo build here.  If /var didn't have 
its own partition, I would have had a crashed system and would have had 
to use a another bootable medium to clean out some stuff so it would 
boot again.  I'm just glad I am setting at my system.  If it was remote, 
I would be VERY pissed at whoever started this / only stuff.

I guess next /home will have to be on / too.  Since everything else is 
moving that way, why not.  May as well lose everything and be done with 
it.  Right?

Just a users point of view.  A long time Gentoo user I might add.   I 
still have my 1.4 CD.

Dale

:-)  :-)

Re: [gentoo-dev] /usr vs. initramfs redux

[Robin H. Johnson]

On Wed, Aug 10, 2011 at 03:47:18PM -0500, Dale wrote:
> > On Wed, Aug 10, 2011 at 11:49:38AM -0500, William Hubbs wrote:
> >> I am concerned about /var being included in this because of the
> >> potential of filling up the root partition.
> > Err, I don't follow. How does mounting /var fill up the root partition?
> 
> If you take /var off its own partition and put it on /, then it will 
> fill up / instead of /var.  Filling up /var, not the end of the world.  
> Filling up / is a bad thing.
[snip]
That is clear, but entirely irrelevant to my question. I _explicitly_
support /var on a partition, that's why my entire initramfs proposal
included it. 

I want to know what William had _against_ the mounting /var in my
proposal, because that is what his statement implied.

-- 
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] /usr vs. initramfs redux

[William Hubbs]

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

On Wed, Aug 10, 2011 at 08:02:44PM +0000, Robin H. Johnson wrote:
> On Wed, Aug 10, 2011 at 11:49:38AM -0500, William Hubbs wrote:
> > I am concerned about /var being included in this because of the
> > potential of filling up the root partition.
> Err, I don't follow. How does mounting /var fill up the root partition?

Sorry, I should have been more clear here. Mounting /var doesn't fill up
the root partition, but if you don't want to use the initramfs, this
means that /var must also exist on the root partition, which can create
more of a concern for filling the root partition than putting /usr on
the root partition creates.

William


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

Re: [gentoo-dev] /usr vs. initramfs redux

[Dale]

Robin H. Johnson wrote:
> On Wed, Aug 10, 2011 at 03:47:18PM -0500, Dale wrote:
>    
>>> On Wed, Aug 10, 2011 at 11:49:38AM -0500, William Hubbs wrote:
>>>        
>>>> I am concerned about /var being included in this because of the
>>>> potential of filling up the root partition.
>>>>          
>>> Err, I don't follow. How does mounting /var fill up the root partition?
>>>        
>> If you take /var off its own partition and put it on /, then it will
>> fill up / instead of /var.  Filling up /var, not the end of the world.
>> Filling up / is a bad thing.
>>      
> [snip]
> That is clear, but entirely irrelevant to my question. I _explicitly_
> support /var on a partition, that's why my entire initramfs proposal
> included it.
>
> I want to know what William had _against_ the mounting /var in my
> proposal, because that is what his statement implied.
>
>    

For the record, I think /usr should work on a separate partition as 
well.  One reason, I would like to use LVM on all but my / file system.  
This is something I been fiddling with for a while.  Thing is, if /usr 
has to be on / then there is no point in me using LVM at all.  I don't 
want / on a LVM because that requires some sort of init* to work.  That 
is what I am trying to avoid.

My opinion, this is going to lead to one heck of a mess.  If it is 
coming from upstream, which it appears to be, then there needs to be 
someone to point the finger at.  I read somewhere it is because of 
Fedora so that helps some.  It's still going to be a mess.  My gut sees 
it coming.  I can already see where it is going to alter my plans hugely 
and I'm a desktop user.  I can't imagine a server or some complicated 
setup.  That is the ones I feel sorry for the most.  If they are not 
using some init* thing already, they appear to be needing one soon.  
It's just one more thing to have to deal with and worry about breaking.

Just my $0.02 worth and that ain't much. ;-)

Dale

:-)  :-)

Re: [gentoo-dev] /usr vs. initramfs redux

[Robin H. Johnson]

On Wed, Aug 10, 2011 at 04:42:04PM -0500, Dale wrote:
> For the record, I think /usr should work on a separate partition as 
> well. 
You're entirely missing the point of this thread.

> One reason, I would like to use LVM on all but my / file system.  
> This is something I been fiddling with for a while.  Thing is, if /usr 
> has to be on / then there is no point in me using LVM at all.  I don't 
> want / on a LVM because that requires some sort of init* to work.  That 
> is what I am trying to avoid.
The final solution in this thread:
TL;DR version: If your /usr is NOT on /, you MUST use an initramfs.

More detailed:
1. If you want /usr or /var on separate partitions (not LVM or anything
   elsewhere userspace action is required to make the block devices
   usable), then the minimal initramfs (or something more capable) MUST
   be used so that udev is happy.
2. If your /usr, /var, root etc block devices require userspace action
   (eg LVM, MD, crypto, firmware etc). You MUST use genkernel, dracut or
   some other initramfs of your own creation. The proposed minimal
   initramfs WILL NOT handle these situations.

> My opinion, this is going to lead to one heck of a mess.  If it is 
> coming from upstream, 
Yes, it's upstream, and their reasons are fairly valid: avoid circular
dependencies in startup.

-- 
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] /usr vs. initramfs redux

[Robin H. Johnson]

On Wed, Aug 10, 2011 at 03:57:30PM -0500, William Hubbs wrote:
> Sorry, I should have been more clear here. Mounting /var doesn't fill up
> the root partition, but if you don't want to use the initramfs, this
> means that /var must also exist on the root partition, which can create
> more of a concern for filling the root partition than putting /usr on
> the root partition creates.
That's a problem for the users, not the initramfs. The initramfs
supports /usr, /var and anything else as noted. Having /var on / is a
perfectly valid choice for certain situations. The problem of filling up
/ is PEBKAC primarily, and can happen equally for / (think /root), /usr
on /, /var on /.

-- 
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] /usr vs. initramfs redux

[Dale]

Robin H. Johnson wrote:
>
> The final solution in this thread:
> TL;DR version: If your /usr is NOT on /, you MUST use an initramfs.
>
> More detailed:
> 1. If you want /usr or /var on separate partitions (not LVM or anything
>     elsewhere userspace action is required to make the block devices
>     usable), then the minimal initramfs (or something more capable) MUST
>     be used so that udev is happy.
> 2. If your /usr, /var, root etc block devices require userspace action
>     (eg LVM, MD, crypto, firmware etc). You MUST use genkernel, dracut or
>     some other initramfs of your own creation. The proposed minimal
>     initramfs WILL NOT handle these situations.
>
>    

The need of init* is just what I want to avoid.  Seeing how this is 
coming, I'm glad I didn't get /usr, /var set up on LVM just to find out 
I got to put it back like it was before I put in all the effort to do it.

Pardon me for saying this, this is a crap sandwich.  Whoever came up 
with this should have to eat it.  I hope all the people this messes up 
has his/her email addy.

Dale

:-)  :-)

Re: [gentoo-dev] /usr vs. initramfs redux

[Jorge Manuel B. S. Vicetto]

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

On 10-08-2011 21:56, Robin H. Johnson wrote:
> On Wed, Aug 10, 2011 at 03:57:30PM -0500, William Hubbs wrote:
>> Sorry, I should have been more clear here. Mounting /var doesn't
>> fill up the root partition, but if you don't want to use the
>> initramfs, this means that /var must also exist on the root
>> partition, which can create more of a concern for filling the root
>> partition than putting /usr on the root partition creates.
> That's a problem for the users, not the initramfs. The initramfs 
> supports /usr, /var and anything else as noted. Having /var on / is
> a perfectly valid choice for certain situations. The problem of
> filling up / is PEBKAC primarily, and can happen equally for / (think
> /root), /usr on /, /var on /.

True, but it's also far more likely to happen when you have /usr and
/var on / than otherwise.

- -- 
Regards,

Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJOQxMdAAoJEC8ZTXQF1qEPBKoQAI5FBt/rDaFSWA5ln6tmDNOt
HhLq54dirdaXWSdHUp6C+vmSNcAC/QPmPlB8RA/bwXQ2aRlO0m4Jc6XPS3NTdT0H
TEgqBQ+3NtZ3mRyTHv+E2YtDanemZIQ5rrpl0QuvMfeODUOM3zNdTosV6/37tmo+
9clXHGzauPqWKpUvXxHc9Ic7OSA9ROXy1vq8wvTzvQWsg2sz7ML6pU7yAE5niC78
FlFgZyG2aZ0S+oBt88aSEkDEwU6aDlgQbLwxT5rN61QtE8wvV5hx5h7k74iJwkaJ
89vUbcgtmdMNFVYcXpIprlqkYWKr68uBxqsdSy2z+uX6d6E90G8mQs8qF9cHryFY
YuA9WSXn4rtElsTkdrdA9yEqEwGXSeiD9oohn8wHwcVYNKWYKVPiRzeCxyAVOSVy
dUqCRh5ZvTVuyD7wvVY1rVihCRLdSSOTYkUknOWexPs/PqvWmwDlhsEH79vVZeL2
pxnO5umvLKn17FL/jOimS2djua1b83elX99nqjdfZLTqT/DCeZ699YOD2Hc1Dd0O
AtYmDzbJSNnjKoFVU8SGX4NspsGdilBFKCa5Gj6MUXqHgjHcMK23HpBcl76jIgeX
tqK+ooJYsd0p/hwCV3gJqaUQvtvU3r05qfU7Qjzg3PAif0Heu4wrjKG056UkUIFb
t1HYMphiA6ITXnSLVl7o
=EcGc
-----END PGP SIGNATURE-----

Re: [gentoo-dev] /usr vs. initramfs redux

[Eray Aslan]

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

On 2011-08-11 12:56 AM, Robin H. Johnson wrote:
> The problem of filling up
> / is PEBKAC primarily, and can happen equally for / (think /root), /usr
> on /, /var on /.

This does not match with my experience.  Over the years, I have seen
/var filling up several times on servers, but not /.  Please be careful
with where you are going with this.

As a side note, I do admire BSD now and then.  Simplicity is good.
-- 
Eray Aslan <eras@gentoo.org>


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

Re: [gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?

[Dale]

Rich Freeman wrote:
> On Thu, Aug 4, 2011 at 7:49 AM, Dale<rdalek1967@gmail.com>  wrote:
>    
>>  From a users perspective.  Could it not be possible to have some USE flag,
>> or other setting, that would tell portage that a separate /usr partition is
>> being used then have the needed files placed elsewhere on / ?  I'm not a dev
>> and I don't play one on TV but I do like options and being able to customize
>> some things.  It is one of the things Gentoo is about.
>>
>>      
> I don't see what a USE flag gets us:
>
> 1.  If you have a separate /usr then either booting without an
> initramfs will work or it won't work - largely depending on how
> complex your environment is.  Booting with an initramfs will work
> reliably (well, if we sort out the initramfs situation - having done
> some more tests I have one virtual machine which was pretty easy to
> get running, and one physical box that for whatever reason wouldn't
> detect/start the RAID).
>
> 2.  If you don't have a separate /usr than booting will always work
> regardless of where the files are, since the system will always find
> them.
>
> Unless what is being proposed is to actually do the Fedora thing and
> make /bin, /lib, etc a symlink into /usr/bin, /usr/lib, etc than there
> isn't anything at package-install time for the flag to affect.  If we
> do want to do the Fedora thing would a flag even work, since those
> directories get created from the stage3?  It seems to me that if you
> want the symlinks you just need to set them up when doing the install
> (or from a rescue disk), and then the package manager should follow
> the links when doing subsequent installs.  Oh, and not all package
> managers like the top-level directories to be symlinks.
>
> I think that as was the case with the use of bash vs sh we may need to
> have a policy decision made here.  Right now the general policy has
> been to conform to FHS, and the Fedora/etc proposal does not do this
> (and apparently we are already a bit out of compliance).  I think that
> moving in a different direction is a big decision.
>
> And, if we do decide to move in that direction, I agree with Samuli
> that we need a transition plan.  Packages can't just start breaking
> initrd-less setups left and right overnight.  To start, we need to get
> dracut/etc configurable to mount any necessary directories (I checked
> - it is fairly smart (though not 100% effective) at finding root, but
> does not try to mount anything else).  Then we need to update our
> documentation.  Then we need to communicate the change to users, and
> give them time to migrate.  Only then can packages have the freedom to
> require usr to be available at boot.
>
> I don't propose that if we move in this direction that we "fix"
> anything that isn't currently FHS-compliant - the damage is already
> done.  We just should avoid propagating the situation until users are
> ready.
>
> Rich
>
>    

The USE flag was just one option that I could think of.  That is why I 
also said "or something" along with that.  You devs are good at coming 
up with neato tools to fix stuff.  ;-)

I understand that Fedora is wanting to do this.  What I don't understand 
is why.  It seems it is udev that is wrecking this havoc.  I like udev 
myself and it seems to work fine but surely something can be done to fix 
this without breaking something else.   It seems from your reply that it 
is breaking the rules of FHS which if Gentoo follows will then be 
breaking FHS as well and this will likely force others to do the same.  
Can someone not explain this to the people that are pushing this?

I saw it mentioned somewhere that a /run directory can be created.  
Since it would likely be small, I wouldn't mind that.  I'd be fine if 
the same files were installed in both /usr/*bin and /run.  I just like 
being able to have /usr, /var and /home on a separate partition without 
a init*.  I usually start my system out as /, /boot and /home.  Then 
after the install is done, I figure up the space need based on the space 
used and copy to a new drive that is partitioned out as /boot, /, /home, 
/usr, and /var.  I am sure there are users that have to have /usr and/or 
/var on a separate partition but don't want a init* to deal with.

Again, my $0.02.  Whatever that is worth.

Dale

:-)  :-)

Re: [gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?

[Rich Freeman]

On Thu, Aug 11, 2011 at 2:04 AM, Dale <rdalek1967@gmail.com> wrote:
> I understand that Fedora is wanting to do this.  What I don't understand is
> why.  It seems it is udev that is wrecking this havoc.

Well, the answer is a bit more nuanced.

First, keep in mind that in a "typical" linux distro the end user does
not build their own kernel (sure, there is usually a way to do it, but
the distro doesn't encourage this).  Instead you get a
one-size-fits-all kernel with just about everything compiled into
modules.  This invariably requires an initramfs to boot, since you
can't tell what drivers will be needed to mount root.  So, anybody
with a mainstream distro already has an initramfs.

Now that you have everything in modules, how do you figure out which
modules to load/etc?  Well, in the end udev becomes the best tool for
this.  Then the question comes up, if you're going to use udev to
configure your mouse, why not use it to configure even the most
essential boot-time devices and avoid re-inventing the wheel?

So, now the big distros are in the state they're currently in - they
end up needing /usr mounted anyway due to the evolution of udev.  It
sort-of crept up on them.

Now, what Fedora is currently proposing is to turn this from a "bug"
into a "feature."  As long as we need to have /usr around anyway - why
not get rid of /bin, /lib, and so on.  What they plan to do is move
all these files under /usr, with compatibility links in the other root
directories.  Then you can mount /usr as read-only (or maybe even run
it from nfs), and every single executable/library on the system is
better protected from accidental modification.  This requires
initramfs support, but they already have an initramfs and so they just
have to add a few lines to mount it (dracut already parses /etc/fstab
to mount root and has just about all the userspace logic in place to
do what mount already does on a booted system, so it can probably just
do little more than a mount /usr to accomplish this).

Since most distros are already using an initramfs, they also have
leveraged this to add additional features, like identifying root
devices by UUID, allowing root on LVM+raid or NFS, or iSCSI, or
whatever.  Also, LUKS support is pretty common - you can install
Ubuntu and check a box and everything gets encrypted.

So, basically other distros already need to support initramfs, and
they just keep going down a path of leveraging this further.  It all
stems from their original decision to make one kernel to rule them
all, and make it modular so that it doesn't eat up half of RAM in
doing so.

> I saw it mentioned somewhere that a /run directory can be created.  Since it
> would likely be small, I wouldn't mind that.  I'd be fine if the same files
> were installed in both /usr/*bin and /run.

So, I believe the purpose of /run is to be a future location for what
currently goes in places like /var/run - this is state information,
sockets, etc that have no meaning after a reboot.  Most likely it
would be implemented as a tmpfs or something along those lines.  It
would not contain copies of anything in /usr/bin/etc.  Then /var
becomes a place for caches that have meaning between reboots (spools,
etc).

Rich

[gentoo-dev] Re: Warn users not to do separate /usr partition without proper initramfs in the handbook?

[Duncan]

Rich Freeman posted on Thu, 11 Aug 2011 08:20:21 -0400 as excerpted:

> On Thu, Aug 11, 2011 at 2:04 AM, Dale <rdalek1967@gmail.com> wrote:
>> I understand that Fedora is wanting to do this.  What I don't
>> understand is why.  It seems it is udev that is wrecking this havoc.
> 
> Well, the answer is a bit more nuanced.

Thank you very much for that answer.  I understood the basic concepts, 
but having it all spelled out so clearly in front of me certainly helped 
integrate my understanding of the whole, as opposed to a bunch of 
independent pieces. =:^)

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

Re: [gentoo-dev] Re: Warn users not to do separate /usr partition without proper initramfs in the handbook?

[Dale]

Duncan wrote:
> Rich Freeman posted on Thu, 11 Aug 2011 08:20:21 -0400 as excerpted:
>
>    
>> On Thu, Aug 11, 2011 at 2:04 AM, Dale<rdalek1967@gmail.com>  wrote:
>>      
>>> I understand that Fedora is wanting to do this.  What I don't
>>> understand is why.  It seems it is udev that is wrecking this havoc.
>>>        
>> Well, the answer is a bit more nuanced.
>>      
> Thank you very much for that answer.  I understood the basic concepts,
> but having it all spelled out so clearly in front of me certainly helped
> integrate my understanding of the whole, as opposed to a bunch of
> independent pieces. =:^)
>
>    

+1  I still would like to be able to have /usr and such on a separate 
partition without the init* stuff tho.  I sense a nightmare coming for 
me.  This may get me to the point of just using lvm for everything. Just 
dive in head first.

How long till all this is going to be a absolute requirement?  That is 
my question.

Dale

:-)  :-)

Re: [gentoo-dev] Re: Warn users not to do separate /usr partition without proper initramfs in the handbook?

[Rich Freeman]

On Tue, Aug 16, 2011 at 3:39 AM, Dale <rdalek1967@gmail.com> wrote:
> How long till all this is going to be a absolute requirement?  That is my
> question.

Well, I don't speak for the teams that want to implement this, but my
recommendation is that it not become a requirement until everything is
in place to support it.  So, our initramfs tools should automatically
find and mount /usr and /var, and so on.  Documentation should be
updated as well, such as the raid+lvm guide.  Once all that is done
and working in ~arch, then it could be stabilized, at which point we
can start expanding this dependency.

Considering that we still haven't finished doing all of this for
OpenRC yet, I wouldn't worry about the changes hitting you anytime
soon.  I'd consider a lessons-learned from OpenRC that we shouldn't
stabilize packages until AFTER the docs are updated.  Otherwise it can
tend to never happen.

Rich

Re: [gentoo-dev] Re: Warn users not to do separate /usr partition without proper initramfs in the handbook?

[Dale]

Rich Freeman wrote:
>
> Considering that we still haven't finished doing all of this for
> OpenRC yet, I wouldn't worry about the changes hitting you anytime
> soon.  I'd consider a lessons-learned from OpenRC that we shouldn't
> stabilize packages until AFTER the docs are updated.  Otherwise it can
> tend to never happen.
>
> Rich
>
>    

Thanks for the reply.  I also agree that the docs should be ready first 
then the change.  I have a friend that may be switching from Gentoo 
because he can not get good docs on how to get his network working after 
the OpenRC update.  It appears the docs he needs aren't ready yet.  
What's the point of having a nice Gentoo install if you can't set up 
your network stuff?

Looks like I'm going to be using the test drive soon.  I'm going to have 
to get into all this stuff I truly hate to mess with.

Thanks.

Dale

:-)  :-)

[gentoo-dev] Re: Warn users not to do separate /usr partition without proper initramfs in the handbook?

[Duncan]

Rich Freeman posted on Tue, 16 Aug 2011 08:34:09 -0400 as excerpted:

> Considering that we still haven't finished doing all of this for OpenRC
> yet, I wouldn't worry about the changes hitting you anytime soon.  I'd
> consider a lessons-learned from OpenRC that we shouldn't stabilize
> packages until AFTER the docs are updated.  Otherwise it can tend to
> never happen.

As a follower and user of baselayout2/openrc from way back when it was 
still baselayout-1.13 (who BTW did my own share of bug tracing and 
filing, sometimes with suggested patches or partial-patches, along the 
way), and a CC on both the main and docs stabilization bugs, that 
actually rather mystified me.

Originally, all the documentation was supposed to be a blocker for the 
openrc/baselayout2 stabilization bug, and that made sense.

But then the docs folks said the policy was only to document stable, and 
that they weren't going to document openrc until it was going stable.  
Which didn't seem to make sense as everybody knew it was a big job, too 
big to happen in a final push, without "mistakes being made".  Plus, by 
the time the final push came, for a change that big, there would be all 
sorts of other bugs blocking on openrc going stable, so there'd be no 
real way to do it properly, particularly with docs as understaffed as it 
is.

I never did see how it was going to work, but shutup, because I was "just 
a user", and I couldn't see the devs being /that/ stupid, to stabilize 
without in-place docs or to rush them at the last minute, when so many 
users would be depending on the docs and the reputation Gentoo /used/ to 
have for being a Linux bright-spot, in terms of documentation, to the 
point that users from other distros used to seek out Gentoo docs, and I 
know that was one of the reason /I/ found Gentoo, particularly since 
Gentoo and its users were so early out the gate in the xfree86/xorg 
switchup.

But then I saw it happen, and there's STILL openrc docs-related bugs 
open. I guess that really brought home to me how far Gentoo has fallen 
from its once exalted status, resting on its laurels... until they've all 
wilted and been thrown out and there's no more to rest on.

That's the real bright spot (aside from his hardened activities which 
only have a relatively indirect affect on anything I follow closely) I 
see to swift's return as well, as he has already started tackling some of 
the related docs bugs.  Nothing against the folks, nightmorph in 
particular, that have been holding down the fort -- I've been on projects 
when it seemed to be only me at times myself and it NOT easy -- but being 
the only real active member IS hard, and certainly DOES lead to burnout 
after awhile, and nightmorph has been exhibiting signs of burnout for two 
years or more (IIRC council even debated what might be done to help at 
one point, but without real volunteers, there's not a lot that they could 
do, except back off a bit on the pressure nightmorph was under, to the 
extent they could help there).  So swift must certainly be a welcome 
relief for nightmorph, and for the rest of us, even in just the couple 
days he has been back, there's some docs changes, etc. =:^)

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

Re: [gentoo-dev] Re: Warn users not to do separate /usr partition without proper initramfs in the handbook?

[Rich Freeman]

On Tue, Aug 16, 2011 at 12:39 PM, Duncan <1i5t5.duncan@cox.net> wrote:
> But then the docs folks said the policy was only to document stable, and
> that they weren't going to document openrc until it was going stable.

Well, I can see their point - OpenRC was the future for probably 2
years before it actually happened.  Certainly it wouldn't make sense
to keep all the official docs updated for that entire period of time.

I think this boils down to basic release management - decide to do
something in a certain timeframe, open blockers, announce the last
call, and then just make it happen (no new blockers allowed without
approval by the project lead or the council).  Once you can see the
light at the end of the tunnel the doc request goes in and becomes a
blocker.

I think that this mostly happens already.  We just need to make sure
the docs stay as a blocker.  In the case of OpenRC I'd treat the
baselayout 1/2 versions of the documentation as separate branches and
then make the switch all at once.

That said, I don't run the docs team, the openrc team, or the
/usr-is-required team, so feel free to chime in with whatever I
missed...

Rich

Re: [gentoo-dev] Re: Warn users not to do separate /usr partition without proper initramfs in the handbook?

[Robin H. Johnson]

On Tue, Aug 16, 2011 at 09:22:30AM -0500, Dale wrote:
> Thanks for the reply.  I also agree that the docs should be ready first 
> then the change.  I have a friend that may be switching from Gentoo 
> because he can not get good docs on how to get his network working after 
> the OpenRC update.  It appears the docs he needs aren't ready yet.  
> What's the point of having a nice Gentoo install if you can't set up 
> your network stuff?
Did he file a bug for this? We have been working on them.

-- 
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] Re: Warn users not to do separate /usr partition without proper initramfs in the handbook?

[Dale]

Robin H. Johnson wrote:
> On Tue, Aug 16, 2011 at 09:22:30AM -0500, Dale wrote:
>    
>> Thanks for the reply.  I also agree that the docs should be ready first
>> then the change.  I have a friend that may be switching from Gentoo
>> because he can not get good docs on how to get his network working after
>> the OpenRC update.  It appears the docs he needs aren't ready yet.
>> What's the point of having a nice Gentoo install if you can't set up
>> your network stuff?
>>      
> Did he file a bug for this? We have been working on them.
>
>    

Nope.  He's a ghost Gentoo user.  I don't think he is subscribed to any 
mailing list or the forums.  He just searches for clues and docs.

I have to say, the docs seem to be lacking on updates.  I think it is a 
lack of manpower so my hats off to the few, maybe even one, that is 
working hard to do what is done.  I wish I could help more.  I'm 
disabled and have more time than most to do it but the xml thingy is 
Greek to me.  No offence to the Greeks here tho.  ;-)   I do think that 
docs should at least be ready a few days before things are released or 
the release should wait.  Some things are more important and some may 
not be such a huge deal but networking is something that about every 
computer has to have and some setups are complicated and need to have 
good docs to back those people up.

Maybe some devs could help write some docs and the docs folks just 
convert it to the xml thingy?  Sort of spread the load a little?

Just saying.  :-)

Dale

:-)  :-)

Re: [gentoo-dev] Re: Warn users not to do separate /usr partition without proper initramfs in the handbook?

[Sven Vermeulen]

On Tue, Aug 16, 2011 at 09:22:30AM -0500, Dale wrote:
> Thanks for the reply.  I also agree that the docs should be ready first 
> then the change.  I have a friend that may be switching from Gentoo because 
> he can not get good docs on how to get his network working after the OpenRC 
> update.  It appears the docs he needs aren't ready yet.  What's the point 
> of having a nice Gentoo install if you can't set up your network stuff?

I know, major apologies...

The documents (more specific, the Gentoo Handbook and a few other
high-profile ones) have been updated recently (last few days) so they should
be okay now. However, some good reviews never hurt.

If you do still find issues, don't hesitate to create a bugreport for it.

Wkr,
	Sven Vermeulen

Re: [gentoo-dev] Re: Warn users not to do separate /usr partition without proper initramfs in the handbook?

[Robin H. Johnson]

On Tue, Aug 16, 2011 at 03:55:23PM -0500, Dale wrote:
> > Did he file a bug for this? We have been working on them.
> Nope.  He's a ghost Gentoo user.  I don't think he is subscribed to any 
> mailing list or the forums.  He just searches for clues and docs.
Can you please data-capture that bug and file it for him then.

We really need to hear about hidden bugs like this.

> I have to say, the docs seem to be lacking on updates.  I think it is a 
> lack of manpower so my hats off to the few, maybe even one, that is 
> working hard to do what is done.  I wish I could help more.  I'm 
> disabled and have more time than most to do it but the xml thingy is 
> Greek to me.  
Write plaintext (or wiki markup), adding the XML is a fairly trivial
transform.

> Some things are more important and some may not be such a huge deal
> but networking is something that about every computer has to have and
> some setups are complicated and need to have good docs to back those
> people up.
I've got some very complex network setups that I have documented and
supported. My homedir has several of them from my own experience:
http://dev.gentoo.org/~robbat2/conf.d-net/
Includes dual-homing, multi-homing, and HE.net IPv6 tunnels.
I wrote a lot of the original bonding, vlan, mac-changer, bridging code
in BL1.

Better documentation on how to set up the complex network configs would
be great, but the net.example is too long already.

-- 
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] Re: Warn users not to do separate /usr partition without proper initramfs in the handbook?

[Dale]

Robin H. Johnson wrote:
> On Tue, Aug 16, 2011 at 03:55:23PM -0500, Dale wrote:
>    
>>> Did he file a bug for this? We have been working on them.
>>>        
>> Nope.  He's a ghost Gentoo user.  I don't think he is subscribed to any
>> mailing list or the forums.  He just searches for clues and docs.
>>      
> Can you please data-capture that bug and file it for him then.
>
> We really need to hear about hidden bugs like this.
>
>    

He has been talking to someone but no clue who.  I'm not even sure it is 
a dev or anything.  I think to have a bug, there has to be something 
first.  I think his point was, once you get sort of advanced with the 
new openrc networking, there is little docs to follow.  Me, I use DHCP 
and it "just works" for me.  Thank goodness for that.

>> I have to say, the docs seem to be lacking on updates.  I think it is a
>> lack of manpower so my hats off to the few, maybe even one, that is
>> working hard to do what is done.  I wish I could help more.  I'm
>> disabled and have more time than most to do it but the xml thingy is
>> Greek to me.
>>      
> Write plaintext (or wiki markup), adding the XML is a fairly trivial
> transform.
>
>    

That is good to know.  May have to poke my head in the door on -doc 
then.  Maybe this old fart can do something after all.  ;-)

>> Some things are more important and some may not be such a huge deal
>> but networking is something that about every computer has to have and
>> some setups are complicated and need to have good docs to back those
>> people up.
>>      
> I've got some very complex network setups that I have documented and
> supported. My homedir has several of them from my own experience:
> http://dev.gentoo.org/~robbat2/conf.d-net/
> Includes dual-homing, multi-homing, and HE.net IPv6 tunnels.
> I wrote a lot of the original bonding, vlan, mac-changer, bridging code
> in BL1.
>
> Better documentation on how to set up the complex network configs would
> be great, but the net.example is too long already.
>
>    

I passed the link on to him.  I'll let you know if it helps.  If he 
comes up with anything that can be added to the docs, I'll post them on 
-doc.  Maybe someone can take it from there.

Sometimes docs can be to long but I have always found this to be 
useful.  Have a simple setup first then follow that with the complicated 
stuff and let it get more complicated as it goes deeper down.  That 
helps the simple setups quickly but still provides needed info for folks 
with the complicated setups.  I wish some things were longer sometimes.  
USE descriptions is one of those at times.

Thanks.

Dale

:-)  :-)

Re: [gentoo-dev] Re: Warn users not to do separate /usr partition without proper initramfs in the handbook?

[Dale]

Sven Vermeulen wrote:
> On Tue, Aug 16, 2011 at 09:22:30AM -0500, Dale wrote:
>    
>> Thanks for the reply.  I also agree that the docs should be ready first
>> then the change.  I have a friend that may be switching from Gentoo because
>> he can not get good docs on how to get his network working after the OpenRC
>> update.  It appears the docs he needs aren't ready yet.  What's the point
>> of having a nice Gentoo install if you can't set up your network stuff?
>>      
> I know, major apologies...
>
> The documents (more specific, the Gentoo Handbook and a few other
> high-profile ones) have been updated recently (last few days) so they should
> be okay now. However, some good reviews never hurt.
>
> If you do still find issues, don't hesitate to create a bugreport for it.
>
> Wkr,
> 	Sven Vermeulen
>
>    

Allow me to start this way.  If you change a page, send me a link, 
offlist if you want, and I'll read it and see if I see anything that 
needs to be changed.  I'm pretty good at typos and I been around Gentoo 
long enough to see a bad command or option for the most part.  I know 
ZERO about xml tho.  I do know the docs team is short handed.  There is 
only so much one or two people can do.

Oh, I also only know English too.  Sometimes I wonder about that one.  lol

Dale

:-)  :-)

Re: [gentoo-dev] Re: Warn users not to do separate /usr partition without proper initramfs in the handbook?

[Jeremy Olexa]

On 08/16/2011 09:01 PM, Dale wrote:

> Allow me to start this way. If you change a page, send me a link,

http://archives.gentoo.org/gentoo-doc-cvs/