[gentoo-dev] newsitem: unmasking udev-181

[gentoo-dev] newsitem: unmasking udev-181

[William Hubbs]

[-- Attachment #1.1: Type: text/plain, Size: 125 bytes --]

All,

here is the udev 181 unmasking news item.

If all goes well, this will be committed to the tree  on 3/14 UTC.

William

[-- Attachment #1.2: 2012-03-14-udev-181-unmasking.en.txt --]
[-- Type: text/plain, Size: 857 bytes --]

Title: udev-181 unmasking
Author: William Hubbs <williamh@gentoo.org>
Content-Type: text/plain
Posted: 2012-03-14
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: <sys-fs/udev-181

udev-181 is being unmasked the same day this newsitem is being published.

This news item is to inform you that once you upgrade to a version of
udev >=181, if you have /usr on a separate partition, you must boot your
system with an initramfs which pre-mounts /usr.

An initramfs which does this is created by >=sys-kernel/genkernel-3.4.25 or
>=sys-kernel/dracut-017-r1. If you do not want to use these tools, be
sure any initramfs you create pre-mounts /usr.

Also, if you are using OpenRC, you must upgrade to >= openrc-0.9.9.

For more information on why this has been done, see the following url:
http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken

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

[gentoo-dev] Re: newsitem: unmasking udev-181

[Rich Freeman]

On Sat, Mar 10, 2012 at 9:27 PM, William Hubbs <williamh@gentoo.org> wrote:
> here is the udev 181 unmasking news item.
>
> If all goes well, this will be committed to the tree  on 3/14 UTC.

I guess this might be OK for unstable, but before this goes stable we
really need to improve the docs around this.  As far as I can tell
neither the genkernel nor dracut docs have specific instructions about
how to handle mounting /usr.  Since having a separate /usr is often
the result of having a more complex configuration (nfs, lvm, mdraid,
etc), instructions explaining how things work and how to handle
variations is pretty important.  Perhaps genkernel automagically does
the right thing in some cases, but I know that dracut does not unless
you properly configure it.  I doubt either tool will handle more
complex situations without some scripting.

I'm not really asking for automation here - just documentation and
reasonable stability in how things work.

Again, this is likely more of a concern before this is stabilized.
However, knowing what I went through to get my bind-mounted /usr on
LVM+mdraid working with dracut, I can imagine that any unstable users
with tricky setups could face a fun weekend.

Perhaps a suggestion for the news item.  I'd recommend that anybody
who needs an initramfs to mount /usr get that working BEFORE they
upgrade udev.  This situation is a heck of a lot easier to figure out
if the system still can be booted when the initramfs doesn't work.

Rich

Re: [gentoo-dev] Re: newsitem: unmasking udev-181

[Luca Barbato]

On 3/10/12 6:53 PM, Rich Freeman wrote:
> neither the genkernel nor dracut docs have specific instructions about

I guess we could pour more effort in getting dracut more easy to use 
and/or try to figure out which are the items that should be moved to / 
and fix the remaining ones...

lu

Re: [gentoo-dev] Re: newsitem: unmasking udev-181

[Rich Freeman]

On Sat, Mar 10, 2012 at 10:28 PM, Luca Barbato <lu_zero@gentoo.org> wrote:
> I guess we could pour more effort in getting dracut more easy to use and/or
> try to figure out which are the items that should be moved to / and fix the
> remaining ones...
>

Well, I'm trying not to take sides in that war.  Unless we want to
patch the living daylights out of upsteam it seems almost moot.

I'm not even so much interested in making dracut easy to use.  I'd
just appreciate it if there were even a single sentence written on
each of its modules and options, let alone some kind of coherent guide
to how to make it all work.

There is a guide out there, but it hasn't really kept pace with the
very rapidly evolving tool, and it doesn't really cover all the
nuances.

Another useful thing would be to update our official RAID+LVM guide so
that when you're done following it your system will boot.

Rich

Re: [gentoo-dev] Re: newsitem: unmasking udev-181

[Luca Barbato]

On 3/10/12 7:50 PM, Rich Freeman wrote:
> Well, I'm trying not to take sides in that war.  Unless we want to
> patch the living daylights out of upsteam it seems almost moot.

It is not a matter about siding. If our boot process requires glib or 
dbus we are sore idiots if we aren't either of them available by that time.

Luckily we do not *need* that at boot time but we can use daemons 
leveraging it after the file system hosting them is mounted.

Same could be said for udev rules. If udev by itself can survive on the 
bare / till we mount our filesystem we are fine, if it does need to 
access the pci-id database we have either to provide it in a way or another.

> I'm not even so much interested in making dracut easy to use.  I'd
> just appreciate it if there were even a single sentence written on
> each of its modules and options, let alone some kind of coherent guide
> to how to make it all work.

That would be great.

> There is a guide out there, but it hasn't really kept pace with the
> very rapidly evolving tool, and it doesn't really cover all the
> nuances.

Ouch.

> Another useful thing would be to update our official RAID+LVM guide so
> that when you're done following it your system will boot.

indeed.

Re: [gentoo-dev] Re: newsitem: unmasking udev-181

[William Hubbs]

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

On Sat, Mar 10, 2012 at 07:28:41PM -0800, Luca Barbato wrote:
> On 3/10/12 6:53 PM, Rich Freeman wrote:
> > neither the genkernel nor dracut docs have specific instructions about
> 
> I guess we could pour more effort in getting dracut more easy to use 
> and/or try to figure out which are the items that should be moved to / 
> and fix the remaining ones...

I highly discourage moving more things to /.  If you google for things
like, "case for usr merge", "understanding bin split", etc, you will
find much information that is very enlightening about the /usr merge and
the reasons for the /bin, /lib, /sbin -> /usr/* split.

I'll start another thread about this farely soon, but for now I'll say
that even though Fedora is a strong advocate of the /usr merge, it
didn't start there. Solaris started this 15 years ago, and I think it
would be a good thing for gentoo to implement the /usr merge at some
point to make us more compatible with other unixes. Another thing to add
is that it appears that at least Fedora and Debian are doing this.

William


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

Re: [gentoo-dev] Re: newsitem: unmasking udev-181

[Samuli Suominen]

On 03/11/2012 07:33 PM, William Hubbs wrote:
> On Sat, Mar 10, 2012 at 07:28:41PM -0800, Luca Barbato wrote:
>> On 3/10/12 6:53 PM, Rich Freeman wrote:
>>> neither the genkernel nor dracut docs have specific instructions about
>>
>> I guess we could pour more effort in getting dracut more easy to use
>> and/or try to figure out which are the items that should be moved to /
>> and fix the remaining ones...
>
> I highly discourage moving more things to /.  If you google for things
> like, "case for usr merge", "understanding bin split", etc, you will
> find much information that is very enlightening about the /usr merge and
> the reasons for the /bin, /lib, /sbin ->  /usr/* split.

Indeed. I thought we got past this already and started moving things to 
/usr [1][2]

http://bugs.gentoo.org/398081
http://bugs.gentoo.org/403073

More to follow...

Re: [gentoo-dev] Re: newsitem: unmasking udev-181

[Michał Górny]

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

On Sun, 11 Mar 2012 19:35:36 +0200
Samuli Suominen <ssuominen@gentoo.org> wrote:

> On 03/11/2012 07:33 PM, William Hubbs wrote:
> > On Sat, Mar 10, 2012 at 07:28:41PM -0800, Luca Barbato wrote:
> >> On 3/10/12 6:53 PM, Rich Freeman wrote:
> >>> neither the genkernel nor dracut docs have specific instructions
> >>> about
> >>
> >> I guess we could pour more effort in getting dracut more easy to
> >> use and/or try to figure out which are the items that should be
> >> moved to / and fix the remaining ones...
> >
> > I highly discourage moving more things to /.  If you google for
> > things like, "case for usr merge", "understanding bin split", etc,
> > you will find much information that is very enlightening about
> > the /usr merge and the reasons for the /bin, /lib, /sbin ->  /usr/*
> > split.
> 
> Indeed. I thought we got past this already and started moving things
> to /usr [1][2]
> 
> http://bugs.gentoo.org/398081
> http://bugs.gentoo.org/403073

I've just reported executables which are broken without /usr mounted.
Some devs moved them to /usr, others moved libraries to /.

-- 
Best regards,
Michał Górny

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

[gentoo-dev] Let's redesign the entire filesystem! [was newsitem: unmasking udev-181]

[Joshua Kinard]

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

On 03/11/2012 13:33, William Hubbs wrote:

> I highly discourage moving more things to /.  If you google for things 
> like, "case for usr merge", "understanding bin split", etc, you will
> find much information that is very enlightening about the /usr merge and
> the reasons for the /bin, /lib, /sbin -> /usr/* split.
> 
> I'll start another thread about this farely soon, but for now I'll say 
> that even though Fedora is a strong advocate of the /usr merge, it
> didn't start there. Solaris started this 15 years ago, and I think it
> would be a good thing for gentoo to implement the /usr merge at some
> point to make us more compatible with other unixes. Another thing to add
> is that it appears that at least Fedora and Debian are doing this.



On a somewhat sarcastic note, why don't we just deprecate /usr and move
everything back to /?  Isn't that, largely, what is being accomplished here?
 Solaris at least keeps some kernel stuff in / off of /stand (I believe).
Linux, after this /usr thing is fully complete, about the only thing left in
/ that is of any value will be /etc.  Kernels were moved into /boot ages ago.

I mean, what really is / in the literal sense?  It's the first filesystem
that the kernel mounts.  If you put everything into /usr, including the init
scripts and /etc, create a few stub mount points for /var, /tmp, etc
(assuming those are separate partitions), then told the kernel that /usr is
/, what's the real difference?  So I think Fedora's approach, while copying
existing behavior from Solaris, is partially broken in this regard.

We should be working to getting rid of /usr and bring it all back into /,
then create temporary /usr symlinks to point programs in the right
direction.  After all, /usr was originally for user data, not system data,
until someone cooked up /home (I don't know the full exact history here, so
feel free to correct me).

Heck, why not redesign the original root filesystem layout while we're at it?

/     - Root.
/boot - Kernels, bootloader.
/apps - Installed, non-system critical applications.  Merges /bin,
        /sbin, /usr/{bin,sbin}, /usr/local/{bin,sbin}, and /lib and
        all of its multilib variants.
/core - System-critical apps needed to get the system into a MINIMAL,
        usable state (core device detection, mounting disks, etc)
/conf - System configuration data.
/dev  - Device nodes.
/home - User stuff.
/data - Variable data.  /var's new name.
/tmp  - System-wide temp dir.
/virt - virtual filesystems (proc, sys, ramfs).
/svcs - Data dir for services (Apache, LDAP, FTP, etc).
/ext  - holds mount points for external devices (merges /mnt & /media).
/root - Superuser's /home.


From that, for the new proposed directories:

/apps/sys/bin - System binaries.  Only non-critical, system-wide binaries
                go here.
/apps/sys/lib - Like /apps/sys/bin above.  Except this can also be
                duplicated for multilib (lib32, lib64, lib128, etc).

/apps/std/bin - Standard program binaries for all non-system, non-critical
                binaries.
/apps/std/lib - Like /apps/std/bin above.  Ditto for multilib.

/apps/local   - If on a stand-alone system, this is a symlink to /apps/std.
                otherwise, this holds a bin/lib folder that is only for apps
                installed locally, while /apps/std might be a network mount
                that holds apps common to multiple systems of the
                same/similar type of install.

/core/bin     - Critical system, binaries needed to get the system into a
                minimally-usable state.  Predominantly occupied by various
                filesystem tools.
/core/lib     - Libraries, usually static, to support /core/bin.  Can be
                multilib, but a system should have a single ABI that can
                successfully boot the userland components of the system.
/core/inf     - Holds minimal information to identify and locate
                boot-critical devices, typically in the form of a small
                database of some design, but which can be parsed with
                no additional dependencies.
/core/init    - Home of your init system of choice, including all the
                information needed for various run levels, etc.  Its
                sub-layout is dependent on the particular init system that
                is installed.

/conf         - Basically a rename of /etc.  The "etc" name doesn't
                convey any useful information to a user anymore about its
                true purpose.  /conf, however, does.  Files stored here
                will largely be comprised of text files that configure
                various system services.  Like /etc, it's sub-layout will
                probably be a complete, unrestrained mess.

/virt         - Everyone loves virtual filesystems.  When there was just
                /proc, everything was alright.  Then /sys comes along, and
                now we've polluted the / namespace with two virtual
                filesystems.  /virt provides a home for those (so /virt/proc
                and /virt/sys), in addition to others like /virt/shm,
                and /virt/pts, or even /virt/ramfs if you want.  Anything
                in here doesn't physically exist, and either changes rapidly
                or is lost once the system loses power.

/data         - Like "etc", /var's original function has been largely
                overridden and hardly contains "variable" data anymore.
                thus, it is reborn as /data, which conveys *exactly* what
                it is for -- data of some kind, whose presence may be
                permanent or transitory.  Mail spools, caches, print spools,
                whatever.  Fill it with data from /dev/urandom if you want!

/svcs         - Like /srv, which some people are resistant to using.  The
                original idea is quite a marvel, though, because it never
                really made any sense to stick Apache into /var/www, or hang
                the TFTP boot directory off of /, or chroot BIND inside of
                /etc or /var (or both).

/ext          - A place for external mounts, either filesystems or devices.
                NFS, CD-ROMs, thumb drives, Samba/CIFS, etc, it goes here.
                This replaces both /mnt and /media, the only difference
                between the two being the same as the difference between
                two shades of purple.  The only exception to this rule is
                /apps/local above.

All other directories retain their original, standard functionality.


I thought this up on a whim, it hasn't been tested nor vetted.  It's largely
meant as a joke, but also to provoke discussion on the current filesystem
design and the direction we're getting pulled in with Fedora's declaration
that separate /usr is broken.  I don't think it is and I don't find their
argument very convincing, and probably never will.

At some point after this change becomes fully adopted (and it will, trust
me), the difference between the / of old and /usr will be so minor, that you
could probably move a few files around, chop /usr off into a separate
partition, and then pass root=/dev/<where /usr is>, and bring a system fully
online, *without a /usr*.  And then, after that, someone will come along and
propose "the new /usr", and the cycle repeats.

But I do, hesitantly, agree that the standard UNIX filesystem has a lot of
"traditions" to it that don't make a lot of sense anymore.  It's a hallmark
of an era where machines usually kept a local copy of stuff needed to start
or stop themselves.  Now we're in an era where machines aren't even physical
anymore.  The location of actual data is somewhat meaningless, if you write
a program correctly and don't hardcode filesystem paths.

So it's probably time to have some kind of a discussion on the filesystem,
and what would need to change to bring it up to date with the era of
large-scale virtualization and embedded systems that run on your wristwatch,
in addition to the standard black (or beige) box sitting on a desk somewhere.

Food for thought.  And yes, I've already tested out udev-181 on a VM with a
separate /usr.  With devtmpfs, the system fully boots just fine, no
initramfs needed.  Guess what the only piece of software to mess up is?
Udev.  I largely think it's a timing issue in OpenRC, however, because /usr
DOES get mounted fairly quickly, but not before udevd starts.  But udevd
does restart itself and everything looks to work fine.  If you aren't
watching the terminal, you wouldn't even notice the failures.

Cheers,

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

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

--Emperor Turhan, Centauri Republic


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

Re: [gentoo-dev] Let's redesign the entire filesystem! [was newsitem: unmasking udev-181]

[Kent Fredric]

On 13 March 2012 14:22, Joshua Kinard <kumba@gentoo.org> wrote:
> I thought this up on a whim, it hasn't been tested nor vetted.  It's largely
> meant as a joke, but also to provoke discussion on the current filesystem
> design and the direction we're getting pulled in with Fedora's declaration
> that separate /usr is broken.  I don't think it is and I don't find their
> argument very convincing, and probably never will.
>

Why don't we just quit with this linux nonsense and all switch to Mac,
after all, it just works!

</cynical remarks>

=p


-- 
Kent

perl -e  "print substr( \"edrgmaM  SPA NOcomil.ic\\@tfrken\", \$_ * 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"

Re: [gentoo-dev] Let's redesign the entire filesystem! [was newsitem: unmasking udev-181]

[Joshua Kinard]

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

On 03/12/2012 21:37, Kent Fredric wrote:

> On 13 March 2012 14:22, Joshua Kinard <kumba@gentoo.org> wrote:
>> I thought this up on a whim, it hasn't been tested nor vetted.  It's largely
>> meant as a joke, but also to provoke discussion on the current filesystem
>> design and the direction we're getting pulled in with Fedora's declaration
>> that separate /usr is broken.  I don't think it is and I don't find their
>> argument very convincing, and probably never will.
>>
> 
> Why don't we just quit with this linux nonsense and all switch to Mac,
> after all, it just works!
> 
> </cynical remarks>
> 
> =p


The problem with that, is, that the system wouldn't boot without /itunes
being available, so you can't partition that one off :P

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

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

--Emperor Turhan, Centauri Republic


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

Re: [gentoo-dev] Let's redesign the entire filesystem! [was newsitem: unmasking udev-181]

[Ian Stakenvicius]

On 2012-03-12, at 9:22 PM, Joshua Kinard <kumba@gentoo.org> wrote:

> 
> And yes, I've already tested out udev-181 on a VM with a
> separate /usr.  With devtmpfs, the system fully boots just fine, no
> initramfs needed.  Guess what the only piece of software to mess up is?
> Udev.  I largely think it's a timing issue in OpenRC, however, because /usr
> DOES get mounted fairly quickly, but not before udevd starts.  But udevd
> does restart itself and everything looks to work fine.  If you aren't
> watching the terminal, you wouldn't even notice the failures.
> 


THANK YOU for testing this -- I could not forsee a reason, back when this process started, as to why openrc couldn't mount /usr before udev started.   since devtmpfs should provide the source devnode anyways.  It's good to have a (near) proof of that.

Ian

Re: [gentoo-dev] Let's redesign the entire filesystem! [was newsitem: unmasking udev-181]

[Joshua Kinard]

[-- Attachment #1.1: Type: text/plain, Size: 1675 bytes --]

On 03/12/2012 22:33, Ian Stakenvicius wrote:

> 
> On 2012-03-12, at 9:22 PM, Joshua Kinard <kumba@gentoo.org> wrote:
> 
>>
>> And yes, I've already tested out udev-181 on a VM with a
>> separate /usr.  With devtmpfs, the system fully boots just fine, no
>> initramfs needed.  Guess what the only piece of software to mess up is?
>> Udev.  I largely think it's a timing issue in OpenRC, however, because /usr
>> DOES get mounted fairly quickly, but not before udevd starts.  But udevd
>> does restart itself and everything looks to work fine.  If you aren't
>> watching the terminal, you wouldn't even notice the failures.
>>
> 
> 
> THANK YOU for testing this -- I could not forsee a reason, back when this process started, as to why openrc couldn't mount /usr before udev started.   since devtmpfs should provide the source devnode anyways.  It's good to have a (near) proof of that.
> 
> Ian

Yeah, I think it's an easy fix either in openrc or in an initscript
somewhere.  I changed nothing except my kernel (was missing devtmpfs -- it's
not under Filesystems!), uninstalled module-init-tools, and installed kmod +
udev-181.  Then rolled back the snapshot once I had the results.

See the attached PNG for the boot output I was able to grab before something
clears the screen.  There was a few extra lines after this, but I'm not that
fast on the screencap button.

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

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

--Emperor Turhan, Centauri Republic

[-- Attachment #1.2: udev-181-test.png --]
[-- Type: image/png, Size: 82494 bytes --]

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

Re: [gentoo-dev] Let's redesign the entire filesystem! [was newsitem: unmasking udev-181]

[Robin H. Johnson]

On Mon, Mar 12, 2012 at 11:14:23PM -0400, Joshua Kinard wrote:
> Yeah, I think it's an easy fix either in openrc or in an initscript
> somewhere.  I changed nothing except my kernel (was missing devtmpfs -- it's
> not under Filesystems!), uninstalled module-init-tools, and installed kmod +
> udev-181.  Then rolled back the snapshot once I had the results.
When udev is linked against a library in /usr, this is not going to work
anymore, because udev won't start at all.

On many simple setups, yes, it's not going actually break much in my
testing on pure OpenRC.

udev starts in the sysinit runlevel, and /usr would normally only become
available later, in the boot runlevel, when localmount runs...

Consider this potential boot order:
sysinit/sysfs
sysinit/udev (fails without sysfs)
boot/modules (after udev, so udev rules work on modprobe)
boot/hwclock (needs rtc modules on some systems)
boot/fsck (after devices are available)
boot/root (after fsck)
boot/localmount (after fsck)

udev before modules is fairly critical for some hardware, so that it
gets configured properly.

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

Re: [gentoo-dev] Let's redesign the entire filesystem! [was newsitem: unmasking udev-181]

[Luca Barbato]

On 3/12/12 8:53 PM, Robin H. Johnson wrote:
> On Mon, Mar 12, 2012 at 11:14:23PM -0400, Joshua Kinard wrote:
>> Yeah, I think it's an easy fix either in openrc or in an initscript
>> somewhere.  I changed nothing except my kernel (was missing devtmpfs -- it's
>> not under Filesystems!), uninstalled module-init-tools, and installed kmod +
>> udev-181.  Then rolled back the snapshot once I had the results.
> When udev is linked against a library in /usr, this is not going to work
> anymore, because udev won't start at all.

So you need need a smaller udev that is completely self contained and 
make sure anything needed for the key rules works. I wonder if the 
pci-ids cannot stay somewhere in /etc or /lib

lu

Re: [gentoo-dev] Let's redesign the entire filesystem! [was newsitem: unmasking udev-181]

[Joshua Kinard]

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

On 03/13/2012 01:17, Luca Barbato wrote:

> 
> So you need need a smaller udev that is completely self contained and make
> sure anything needed for the key rules works. I wonder if the pci-ids cannot
> stay somewhere in /etc or /lib
> 
> lu


I think gregkh is already on record as saying that the pci-ids file is going
to go into /usr and stay there.  The errors I got weren't from that, though,
it was the init scripts trying to find udevadm, and then not finding
libkmod, which was likely installed into /usr/lib64.

I guess I don't run a "standard" Linux system anymore.  I build a fairly
monolithic kernel that contains device drivers for all the hardware in the
machine needed to get it up and running, while miscellaneous modules (like
CIFS or the Happy MEal quad ethernet card) are modulues.  My MIPS systems
all run pure monolithic, completely lacking module support entirely.

The trend now seems to be to modularize everything these days, even stuff
like the core disk drivers, then build those core modules into an initramfs
that the kernel cherrypicks from at boot.  That's the perception, anyways,
and one which I don't really get.

Correct me if I'm wrong...

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

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

--Emperor Turhan, Centauri Republic


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

Re: [gentoo-dev] Let's redesign the entire filesystem! [was newsitem: unmasking udev-181]

[Rich Freeman]

On Tue, Mar 13, 2012 at 8:20 PM, Joshua Kinard <kumba@gentoo.org> wrote:
> The trend now seems to be to modularize everything these days, even stuff
> like the core disk drivers, then build those core modules into an initramfs
> that the kernel cherrypicks from at boot.  That's the perception, anyways,
> and one which I don't really get.

Well, on most distros the kernel is just another package that is the
same on every box.  If you want one kernel for every PC, then it needs
to support every piece of hardware in existence.  So, either it is
highly modular, or it is going to suck up a ton of RAM.

The solution is a one-size-fits-all kernel, combined with a
one-size-fits-all initramfs.

For Gentoo where people build their own kernels, it doesn't make as much sense.

Rich

Re: [gentoo-dev] Let's redesign the entire filesystem! [was newsitem: unmasking udev-181]

[Ian Stakenvicius]

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

On 12/03/12 11:14 PM, Joshua Kinard wrote:
> On 03/12/2012 22:33, Ian Stakenvicius wrote:
> 
>> 
>> On 2012-03-12, at 9:22 PM, Joshua Kinard <kumba@gentoo.org>
>> wrote:
>> 
>>> 
>>> And yes, I've already tested out udev-181 on a VM with a
>>> separate /usr.  With devtmpfs, the system fully boots just
>>> fine, no initramfs needed.  Guess what the only piece of
>>> software to mess up is? Udev.  I largely think it's a timing
>>> issue in OpenRC, however, because /usr DOES get mounted fairly
>>> quickly, but not before udevd starts.  But udevd does restart
>>> itself and everything looks to work fine.  If you aren't
>>> watching the terminal, you wouldn't even notice the failures.
>>> 
>> 
>> 
>> THANK YOU for testing this -- I could not forsee a reason, back 
>> when this process started, as to why openrc couldn't mount /usr 
>> before udev started.   since devtmpfs should provide the source 
>> devnode anyways.  It's good to have a (near) proof of that.
>> 
>> Ian
> 
> Yeah, I think it's an easy fix either in openrc or in an initscript
>  somewhere.  I changed nothing except my kernel (was missing
> devtmpfs -- it's not under Filesystems!), uninstalled
> module-init-tools, and installed kmod + udev-181.  Then rolled back
> the snapshot once I had the results.

Ah, right; kmod.. Tthere's pressure for that one to move to /usr
too, isn't there mgorny? ....  ok, nvm.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)

iF4EAREIAAYFAk9fTXIACgkQAJxUfCtlWe3RQQD8DIr8mZ773vIqhIxf5ERYWo8E
ZkfDgAUlUDF7hcDiuUIA/1amWFFZcVu36V6vikq4HGF0we43YYMVLW6b96SblGzN
=dKid
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Let's redesign the entire filesystem! [was newsitem: unmasking udev-181]

[Jeroen Roovers]

On Mon, 12 Mar 2012 21:22:26 -0400
Joshua Kinard <kumba@gentoo.org> wrote:

> On a somewhat sarcastic note, why don't we just deprecate /usr and
> move everything back to /?  Isn't that, largely, what is being
> accomplished here? Solaris at least keeps some kernel stuff in / off
> of /stand (I believe). Linux, after this /usr thing is fully
> complete, about the only thing left in / that is of any value will
> be /etc.  Kernels were moved into /boot ages ago.

A bit like stali? http://sta.li/

Or is that still too complicated? :)


     jer

Re: [gentoo-dev] Let's redesign the entire filesystem! [was newsitem: unmasking udev-181]

[James Broadhead]

On 13 March 2012 01:22, Joshua Kinard <kumba@gentoo.org> wrote:
> We should be working to getting rid of /usr and bring it all back into /,
> then create temporary /usr symlinks to point programs in the right
> direction.  After all, /usr was originally for user data, not system data,
> until someone cooked up /home (I don't know the full exact history here, so
> feel free to correct me).
>

I believe that the Art of Unix Programming* says that /usr was the
result of the original UNIX 4MB hard disk becoming full, and that they
chose /usr to mount a second one. Every definition since then has been
an attempt to justify preserving the split.


* On reflection, I may have read this elsewhere.

Re: [gentoo-dev] Let's redesign the entire filesystem! [was newsitem: unmasking udev-181]

[Joshua Kinard]

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

On 03/13/2012 07:54, James Broadhead wrote:

> On 13 March 2012 01:22, Joshua Kinard <kumba@gentoo.org> wrote:
>> We should be working to getting rid of /usr and bring it all back into /,
>> then create temporary /usr symlinks to point programs in the right
>> direction.  After all, /usr was originally for user data, not system data,
>> until someone cooked up /home (I don't know the full exact history here, so
>> feel free to correct me).
>>
> 
> I believe that the Art of Unix Programming* says that /usr was the
> result of the original UNIX 4MB hard disk becoming full, and that they
> chose /usr to mount a second one. Every definition since then has been
> an attempt to justify preserving the split.


Sounds like how a lot of UNIXy things came into being.  This is why I think
/usr should be merged back into /, not the other way around.  Although, both
approaches essentially achieve the same effect in the end, once you move
/etc and a few other bits, then point the kernel at "/usr".

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

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

--Emperor Turhan, Centauri Republic


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

[gentoo-dev] Re: Let's redesign the entire filesystem! [was newsitem: unmasking udev-181]

[Duncan]

Joshua Kinard posted on Tue, 13 Mar 2012 20:16:10 -0400 as excerpted:

> On 03/13/2012 07:54, James Broadhead wrote:
> 
>> I believe that the Art of Unix Programming* says that /usr was the
>> result of the original UNIX 4MB hard disk becoming full, and that they
>> chose /usr to mount a second one. Every definition since then has been
>> an attempt to justify preserving the split.
> 
> Sounds like how a lot of UNIXy things came into being.  This is why I
> think /usr should be merged back into /, not the other way around. 
> Although, both approaches essentially achieve the same effect in the
> end, once you move /etc and a few other bits, then point the kernel at
> "/usr".

I've seen it pointed out that in initr* based systems anyway, the "new" 
rootfs is effectively taking the role the old initrd tmproot did, it's 
only there in a bootstrapping role, no "running system" content at all, 
except that instead of using pivot_root or whatever to get off it once 
the system early bootstrap is done, it remains the mountpoint used by 
everything else on the running system.

That's rootfs's only modern role, according to these folks, providing the 
mountpoints for everything else.

And with an assumed initr* based setup, it all "just works".  Rootfs can 
in fact be entirely virtual, tmpfs or squashfs or whatever, setup only in 
the initr*, with only a few minimal early-boot config files, the modules 
necessary to boot the rest of the system, etc, as content, and those 
quickly over-mounted with the "real" system -- note that /usr/etc can be 
bind-mounted over the boot-time-stub /etc too, so literally, post-initr*, 
the ONLY part of rootfs operationally visible is the mountpoints used by 
everything else.

THAT is why they're moving /bin, /sbin and /lib to /usr rather than the 
other direction.  rootfs will be ONLY a mountpoint, with even /etc/ being 
bind-mounted from /usr/etc, and all system data unified on /usr, 
including /etc.

Viewed from that perspective, the direction of the "unification", 
everything formerly on rootfs moving to /usr, so rootfs' only function is 
providing the mountpoints for everything else, has a certain logic to 
it...

And they don't care about non-initr* based systems any more than they 
care about non-Linux systems or for that matter, non-systemd Linux 
systems.  That's outside their operational universe.  Other people are 
welcome to continue working with "legacy" systems if they want, but Linux-
only, systemd-based, initr*-based systems are the only thing they're 
interested in supporting, themselves.

-- 
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: Let's redesign the entire filesystem!

[Joshua Kinard]

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

On 03/14/2012 04:39, Duncan wrote:

> 
> THAT is why they're moving /bin, /sbin and /lib to /usr rather than the 
> other direction.  rootfs will be ONLY a mountpoint, with even /etc/ being 
> bind-mounted from /usr/etc, and all system data unified on /usr, 
> including /etc.
> 
> Viewed from that perspective, the direction of the "unification", 
> everything formerly on rootfs moving to /usr, so rootfs' only function is 
> providing the mountpoints for everything else, has a certain logic to 
> it...


From one perspective, this makes sense.  It actually is a kinda of holy
grail for administrators, because it's one less filesystem to worry about
backing up.


> And they don't care about non-initr* based systems any more than they 
> care about non-Linux systems or for that matter, non-systemd Linux 
> systems.  That's outside their operational universe.  Other people are 
> welcome to continue working with "legacy" systems if they want, but Linux-
> only, systemd-based, initr*-based systems are the only thing they're 
> interested in supporting, themselves.


You know, I would have no problem with this if it wasn't a decision made by
a single Linux distro with a huge amount of clout in the Linux world.  This
isn't like Debian forking Firefox into Ice Weasel, an issue that largely
remains Debian-specific to this day.  This is a change that will
fundamentally alter the way every distro does things, and none of us (as far
as I know) were given a choice in the matter.

The /usr move is going to happen.  I, along with a lot of other people, are
going to have to "fix" all my installed systems over this.  Not because of a
choice made by all distros, but because one distro thinks that its way is
the RightWay() and the OnlyWay().

That's what I disagree with.  We shouldn't be affected by this change.  Only
Fedora users should have to deal with it.  But other upstream projects are
going to follow in Fedora's lead, and this brings us up to a decision point:
adapt, or become irrelevant.

I chose to stick with Gentoo as my distro of choice because I didn't like
the way Red Hat did things years ago.  As well as a few other nitpicks I
have.  It bugs me to no end that, despite running a fairly vanilla setup on
a source-based distro whose original inspiration came from BSD ports, I am
still affected by a decision made by RH.

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

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

--Emperor Turhan, Centauri Republic


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

Re: [gentoo-dev] Re: Let's redesign the entire filesystem!

[Greg KH]

On Wed, Mar 14, 2012 at 08:40:46AM -0400, Joshua Kinard wrote:
> I chose to stick with Gentoo as my distro of choice because I didn't like
> the way Red Hat did things years ago.  As well as a few other nitpicks I
> have.  It bugs me to no end that, despite running a fairly vanilla setup on
> a source-based distro whose original inspiration came from BSD ports, I am
> still affected by a decision made by RH.

It is not a decision made by RH, some of the developers involved just
happen to work for that distro.  Others of us do not.  Please don't get
this confused with distro specific politics, it's not that at all.

And again, if you have /usr on a different filesystem today, with no
initrd, your machine could be broken and you don't even know it.

greg "why is this thread still alive" k-h

Re: [gentoo-dev] Re: Let's redesign the entire filesystem!

[Philip Webb]

120314 Greg KH wrote:
> if you have /usr on a different filesystem today, with no initrd,
> your machine could be broken and you don't even know it.

Whatever do you mean ? -- if it were truly broken,
it wouldn't perform in some important & obvious respect.
Do you mean "insecure" ? -- if so, what is the threat ?

> greg "why is this thread still alive" k-h

Your dismissive response is perhaps one reason ...

-- 
========================,,============================================
SUPPORT     ___________//___,   Philip Webb
ELECTRIC   /] [] [] [] [] []|   Cities Centre, University of Toronto
TRANSIT    `-O----------O---'   purslowatchassdotutorontodotca

Re: [gentoo-dev] Re: Let's redesign the entire filesystem!

[Greg KH]

On Wed, Mar 14, 2012 at 10:51:44AM -0400, Philip Webb wrote:
> 120314 Greg KH wrote:
> > if you have /usr on a different filesystem today, with no initrd,
> > your machine could be broken and you don't even know it.
> 
> Whatever do you mean ? -- if it were truly broken,
> it wouldn't perform in some important & obvious respect.

Not always, no, it isn't obvious that something didn't start up
correctly, or that it didn't fully load properly.  Some programs later
on recover and handle things better.

> Do you mean "insecure" ? -- if so, what is the threat ?

No threat.

> > greg "why is this thread still alive" k-h
> 
> Your dismissive response is perhaps one reason ...

Given that this is the first time I've responded to this thread in
weeks, I doubt it.  People like to complain, that's nothing new, I
should be used to it by now, so perhaps it is all my fault...

greg k-h

Re: [gentoo-dev] Re: Let's redesign the entire filesystem!

[Ciaran McCreesh]

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

On Wed, 14 Mar 2012 08:04:31 -0700
Greg KH <gregkh@gentoo.org> wrote:
> Not always, no, it isn't obvious that something didn't start up
> correctly, or that it didn't fully load properly.  Some programs later
> on recover and handle things better.

So why not work on fixing those things, since they're clearly symptoms
of a larger "oops, we have too much coupling" problem, instead of
forcing a workaround onto large numbers of users?

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Re: Let's redesign the entire filesystem!

[Greg KH]

On Wed, Mar 14, 2012 at 03:08:27PM +0000, Ciaran McCreesh wrote:
> On Wed, 14 Mar 2012 08:04:31 -0700
> Greg KH <gregkh@gentoo.org> wrote:
> > Not always, no, it isn't obvious that something didn't start up
> > correctly, or that it didn't fully load properly.  Some programs later
> > on recover and handle things better.
> 
> So why not work on fixing those things, since they're clearly symptoms
> of a larger "oops, we have too much coupling" problem, instead of
> forcing a workaround onto large numbers of users?

I seriously doubt there are a "large number" of users here that have
this issue.

And even if there is, again, there is a simple solution that Gentoo
provides for this issue, see the earlier initrd solution that we support
today.

As for "fixing this", see the oft-linked webpage as to why it can't be
fixed easily, if at all, and honestly, I don't think it needs to be
fixed.

Especially as NO ONE has ever stepped up to fix these issues, which
proves that no one is really invested in it.

As for "too much coupling", you are talking to the wrong person.
Personally, I feel we are too lightly coupled, and need to have stronger
links happening here in order to properly solve the problems that we
have in this area.

If you disagree with the coupling issue, fine, but again, you need to do
the work, and properly understand the issues involved.  The people doing
the work today do understand them, by virtue of doing the work involved,
which gives them the say in how it is done.  That's how open source
works, why is this ever a surprise to people?

I'll go back to lurking now, and getting stuff done, like everyone else
on this thread should be doing, instead of complaining (this is -dev,
not -users...)

greg k-h

Re: [gentoo-dev] Re: Let's redesign the entire filesystem!

[Ciaran McCreesh]

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

On Wed, 14 Mar 2012 08:22:09 -0700
Greg KH <gregkh@gentoo.org> wrote:
> The people doing the work today do understand them, by virtue of
> doing the work involved, which gives them the say in how it is done.
> That's how open source works, why is this ever a surprise to people?

The problem is that when a small number of people who have commit
access to core projects screw everything up and don't fix the mess
they're inflicting upon everyone, the only option left with "how open
source works" is for someone to fork the code from the point where it
all worked. That isn't something that should be done lightly.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Re: Let's redesign the entire filesystem!

[Greg KH]

On Wed, Mar 14, 2012 at 03:59:56PM +0000, Ciaran McCreesh wrote:
> On Wed, 14 Mar 2012 08:22:09 -0700
> Greg KH <gregkh@gentoo.org> wrote:
> > The people doing the work today do understand them, by virtue of
> > doing the work involved, which gives them the say in how it is done.
> > That's how open source works, why is this ever a surprise to people?
> 
> The problem is that when a small number of people who have commit
> access to core projects screw everything up and don't fix the mess
> they're inflicting upon everyone,

Again, there is a simple solution for this problem, already provided,
and supported, so no "mess" talking here please, that's just trying to
be dramatic.

> the only option left with "how open source works" is for someone to
> fork the code from the point where it all worked. That isn't something
> that should be done lightly.

Forking should ALWAYS be done lightly and often, I highly recommend it.

If you think you know how to do something better, it's best to fork,
work it out, and if you come up with something, then work to merge it
back, if at all possible.  If merging doesn't work, and it turns out
that your stuff works better, people will migrate to it, keeping it
alive.

Odds are, the fork will turn out to be a dead-end, and it will die off.
But you will then know the reasons why, and not be so upset when others
do things you disagree with.

That's the way evolution works, and it works quite well, it's why open
soure works as well as it does.

So please, fork away, I can't recommend it enough.  Remember, it's what
got us Gentoo :)

greg k-h

Re: [gentoo-dev] Re: Let's redesign the entire filesystem!

[Matthew Summers]

On Wed, Mar 14, 2012 at 10:22 AM, Greg KH <gregkh@gentoo.org> wrote:
> On Wed, Mar 14, 2012 at 03:08:27PM +0000, Ciaran McCreesh wrote:
>> On Wed, 14 Mar 2012 08:04:31 -0700
>> Greg KH <gregkh@gentoo.org> wrote:
>> > Not always, no, it isn't obvious that something didn't start up
>> > correctly, or that it didn't fully load properly.  Some programs later
>> > on recover and handle things better.
>>
>> So why not work on fixing those things, since they're clearly symptoms
>> of a larger "oops, we have too much coupling" problem, instead of
>> forcing a workaround onto large numbers of users?
>
> I seriously doubt there are a "large number" of users here that have
> this issue.
>

The majority of users should not encounter any difficulty due to this
issue. Those that are doing special things that require careful
mounting, etc should be sufficiently competent to deal with this issue
without any trouble at all, especially given the various solution
paths.

> And even if there is, again, there is a simple solution that Gentoo
> provides for this issue, see the earlier initrd solution that we support
> today.
>

Gentoo provides a solution with genkernel, dracut provides a solution,
even the linux kernel itself provides a solution (in my view the
easiest solution at that).

> I'll go back to lurking now, and getting stuff done, like everyone else
> on this thread should be doing, instead of complaining (this is -dev,
> not -users...)
>
> greg k-h
>

Oh, please Greg, do continue to stay engaged, I enjoy your perspective
very much.

I just wanted to drop this simple fact in there. This has been coming
for several years now AND the linux kernel has been using an initramfs
for every boot, every time for a long time now, all 2.6 and up as I
understand it. If the initramfs is empty, well the kernel is smart
enough to fall back on "legacy" boot process.

If you care to read about it, its all contained locally if your kernel
source in the file
linux/Documentation/filesystems/ramfs-rootfs-initramfs.txt

Its a great read, sure to entertain and enlighten. It saved my bacon a
few times when mdadm switched to the new metadata format. Once I began
to learn about what the initramfs made possible, entire new worlds of
possibility appeared (and I was not even on drugs!).

It's actually something of a surprise to me that there are people
upset about this change, since it cleans things up a bit while also
giving people that want and/or need it, a great deal of power and
control over the boot process that was not nearly as easy before.

I do believe Gentoo, as a community/volunteer-run and super-power-user
distribution, should be careful, a bit wary, and seriously consider
the decisions made by our corporate colleagues (we do have the mandate
to maintain our independence). However, simply because RHEL, SUSE, etc
are corporation controlled distributions does not mean they are bad or
trying to control/ruin the rest of the distros.

Anyway, I merely thought I would place my commentary on this situation
here for posterity. Since I have an opinion, I thought I would share
it for better or worse.

-- 
Matthew W. Summers
Gentoo Foundation Inc.

Re: [gentoo-dev] Re: Let's redesign the entire filesystem!

[Joshua Kinard]

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

On 03/14/2012 12:28, Matthew Summers wrote:

> 
> Gentoo provides a solution with genkernel, dracut provides a solution,
> even the linux kernel itself provides a solution (in my view the
> easiest solution at that).


The kernel doesn't appear to create the networking interfaces, though.
CONFIG_DEVTMPFS is only going to handle things that physically exist within
/dev, of which, ethernet devices have always been excluded.  If that can get
fixed in some fashion, then devtmpfs pretty much does make this a non-issue.


> I just wanted to drop this simple fact in there. This has been coming
> for several years now AND the linux kernel has been using an initramfs
> for every boot, every time for a long time now, all 2.6 and up as I
> understand it. If the initramfs is empty, well the kernel is smart
> enough to fall back on "legacy" boot process.


initramfs was introduced in 2.6.10, and prior to that, only a handful of
architectures even supported a built-in initrd (MIPS was one, and it wasn't
very pretty or functional).  I believe other distros required the bootloader
to pass the initrd to them somehow, but having never used an initrd in that
fashion, I don't know for certain.

But yes, if you enable CONFIG_IKCONFIG_PROC, you're essentially turning on
(or utilizing)  an initramfs accessible via /proc.

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

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

--Emperor Turhan, Centauri Republic


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

Re: [gentoo-dev] Re: Let's redesign the entire filesystem!

[Maxim Kammerer]

On Wed, Mar 14, 2012 at 17:22, Greg KH <gregkh@gentoo.org> wrote:
> As for "fixing this", see the oft-linked webpage as to why it can't be
> fixed easily, if at all, and honestly, I don't think it needs to be
> fixed.

What's wrong with:
  * having an "early mounts" list file
  * having an "early modules" list file
  * init system in early boot (e.g., OpenRC in init.sh) loading "early
modules" and mounting "early mounts" from /etc/fstab

This will solve the issue with most non-complex (i.e., no raid or
encryption) initramfs-less setups, without requiring that users
migrate to initramfs (e.g., after dealing with genkernel-generated
scripts for a long time, I wouldn't touch it with a pointed stick
anymore). The relevant files can be also generated automatically
during an upgrade (empty "early modules" and empty or /usr-only "early
mounts", depending on /etc/fstab contents).

-- 
Maxim Kammerer
Liberté Linux (discussion / support: http://dee.su/liberte-contribute)

Re: [gentoo-dev] Re: Let's redesign the entire filesystem!

[Zac Medico]

On 03/14/2012 10:11 AM, Maxim Kammerer wrote:
> What's wrong with:
>   * having an "early mounts" list file
>   * having an "early modules" list file
>   * init system in early boot (e.g., OpenRC in init.sh) loading "early
> modules" and mounting "early mounts" from /etc/fstab

You're assuming that the /sbin/init hasn't migrated to /usr/sbin/init.
Other that that, it sounds like a perfect solution if you're in the "I'd
rather die than use an initramfs" camp.
-- 
Thanks,
Zac

Re: [gentoo-dev] Re: Let's redesign the entire filesystem!

[Matthew Summers]

On Wed, Mar 14, 2012 at 12:29 PM, Zac Medico <zmedico@gentoo.org> wrote:
> On 03/14/2012 10:11 AM, Maxim Kammerer wrote:
>> What's wrong with:
>>   * having an "early mounts" list file
>>   * having an "early modules" list file
>>   * init system in early boot (e.g., OpenRC in init.sh) loading "early
>> modules" and mounting "early mounts" from /etc/fstab
>
> You're assuming that the /sbin/init hasn't migrated to /usr/sbin/init.
> Other that that, it sounds like a perfect solution if you're in the "I'd
> rather die than use an initramfs" camp.
> --
> Thanks,
> Zac
>

__Everyone__ is already using an initramfs, therefore there are no
initramfs-less systems anymore (it may just be empty). Every single
person reading this thread that has not already done so needs to
immediately go read the relevant documentation located in
/usr/src/linux/Documentation/filesystems/ramfs-rootfs-initramfs.txt,
then and only then can a real discourse be had.

Why is an in-kernel initramfs so bad anyway? I am baffled. Its quite
nice to have a minimal recovery env in case mounting fails, etc, etc,
etc.

:/

-- 
Matthew W. Summers
Gentoo Foundation Inc.

Re: [gentoo-dev] Re: Let's redesign the entire filesystem!

[Ciaran McCreesh]

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

On Wed, 14 Mar 2012 12:58:26 -0500
Matthew Summers <quantumsummers@gentoo.org> wrote:
> Why is an in-kernel initramfs so bad anyway? I am baffled. Its quite
> nice to have a minimal recovery env in case mounting fails, etc, etc,
> etc.

Because the initramfs is just replacing what / used to be, and it's
even less well handled than "stuff not in /usr" is just now. All using
an initramfs does is move the dependencies problem from somewhere where
we have a solution that used to work and that still mostly works to
somewhere where we don't have anything at all.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Re: Let's redesign the entire filesystem!

[Maxim Kammerer]

On Wed, Mar 14, 2012 at 19:58, Matthew Summers
<quantumsummers@gentoo.org> wrote:
> __Everyone__ is already using an initramfs, therefore there are no
> initramfs-less systems anymore (it may just be empty).

I suggest that you take a look at CONFIG_BLK_DEV_INITRD.

> Why is an in-kernel initramfs so bad anyway? I am baffled. Its quite
> nice to have a minimal recovery env in case mounting fails, etc, etc,
> etc.

There is nothing bad about initramfs. I think that you are misreading
the arguments above.

-- 
Maxim Kammerer
Liberté Linux (discussion / support: http://dee.su/liberte-contribute)

Re: [gentoo-dev] Re: Let's redesign the entire filesystem!

[Zac Medico]

On 03/14/2012 11:36 AM, Maxim Kammerer wrote:
> On Wed, Mar 14, 2012 at 19:58, Matthew Summers
> <quantumsummers@gentoo.org> wrote:
>> Why is an in-kernel initramfs so bad anyway? I am baffled. Its quite
>> nice to have a minimal recovery env in case mounting fails, etc, etc,
>> etc.
> 
> There is nothing bad about initramfs. I think that you are misreading
> the arguments above.

Whatever the arguments may be, the whole discussion boils down to the
fact that the only people who seem to have a "problem" are those that
have a separate /usr partition and simultaneously refuse to use an
initramfs.
-- 
Thanks,
Zac

Re: [gentoo-dev] Re: Let's redesign the entire filesystem!

[Michael Orlitzky]

On 03/14/12 14:56, Zac Medico wrote:
> On 03/14/2012 11:36 AM, Maxim Kammerer wrote:
>> On Wed, Mar 14, 2012 at 19:58, Matthew Summers
>> <quantumsummers@gentoo.org> wrote:
>>> Why is an in-kernel initramfs so bad anyway? I am baffled. Its quite
>>> nice to have a minimal recovery env in case mounting fails, etc, etc,
>>> etc.
>>
>> There is nothing bad about initramfs. I think that you are misreading
>> the arguments above.
> 
> Whatever the arguments may be, the whole discussion boils down to the
> fact that the only people who seem to have a "problem" are those that
> have a separate /usr partition and simultaneously refuse to use an
> initramfs.

People just don't like change for the sake of change, and haven't been
shown any benefits yet. I don't have a separate /usr anywhere, but if I
did, I would have to rebuild and test a good number of custom kernels
that would eventually need to wind up on production servers.

It would take a least a day's worth of work, not to mention staying late
to make the switch overnight. If you can offer me something cool for it,
great; but at the moment people are being offered "it will work the same
as it did yesterday," which sucks, because it works that way now.

Sure, there will be improvements in the future, but it can feel a lot
like treading water sometimes.

Re: [gentoo-dev] Re: Let's redesign the entire filesystem!

[Zac Medico]

On 03/14/2012 12:14 PM, Michael Orlitzky wrote:
> On 03/14/12 14:56, Zac Medico wrote:
>> On 03/14/2012 11:36 AM, Maxim Kammerer wrote:
>>> On Wed, Mar 14, 2012 at 19:58, Matthew Summers
>>> <quantumsummers@gentoo.org> wrote:
>>>> Why is an in-kernel initramfs so bad anyway? I am baffled. Its quite
>>>> nice to have a minimal recovery env in case mounting fails, etc, etc,
>>>> etc.
>>>
>>> There is nothing bad about initramfs. I think that you are misreading
>>> the arguments above.
>>
>> Whatever the arguments may be, the whole discussion boils down to the
>> fact that the only people who seem to have a "problem" are those that
>> have a separate /usr partition and simultaneously refuse to use an
>> initramfs.
> 
> People just don't like change for the sake of change, and haven't been
> shown any benefits yet. I don't have a separate /usr anywhere, but if I
> did, I would have to rebuild and test a good number of custom kernels
> that would eventually need to wind up on production servers.
> 
> It would take a least a day's worth of work, not to mention staying late
> to make the switch overnight. If you can offer me something cool for it,
> great; but at the moment people are being offered "it will work the same
> as it did yesterday," which sucks, because it works that way now.
> 
> Sure, there will be improvements in the future, but it can feel a lot
> like treading water sometimes.

Well, for most people, the most practical course of action is to suck it
up [1] and move on. Dwelling on it certainly won't help, and the
"redesign the entire filesystem" approach probably isn't very practical
for most people either.

[1] http://en.wiktionary.org/wiki/suck_it_up
-- 
Thanks,
Zac

Re: [gentoo-dev] Re: Let's redesign the entire filesystem!

[David Leverton]

On 14 March 2012 18:56, Zac Medico <zmedico@gentoo.org> wrote:
> Whatever the arguments may be, the whole discussion boils down to the
> fact that the only people who seem to have a "problem" are those that
> have a separate /usr partition and simultaneously refuse to use an
> initramfs.

I wonder if it might help to go through the benefits of having a
separate /usr, and see whether they still work when /usr is mounted by
initramfs.  Hopefully that would either demonstrate that the initramfs
approach is fine, or reveal a concrete problem with it so we can start
talking about solutions.

(For the record, I don't have a separate /usr, but mainly because when
I've been setting up machines I've been too lazy to either 1) figure
out how much space to allocate to each partition, or 2) learn how to
use lvm so I don't have to worry so much about getting it right the
first time.  I'd prefer for the option to stay available, but not as
strongly as some people do.)

To start us off, the benefit that I'm mainly interested in (for
potential future use, as stated above), and I realise this is probably
pretty far down the list overall, is that OpenRC can run fsck at
shutdown instead of boot for non-/ filesystems, so as long as / is
small there won't be huge boot delays.  I imagine using initramfs
wouldn't affect this, as by the time the system's shutting down it
shouldn't matter how /usr got mounted originally.  It might be
affected if fsck etc got moved to /usr as has been mentioned, but if
that happened OpenRC would probably have to be modified to remount it
readonly at shutdown rather than unmount it, and presumably that would
allow the fsck to occur.

Would anyone else like to continue with their own favourite
separate-/usr reason?

Re: [gentoo-dev] Re: Let's redesign the entire filesystem!

[Greg KH]

On Wed, Mar 14, 2012 at 07:57:52PM +0000, David Leverton wrote:
> Would anyone else like to continue with their own favourite
> separate-/usr reason?

Haveing a separate /usr is wonderful, and once we finish moving /sbin/
and /bin/ into /usr/ it makes even more sense.  See the /usr page at
fedora for all of the great reasons why this is good.

What doesn't make sense is people who do that, refusing to use an initrd
or initramfs to make the whole thing work properly.

It's as if people want the benefits, yet fail to want to actually use
the tools required to get those benefits.  It makes no sense, and if
anyone continues to complain, it shows a lack of understanding.

greg k-h

Re: [gentoo-dev] Re: Let's redesign the entire filesystem!

[David Leverton]

On 14 March 2012 21:04, Greg KH <gregkh@gentoo.org> wrote:
> Haveing a separate /usr is wonderful, and once we finish moving /sbin/
> and /bin/ into /usr/ it makes even more sense.  See the /usr page at
> fedora for all of the great reasons why this is good.

My point was examine, in detail, whether separate-/usr-with-initramfs
has any disadvantages compared to separate-/usr-without-initramfs.
Either it has, in which case we have a concrete argument against
requiring initramfs (albeit possibly one that can be fixed), or it
hasn't, which should hopefully convince at least some people to accept
it.

Re: [gentoo-dev] Re: Let's redesign the entire filesystem!

[Greg KH]

On Wed, Mar 14, 2012 at 10:14:54PM +0000, David Leverton wrote:
> On 14 March 2012 21:04, Greg KH <gregkh@gentoo.org> wrote:
> > Haveing a separate /usr is wonderful, and once we finish moving /sbin/
> > and /bin/ into /usr/ it makes even more sense.  See the /usr page at
> > fedora for all of the great reasons why this is good.
> 
> My point was examine, in detail, whether separate-/usr-with-initramfs
> has any disadvantages compared to separate-/usr-without-initramfs.

Oh, that's simple, separate-/usr-without-initramfs will not work and
will not be supported :)

Again, the fact that it works for some people today is pure luck, and
odds are, it really isn't, but it's really hard to determine this given
that the init system they are using doesn't provide a good feedback loop
for this type of thing.

Hence, it is not supported.

thanks,

greg k-h

Re: [gentoo-dev] Re: Let's redesign the entire filesystem!

[David Leverton]

On 14 March 2012 22:51, Greg KH <gregkh@gentoo.org> wrote:
> Oh, that's simple, separate-/usr-without-initramfs will not work and
> will not be supported :)

See, it's this "we're doing it this way because we know best and we
say so" that upsets people.  I'm trying to encourage everyone to get
to the core reasons for having a separate /usr in the first place (not
all of which are guaranteed to be mentioned on any specific wiki
page), and logically analyse the potential disadvantages of using an
initramfs in each situation.  It may turn out that there are no
disadvantages after all, but the analysis is still important, not only
to make sure that "we"'re making the right decision, but also to
persuade everyone else that it's the right decision.

> Again, the fact that it works for some people today is pure luck, and
> odds are, it really isn't, but it's really hard to determine this given
> that the init system they are using doesn't provide a good feedback loop
> for this type of thing.

Maybe it would be worth improving the init system to do so?  Or maybe
it wouldn't because using an initramfs is easier and has no drawbacks,
but see above.

Re: [gentoo-dev] Re: Let's redesign the entire filesystem!

[Greg KH]

On Wed, Mar 14, 2012 at 11:21:44PM +0000, David Leverton wrote:
> On 14 March 2012 22:51, Greg KH <gregkh@gentoo.org> wrote:
> > Oh, that's simple, separate-/usr-without-initramfs will not work and
> > will not be supported :)
> 
> See, it's this "we're doing it this way because we know best and we
> say so" that upsets people.

Oh, and somehow "consensus" will work?  No, sorry, it will not.

How about the basic FACT that today, such systems do not work, and are
not supported by a wide range of packages we support today.

Yes, some people are "lucky" in that their systems don't have those
packages, but others are not.  The simple "I use a bluetooth keyboard"
is one such example.

So it's not a "we know best", it's a "it will not properly work
otherwise."

It is strange to watch people somehow think that if they complain
enough, or feel strongly enough, something is going to change here to
make this basic fact go away.

Now, to get back to what I said before, I'm done with this thread, it's
going nowhere, and it seems I'm just making it worse, my apologies.  For
penance, I'll adopt the next abandoned package someone throws at me, any
suggestions?

greg k-h

Re: [gentoo-dev] Re: Let's redesign the entire filesystem!

[Richard Yao]

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

On 03/14/12 19:44, Greg KH wrote:
> Now, to get back to what I said before, I'm done with this thread, it's
> going nowhere, and it seems I'm just making it worse, my apologies.  For
> penance, I'll adopt the next abandoned package someone throws at me, any
> suggestions?

Bug #360513 needs work. Something in sys-boot/grub-0.97-r* is triggering
a bug in the GNU toolchain. Few of us have time to deal with it, so it
would be much appreciated if you would take care of it. ;)


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

Re: [gentoo-dev] Re: Let's redesign the entire filesystem!

[Greg KH]

On Wed, Mar 14, 2012 at 07:58:23PM -0400, Richard Yao wrote:
> On 03/14/12 19:44, Greg KH wrote:
> > Now, to get back to what I said before, I'm done with this thread, it's
> > going nowhere, and it seems I'm just making it worse, my apologies.  For
> > penance, I'll adopt the next abandoned package someone throws at me, any
> > suggestions?
> 
> Bug #360513 needs work. Something in sys-boot/grub-0.97-r* is triggering
> a bug in the GNU toolchain. Few of us have time to deal with it, so it
> would be much appreciated if you would take care of it. ;)

grub is not an abandoned package, it's as if people don't read what I
write...

Re: [gentoo-dev] Re: Let's redesign the entire filesystem!

[David Leverton]

On 14 March 2012 23:44, Greg KH <gregkh@gentoo.org> wrote:
> Oh, and somehow "consensus" will work?  No, sorry, it will not.

No, logical analysis will, as I said in the rest of my post which you
conveniently ignored - either we conclude with evidence that there are
no issues, which should settle the matter for reasonable people, or we
discover that there are, in which case they have to be dealt with one
way or another.  I really don't see how anyone can object to that,
unless they're worried they won't like the result....

> How about the basic FACT that today, such systems do not work

This is debatable at best.  You can keep screaming "but bluetooth
won't work!" until you're blue in the face, but that's not relevant at
all to people who don't use bluetooth.

> and are not supported by a wide range of packages we support today.

Isn't such support being removed by the same people who keep arguing
that it's already not supported?  That's like cutting half your
employees' pay, and then insisting that you have to choice but to cut
the other half's pay as well, in order to be fair.

> Yes, some people are "lucky" in that their systems don't have those
> packages, but others are not.  The simple "I use a bluetooth keyboard"
> is one such example.

People who only have a bluetooth keyboard can set their systems up in
such a way that it works, just like how people who have / on lvm can
set their systems up in such a way that that works.  That's not in
itself a reason to force it on everyone.

> It is strange to watch people somehow think that if they complain
> enough, or feel strongly enough, something is going to change here to
> make this basic fact go away.

If by "the basic fact" you mean that plenty of people are quite happy
doing what's worked just fine for years, then yes.

Re: [gentoo-dev] Re: Let's redesign the entire filesystem!

[Stelian Ionescu]

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

On Thu, 2012-03-15 at 00:29 +0000, David Leverton wrote:
> On 14 March 2012 23:44, Greg KH <gregkh@gentoo.org> wrote:
> > Oh, and somehow "consensus" will work?  No, sorry, it will not.
> 
> No, logical analysis will, as I said in the rest of my post which you
> conveniently ignored - either we conclude with evidence that there are
> no issues, which should settle the matter for reasonable people, or we
> discover that there are, in which case they have to be dealt with one
> way or another.  I really don't see how anyone can object to that,
> unless they're worried they won't like the result....
> 
> > How about the basic FACT that today, such systems do not work
> 
> This is debatable at best.  You can keep screaming "but bluetooth
> won't work!" until you're blue in the face, but that's not relevant at
> all to people who don't use bluetooth.

That's true, but given the need to have a "one size fits all" boot
system(for obvious practical reasons), such boot system needs to work
with bluetooth input devices

-- 
Stelian Ionescu a.k.a. fe[nl]ix
Quidquid latine dictum sit, altum videtur.
http://common-lisp.net/project/iolib


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

Re: [gentoo-dev] Re: Let's redesign the entire filesystem!

[Joshua Kinard]

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

On 03/15/2012 07:20, Stelian Ionescu wrote:

> On Thu, 2012-03-15 at 00:29 +0000, David Leverton wrote:
>> On 14 March 2012 23:44, Greg KH <gregkh@gentoo.org> wrote:
>>> Oh, and somehow "consensus" will work?  No, sorry, it will not.
>>
>> No, logical analysis will, as I said in the rest of my post which you
>> conveniently ignored - either we conclude with evidence that there are
>> no issues, which should settle the matter for reasonable people, or we
>> discover that there are, in which case they have to be dealt with one
>> way or another.  I really don't see how anyone can object to that,
>> unless they're worried they won't like the result....
>>
>>> How about the basic FACT that today, such systems do not work
>>
>> This is debatable at best.  You can keep screaming "but bluetooth
>> won't work!" until you're blue in the face, but that's not relevant at
>> all to people who don't use bluetooth.
> 
> That's true, but given the need to have a "one size fits all" boot
> system(for obvious practical reasons), such boot system needs to work
> with bluetooth input devices


With Gentoo, that's really only for the preliminary installation.  Once you
get the system up and running, you're free to modify it in whatever way
pleases you.

For binary distributions, especially those that deal in the enterprise
sector, the one-size-fits-all approach is damn near mandatory because most
admins run with the distro-provided kernel and typically are not custom
compiling them.

But we're not a binary distro.  We're a source-based distro, although it's
possible to run Gentoo in a binary fashion.  As such, we're not necessarily
beholden to the "one-size-fits-all" approach.

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

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

--Emperor Turhan, Centauri Republic


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

Re: [gentoo-dev] Re: Let's redesign the entire filesystem!

[Joshua Kinard]

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

On 03/14/2012 19:44, Greg KH wrote:

> 
> Oh, and somehow "consensus" will work?  No, sorry, it will not.


If compelling arguments were used, yes, you can sometimes trigger people to
change their minds and arrive at a consensus.  But outright dismissing them
as if that will make them disappear is what won't work.


> So it's not a "we know best", it's a "it will not properly work
> otherwise."


Udev is the only package I have installed in my VM setup that fails at boot
with a separate /usr and no initramfs.  And that isn't even a fatal failure,
but it is a failure none the less, at least by virtue of OpenRC flagging the
fact that udev returned an error code.  Everything else works fine.

But it's not udev that is broke, is it?  It's my setup, right?  I've been
wrong for the last 10 years?  Why was this ever referenced then in the
Security Handbook?  See Code Listing 1.1:

http://www.gentoo.org/doc/en/security/security-handbook.xml?part=1&chap=4


> It is strange to watch people somehow think that if they complain
> enough, or feel strongly enough, something is going to change here to
> make this basic fact go away.


It's human nature to complain or otherwise voice dissent, especially when
someone or something comes along and declares that what used to JustWork(TM)
now NoLongerWorks(TM).

Does that mean my dissent matters?  Probably not.  But that's not going to
stop me from trying.

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

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

--Emperor Turhan, Centauri Republic


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

Re: [gentoo-dev] Re: Let's redesign the entire filesystem!

[Zac Medico]

On 03/14/2012 04:21 PM, David Leverton wrote:
> On 14 March 2012 22:51, Greg KH <gregkh@gentoo.org> wrote:
>> Oh, that's simple, separate-/usr-without-initramfs will not work and
>> will not be supported :)
> 
> See, it's this "we're doing it this way because we know best and we
> say so" that upsets people.

It's more about what we're _not_ doing that what we're doing. What we're
not doing is supporting the "/ is a self-contained boot disk that is
independent of /usr" use case, simply because it's a huge maintenance
burden and it doesn't make much sense in the post-initramfs world. The
people who have a "problem" with this don't understand the burden and
have no intention of taking on the burden themselves. Even if they
wanted to take on the burden, they wouldn't be capable of it. If they
were capable of taking on this burden then they would have already
understood that the initramfs is the most reasonable solution to their
perceived problem.
-- 
Thanks,
Zac

Re: [gentoo-dev] Re: Let's redesign the entire filesystem!

[David Leverton]

On 14 March 2012 23:47, Zac Medico <zmedico@gentoo.org> wrote:
> It's more about what we're _not_ doing that what we're doing.

Clearly something must have changed in udev 181 to make
/usr-without-initramfs not work anymore, and someone must have done
something to make that change happen, unless udev has aquired the
ability to evolve by itself.

Re: [gentoo-dev] Re: Let's redesign the entire filesystem!

[Zac Medico]

On 03/14/2012 05:36 PM, David Leverton wrote:
> On 14 March 2012 23:47, Zac Medico <zmedico@gentoo.org> wrote:
>> It's more about what we're _not_ doing that what we're doing.
> 
> Clearly something must have changed in udev 181 to make
> /usr-without-initramfs not work anymore, and someone must have done
> something to make that change happen, unless udev has aquired the
> ability to evolve by itself.

You're pointing your finger at udev, but the udev change is just a
symptom of a more general shift away from supporting the "/ is a
self-contained boot disk that is independent of /usr" use case.
-- 
Thanks,
Zac

Re: [gentoo-dev] Re: Let's redesign the entire filesystem!

[David Leverton]

On 15 March 2012 00:45, Zac Medico <zmedico@gentoo.org> wrote:
> You're pointing your finger at udev, but the udev change is just a
> symptom of a more general shift away from supporting the "/ is a
> self-contained boot disk that is independent of /usr" use case.

OK, so there are multiple instances of people not not doing anything
rather than just one.  I think that supports my point more than it
refutes it.

Re: [gentoo-dev] Re: Let's redesign the entire filesystem!

[Joshua Kinard]

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

On 03/14/2012 20:45, Zac Medico wrote:

> On 03/14/2012 05:36 PM, David Leverton wrote:
>> On 14 March 2012 23:47, Zac Medico <zmedico@gentoo.org> wrote:
>>> It's more about what we're _not_ doing that what we're doing.
>>
>> Clearly something must have changed in udev 181 to make
>> /usr-without-initramfs not work anymore, and someone must have done
>> something to make that change happen, unless udev has aquired the
>> ability to evolve by itself.
> 
> You're pointing your finger at udev, but the udev change is just a
> symptom of a more general shift away from supporting the "/ is a
> self-contained boot disk that is independent of /usr" use case.


I think it's better to say that udev is one of the more important components
of your average Linux system that's decided to support a unified root + /usr
filesystem.  If we were looking at some non-critical, non-boot service that
made this decision, then we wouldn't be having this discussion.

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

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

--Emperor Turhan, Centauri Republic


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

Re: [gentoo-dev] Re: Let's redesign the entire filesystem!

[Zac Medico]

On 03/15/2012 05:27 AM, Joshua Kinard wrote:
> On 03/14/2012 20:45, Zac Medico wrote:
> 
>> On 03/14/2012 05:36 PM, David Leverton wrote:
>>> On 14 March 2012 23:47, Zac Medico <zmedico@gentoo.org> wrote:
>>>> It's more about what we're _not_ doing that what we're doing.
>>>
>>> Clearly something must have changed in udev 181 to make
>>> /usr-without-initramfs not work anymore, and someone must have done
>>> something to make that change happen, unless udev has aquired the
>>> ability to evolve by itself.
>>
>> You're pointing your finger at udev, but the udev change is just a
>> symptom of a more general shift away from supporting the "/ is a
>> self-contained boot disk that is independent of /usr" use case.
> 
> 
> I think it's better to say that udev is one of the more important components
> of your average Linux system that's decided to support a unified root + /usr
> filesystem.  If we were looking at some non-critical, non-boot service that
> made this decision, then we wouldn't be having this discussion.

They're intertwined though, since having a unified root implies that
there is no support for the "/ is a self-contained boot disk that is
independent of /usr" use case, and the bulk of people's opposition to
having a unified root seems to stem from their dependence on the "/ is a
self-contained boot disk that is independent of /usr" use case.

So, the question at the heart of the whole discussion is: Should we
support the "/ is a self-contained boot disk that is independent of
/usr" use case?
-- 
Thanks,
Zac

Re: [gentoo-dev] Re: Let's redesign the entire filesystem!

[Richard Yao]

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

On 03/14/12 20:36, David Leverton wrote:
> On 14 March 2012 23:47, Zac Medico <zmedico@gentoo.org> wrote:
>> It's more about what we're _not_ doing that what we're doing.
> 
> Clearly something must have changed in udev 181 to make
> /usr-without-initramfs not work anymore, and someone must have done
> something to make that change happen, unless udev has aquired the
> ability to evolve by itself.
> 

I suggest that you file a bug report regarding this for the Gentoo udev
maintainer.


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

Re: [gentoo-dev] Re: Let's redesign the entire filesystem!

[Zac Medico]

On 03/14/2012 05:58 PM, Richard Yao wrote:
> On 03/14/12 20:36, David Leverton wrote:
>> On 14 March 2012 23:47, Zac Medico <zmedico@gentoo.org> wrote:
>>> It's more about what we're _not_ doing that what we're doing.
>>
>> Clearly something must have changed in udev 181 to make
>> /usr-without-initramfs not work anymore, and someone must have done
>> something to make that change happen, unless udev has aquired the
>> ability to evolve by itself.
>>
> 
> I suggest that you file a bug report regarding this for the Gentoo udev
> maintainer.

RESOLVED:UPSTREAM
-- 
Thanks,
Zac

Re: [gentoo-dev] Re: Let's redesign the entire filesystem!

[Richard Yao]

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

On 03/14/12 21:06, Zac Medico wrote:
> On 03/14/2012 05:58 PM, Richard Yao wrote:
>> On 03/14/12 20:36, David Leverton wrote:
>>> On 14 March 2012 23:47, Zac Medico <zmedico@gentoo.org> wrote:
>>>> It's more about what we're _not_ doing that what we're doing.
>>>
>>> Clearly something must have changed in udev 181 to make
>>> /usr-without-initramfs not work anymore, and someone must have done
>>> something to make that change happen, unless udev has aquired the
>>> ability to evolve by itself.
>>>
>>
>> I suggest that you file a bug report regarding this for the Gentoo udev
>> maintainer.
> 
> RESOLVED:UPSTREAM

Lets permit the udev maintainer to do that. :)


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

Re: [gentoo-dev] Re: Let's redesign the entire filesystem!

[Zac Medico]

On 03/14/2012 06:49 PM, Richard Yao wrote:
> On 03/14/12 21:06, Zac Medico wrote:
>> On 03/14/2012 05:58 PM, Richard Yao wrote:
>>> On 03/14/12 20:36, David Leverton wrote:
>>>> On 14 March 2012 23:47, Zac Medico <zmedico@gentoo.org> wrote:
>>>>> It's more about what we're _not_ doing that what we're doing.
>>>>
>>>> Clearly something must have changed in udev 181 to make
>>>> /usr-without-initramfs not work anymore, and someone must have done
>>>> something to make that change happen, unless udev has aquired the
>>>> ability to evolve by itself.
>>>>
>>>
>>> I suggest that you file a bug report regarding this for the Gentoo udev
>>> maintainer.
>>
>> RESOLVED:UPSTREAM
> 
> Lets permit the udev maintainer to do that. :)

Bug 398049 can serve well enough. The maintainer said, "This should no
longer be an issue once we have everyone with separate /usr using an
initramfs." [1]

[1] https://bugs.gentoo.org/show_bug.cgi?id=398049#c2
-- 
Thanks,
Zac

Re: [gentoo-dev] Re: Let's redesign the entire filesystem!

[Zac Medico]

On 03/14/2012 06:49 PM, Richard Yao wrote:
> On 03/14/12 21:06, Zac Medico wrote:
>> On 03/14/2012 05:58 PM, Richard Yao wrote:
>>> On 03/14/12 20:36, David Leverton wrote:
>>>> On 14 March 2012 23:47, Zac Medico <zmedico@gentoo.org> wrote:
>>>>> It's more about what we're _not_ doing that what we're doing.
>>>>
>>>> Clearly something must have changed in udev 181 to make
>>>> /usr-without-initramfs not work anymore, and someone must have done
>>>> something to make that change happen, unless udev has aquired the
>>>> ability to evolve by itself.
>>>>
>>>
>>> I suggest that you file a bug report regarding this for the Gentoo udev
>>> maintainer.
>>
>> RESOLVED:UPSTREAM
> 
> Lets permit the udev maintainer to do that. :)

Bug 398049 can serve well enough. The maintainer said, "This should no
longer be an issue once we have everyone with separate /usr using an
initramfs." [1]

[1] https://bugs.gentoo.org/show_bug.cgi?id=398049#c2
-- 
Thanks,
Zac

Re: [gentoo-dev] Re: Let's redesign the entire filesystem!

[Joshua Kinard]

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

On 03/14/2012 18:51, Greg KH wrote:

> On Wed, Mar 14, 2012 at 10:14:54PM +0000, David Leverton wrote:
>> On 14 March 2012 21:04, Greg KH <gregkh@gentoo.org> wrote:
>>> Haveing a separate /usr is wonderful, and once we finish moving /sbin/
>>> and /bin/ into /usr/ it makes even more sense.  See the /usr page at
>>> fedora for all of the great reasons why this is good.
>>
>> My point was examine, in detail, whether separate-/usr-with-initramfs
>> has any disadvantages compared to separate-/usr-without-initramfs.
> 
> Oh, that's simple, separate-/usr-without-initramfs will not work and
> will not be supported :)


Not supported by whom?  udev?  Or Gentoo?

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

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

--Emperor Turhan, Centauri Republic


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

Re: [gentoo-dev] Re: Let's redesign the entire filesystem!

[Joshua Kinard]

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

On 03/14/2012 18:14, David Leverton wrote:

> On 14 March 2012 21:04, Greg KH <gregkh@gentoo.org> wrote:
>> Haveing a separate /usr is wonderful, and once we finish moving /sbin/
>> and /bin/ into /usr/ it makes even more sense.  See the /usr page at
>> fedora for all of the great reasons why this is good.
> 
> My point was examine, in detail, whether separate-/usr-with-initramfs
> has any disadvantages compared to separate-/usr-without-initramfs.
> Either it has, in which case we have a concrete argument against
> requiring initramfs (albeit possibly one that can be fixed), or it
> hasn't, which should hopefully convince at least some people to accept
> it.


I went with a split filesystem design when I built my first Gentoo install
back in mid 2003 because at the time, both the Gentoo and Debian security
guides referenced it as being an option for a more secure system.

Specifically so that you could apply mount options to each partition.  For
example, on /home, you would usually want to do nodev and nosuid, because
rarely does a user need the ability to create device nodes and SUID
binaries.  On /var, nodev, nosuid, and noexec, with the one exception if you
ran qmail or a few other packages known to stick executables into /var.  For
/usr, the guides suggested just nodev, because you rarely, if ever need to
create device nodes in /usr.  Optionally, you could mount /usr ro and only
make it rw if updating packages.

You won't find A separate /usr mentioned specifically anymore in either
security guide, but I'm sure if you dig on the Wayback Machine (once it
comes back online), you can probably find these references.  Search from
2003 to 2007.  I'm not certain when they were removed.

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

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

--Emperor Turhan, Centauri Republic


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

Re: [gentoo-dev] Re: Let's redesign the entire filesystem!

[Richard Yao]

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

On 03/14/12 17:04, Greg KH wrote:
> On Wed, Mar 14, 2012 at 07:57:52PM +0000, David Leverton wrote:
>> Would anyone else like to continue with their own favourite
>> separate-/usr reason?
> 
> Haveing a separate /usr is wonderful, and once we finish moving /sbin/
> and /bin/ into /usr/ it makes even more sense.  See the /usr page at
> fedora for all of the great reasons why this is good.
> 
> What doesn't make sense is people who do that, refusing to use an initrd
> or initramfs to make the whole thing work properly.
> 
> It's as if people want the benefits, yet fail to want to actually use
> the tools required to get those benefits.  It makes no sense, and if
> anyone continues to complain, it shows a lack of understanding.
> 
> greg k-h
> 

Is this that page?

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

That refers to the systemd website on freedesktop.org.

http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge

Reading that, it seems to me that this /usr move was caused by a
systemd-specific decision that rootfs should be both system-specific and
located on the particular system while /usr should be network mountable.
However, I see no argument for why that should be the case.

Thinking about it, I suppose this would make sense in an enterprise
setting where everything is diskless. If you PXE boot, put rootfs on
iSCSI and have /usr on a NFS mount, this would work very well. Claiming
that people show a lack of understanding when you never explain this,
however, is definitely the wrong thing to do.

With that said, I have a few questions:

1. Why does no one mention the enterprise use case at all?
2. Why not make rootfs a NFS mount with a unionfs at the SAN/NAS device?
3. Why not let the users choose where these directories go and support
both locations?


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

Re: [gentoo-dev] Re: Let's redesign the entire filesystem!

[Greg KH]

On Wed, Mar 14, 2012 at 06:39:05PM -0400, Richard Yao wrote:
> Is this that page?
> 
> http://fedoraproject.org/wiki/Features/UsrMove
> 
> That refers to the systemd website on freedesktop.org.
> 
> http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge

Yes.

> With that said, I have a few questions:
> 
> 1. Why does no one mention the enterprise use case at all?

It has been pointed out before, why constantly repeat ourselves.

> 2. Why not make rootfs a NFS mount with a unionfs at the SAN/NAS device?

unionfs is still a "work in progress", some systems can't do that yet.

> 3. Why not let the users choose where these directories go and support
> both locations?

Because a plethera of options is a sure way to make sure that half of
them don't work over the long run.

We aren't Debian here people, we don't support "everything" :)

If you want to support both, great, feel free to step up and do the
work.

greg k-h

Re: [gentoo-dev] Re: Let's redesign the entire filesystem!

[Richard Yao]

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

On 03/14/12 18:49, Greg KH wrote:
> On Wed, Mar 14, 2012 at 06:39:05PM -0400, Richard Yao wrote:
>> With that said, I have a few questions:
>>
>> 1. Why does no one mention the enterprise use case at all?
> 
> It has been pointed out before, why constantly repeat ourselves.

Simple. No one has documented it. A webpage that makes a few vague
references to "enterprise use" does not count as documentation.

I happened to figure it out when trying to rationalize why anyone would
want this, but this is hardly obvious to those that imagine a computer
as a self-sufficient single disk system.

>> 2. Why not make rootfs a NFS mount with a unionfs at the SAN/NAS device?
> 
> unionfs is still a "work in progress", some systems can't do that yet.

That sounds like something that needs to be fixed.

>> 3. Why not let the users choose where these directories go and support
>> both locations?
> 
> Because a plethera of options is a sure way to make sure that half of
> them don't work over the long run.
> 
> We aren't Debian here people, we don't support "everything" :)

Gentoo provides far more options than Debian does, so this seems
somewhat contradictory to me.


> If you want to support both, great, feel free to step up and do the
> work.

Fair enough, however, I should remind you that not much will happen
without a decision from the Gentoo Council. I am willing to accept
whatever decision they make, but I think that exposing this decision to
users is something that is within our ability to do.

Portage provides use with the ability to do abstractions that other
distributions cannot do, such as permitting people to merge
/usr{bin,lib{32,64,},sbin} into /.


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

Re: [gentoo-dev] Re: Let's redesign the entire filesystem!

[Greg KH]

On Wed, Mar 14, 2012 at 07:27:07PM -0400, Richard Yao wrote:
> >> 3. Why not let the users choose where these directories go and support
> >> both locations?
> > 
> > Because a plethera of options is a sure way to make sure that half of
> > them don't work over the long run.
> > 
> > We aren't Debian here people, we don't support "everything" :)
> 
> Gentoo provides far more options than Debian does, so this seems
> somewhat contradictory to me.

Not really, I don't think we support systems without udev anymore,
right?  And we get away with a lot of these different "options" at
compile time, which makes it easier than what Debian has to handle, so
perhaps it's not a fair comparison.

> > If you want to support both, great, feel free to step up and do the
> > work.
> 
> Fair enough, however, I should remind you that not much will happen
> without a decision from the Gentoo Council. I am willing to accept
> whatever decision they make, but I think that exposing this decision to
> users is something that is within our ability to do.

I didn't think the Council ruled on technical questions.

In fact, how is this relevant at all anyway?  It's quite simple in that
we don't support systems today with a separate /usr/ without a
initramfs/initrd.  If it happens to work, wonderful, but don't expect
Gentoo developers to rewrite the upstream packages to work for this type
of unsupported systems, it's not going to happen.

Or are you referring to the "no more /bin and /sbin" thing?  That's just
going to happen "naturally", one day in a few months or years, your
system will have moved to this without you even realizing it :)

> Portage provides use with the ability to do abstractions that other
> distributions cannot do, such as permitting people to merge
> /usr{bin,lib{32,64,},sbin} into /.

Sure, but that doesn't mean that the packages that are being merged will
actually work :)

greg k-h

Re: [gentoo-dev] Re: Let's redesign the entire filesystem!

[Richard Yao]

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

On 03/14/12 19:37, Greg KH wrote:
>> Portage provides use with the ability to do abstractions that other
>> distributions cannot do, such as permitting people to merge
>> /usr{bin,lib{32,64,},sbin} into /.
> 
> Sure, but that doesn't mean that the packages that are being merged will
> actually work :)
> 
> greg k-h

I proposed a way that this could work with no effort on the part of the
Gentoo developers in one of my earlier emails:

On 03/14/12 17:05, Richard Yao wrote:
> In the meantime, it should be possible to create a global usr USE flag
> that enables/disables gen_usr_ldscript. It would then be possible to
> delete all of the usr ldscripts, dump /usr into / and symlink /usr to /.
> The dynamic linker would go to / before /usr and it would be trivial to
> modify $PATH to ignore /usr entirely. Legacy software that requires
> /usr/{bin,sbin} would still work while those that want a separate /usr
> mount could symlink /usr/{bin,include,libexec,sbin} into their rootfs
> counterparts.


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

Re: [gentoo-dev] Re: Let's redesign the entire filesystem!

[Rich Freeman]

On Wed, Mar 14, 2012 at 7:51 PM, Richard Yao <ryao@cs.stonybrook.edu> wrote:
>
> I proposed a way that this could work with no effort on the part of the
> Gentoo developers in one of my earlier emails:
>

Then go ahead and make it happen.  If as you say no dev participation
is needed there is nothing Gentoo needs to do to support this.

On Wed, Mar 14, 2012 at 6:49 PM, Greg KH <gregkh@gentoo.org> wrote:
>
> We aren't Debian here people, we don't support "everything" :)
>
> If you want to support both, great, feel free to step up and do the
> work.
>

Gentoo is about choice, but it is largely about the choices that
people are willing to step up and maintain.

A few months ago there was a big thread and lots of devs said that
systemd isn't supported on Gentoo.  Some devs stepped up and decided
to maintain it and now I'd say systemd is about as supported on Gentoo
as Prefix, FreeBSD, Sparc, or MIPS.  That didn't happen because of
mailing list persuasion - it happened because a few people interested
in making it happen wrote a bunch of ebuilds.  How do systemd units
end up in various packages?  The people interested in seeing them
write good-quality patches and submit bugs, or otherwise work with the
maintainers to commit them.

For those who don't like the current direction, by all means create an
overlay called udev-root, mdev-boot, noinitramfs, or whatever.  You
don't need anybody's permission to do it - just go on github and make
it happen.  Write some good code.  There are several devs here who
might even help you out with it, and nobody here is going to object to
packages going into the main tree as long as they're maintained in
accordance with Gentoo QA.  Create some USE flags where you need
tie-ins to other system packages and as long as everything behaves
nicely and patches are good and maintained, I'm sure the package
maintainers will accept them.

Gentoo already gives its users a lot of choice, but it can only offer
the choices that people are willing to maintain.  Right now I see a
lot of complaining and not a lot of maintaining.  When I see a package
lastrited I don't moan about it - I either sigh or sign up to maintain
it.  By all means make suggestions to improve the transition or write
docs, but simply posting on this list isn't likely to change the
direction the linux winds are blowing.  The forces involved are much
larger than Gentoo.

Rich

Re: [gentoo-dev] Re: Let's redesign the entire filesystem!

[Zac Medico]

On 03/14/2012 06:07 PM, Rich Freeman wrote:
> For those who don't like the current direction, by all means create an
> overlay called udev-root, mdev-boot, noinitramfs, or whatever.

The simplest alternative to an initramfs that I can think of would be an
init wrapper like the one that I suggested a while back [1].

[1]
http://archives.gentoo.org/gentoo-dev/msg_20749880f5bc5feda141488498729fe8.xml
-- 
Thanks,
Zac

Re: [gentoo-dev] Re: Let's redesign the entire filesystem!

[Richard Yao]

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

On 03/14/12 21:07, Rich Freeman wrote:
> On Wed, Mar 14, 2012 at 7:51 PM, Richard Yao <ryao@cs.stonybrook.edu> wrote:
>>
>> I proposed a way that this could work with no effort on the part of the
>> Gentoo developers in one of my earlier emails:
>>
> 
> Then go ahead and make it happen.  If as you say no dev participation
> is needed there is nothing Gentoo needs to do to support this.

That proposal was something that I had intended to abstract ebuild
maintainers such as myself out of the picture. I am do not have a
separate /usr filesystem, yet as an ebuild maintainer, I receive bug
reports from those that do.

If people want to guarentee that they can boot without an initramfs,
they can implement my suggestion. If they don't, then it is no problem
for me. I have already fixed things for the separate /usr crowd in my
ebuilds.


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

Re: [gentoo-dev] Re: Let's redesign the entire filesystem!

[Canek Peláez Valdés]

On Wed, Mar 14, 2012 at 7:07 PM, Rich Freeman <rich0@gentoo.org> wrote:
> On Wed, Mar 14, 2012 at 7:51 PM, Richard Yao <ryao@cs.stonybrook.edu> wrote:
>>
>> I proposed a way that this could work with no effort on the part of the
>> Gentoo developers in one of my earlier emails:
>>
>
> Then go ahead and make it happen.  If as you say no dev participation
> is needed there is nothing Gentoo needs to do to support this.
>
> On Wed, Mar 14, 2012 at 6:49 PM, Greg KH <gregkh@gentoo.org> wrote:
>>
>> We aren't Debian here people, we don't support "everything" :)
>>
>> If you want to support both, great, feel free to step up and do the
>> work.
>>
>
> Gentoo is about choice, but it is largely about the choices that
> people are willing to step up and maintain.
>
> A few months ago there was a big thread and lots of devs said that
> systemd isn't supported on Gentoo.  Some devs stepped up and decided
> to maintain it and now I'd say systemd is about as supported on Gentoo
> as Prefix, FreeBSD, Sparc, or MIPS.  That didn't happen because of
> mailing list persuasion - it happened because a few people interested
> in making it happen wrote a bunch of ebuilds.  How do systemd units
> end up in various packages?  The people interested in seeing them
> write good-quality patches and submit bugs, or otherwise work with the
> maintainers to commit them.
>
> For those who don't like the current direction, by all means create an
> overlay called udev-root, mdev-boot, noinitramfs, or whatever.  You
> don't need anybody's permission to do it - just go on github and make
> it happen.  Write some good code.  There are several devs here who
> might even help you out with it, and nobody here is going to object to
> packages going into the main tree as long as they're maintained in
> accordance with Gentoo QA.  Create some USE flags where you need
> tie-ins to other system packages and as long as everything behaves
> nicely and patches are good and maintained, I'm sure the package
> maintainers will accept them.

In that vein... just to let you guys know that I have set up an
overlay that has allowed me to run my Gentoo machines with only
systemd: no OpenRC, no baselayout, no sysvinit:

http://xochitl.matem.unam.mx/~canek/gentoo-systemd-only/

The changes are rather minimal (less than ten lines (usually a cople)
per ebuild changed from the original ebuilds in the tree), and almost
all will go away when the following bugs get fixed:

https://bugs.gentoo.org/show_bug.cgi?id=366173
https://bugs.gentoo.org/show_bug.cgi?id=373219
https://bugs.gentoo.org/show_bug.cgi?id=373219
https://bugs.gentoo.org/show_bug.cgi?id=373219
https://bugs.gentoo.org/show_bug.cgi?id=399615
https://bugs.gentoo.org/show_bug.cgi?id=399615
https://bugs.gentoo.org/show_bug.cgi?id=399615
https://bugs.gentoo.org/show_bug.cgi?id=405703
https://bugs.gentoo.org/show_bug.cgi?id=408379

Bug 373219 is specially problematic, since several scripts in packages
on the tree source /etc/init.d/functions.sh, (which lives in OpenRC),
and don't depend on OpenRC explicitly. I wrote a little script that
replaces the einfo, ewarn, etc. functions of OpenRC, and it seems to
be working. I also wrote alternative versions of the packages on the
tree that implicitly depend on OpenRC, so they now explicitly depend
on a little package that only installs my script.

It seems to be working.

If you guys want to try it, I would love to hear some comments about
it. (Usual disclaimer; if it breaks, you get to keep all the pieces).

Oh, and obviously the only supported setups are those with /usr in the
same partition as /; or, if /usr is in a separated partition, systems
that use an initramfs to mount it.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-dev] Re: Let's redesign the entire filesystem!

[Canek Peláez Valdés]

On Thu, Mar 15, 2012 at 7:17 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:

[...]

> https://bugs.gentoo.org/show_bug.cgi?id=366173
> https://bugs.gentoo.org/show_bug.cgi?id=373219
> https://bugs.gentoo.org/show_bug.cgi?id=399615
> https://bugs.gentoo.org/show_bug.cgi?id=405703
> https://bugs.gentoo.org/show_bug.cgi?id=408379

Oops, sorry, fogot to use uniq.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-dev] Re: Let's redesign the entire filesystem!

[Luca Barbato]

On 3/14/12 4:37 PM, Greg KH wrote:
> Not really, I don't think we support systems without udev anymore,
> right?  And we get away with a lot of these different "options" at
> compile time, which makes it easier than what Debian has to handle, so
> perhaps it's not a fair comparison.

I think we support systems with launchd and devd quite well and we'd 
love to support even some more.

> Sure, but that doesn't mean that the packages that are being merged will
> actually work :)

Only if upstream really wants to break them... And that is the perceived 
situation, exacerbated by the past experience with a certain audio 
daemon trying to do too much at the same time.

lu

Re: [gentoo-dev] Re: Let's redesign the entire filesystem!

[Martin Gysel]

Am 15.03.2012 00:37, schrieb Greg KH:
> Not really, I don't think we support systems without udev anymore,
> right?  And we get away with a lot of these different "options" at
> compile time, which makes it easier than what Debian has to handle, so
> perhaps it's not a fair comparison.

Sure Gentoo does support such systems...

# equery g virtual/dev-manager
 * Searching for dev-manager in virtual ...

 * dependency graph for virtual/dev-manager-0
 `--  virtual/dev-manager-0  amd64
   `--  sys-fs/udev-171-r5  (sys-fs/udev) amd64
   `--  sys-apps/busybox-1.19.3-r1  (sys-apps/busybox) amd64  [mdev]
   `--  sys-fs/devfsd-1.3.25-r9  (sys-fs/devfsd) [missing keyword]
   `--  sys-fs/static-dev-0.1  (sys-fs/static-dev) amd64
   `--  sys-freebsd/freebsd-sbin-9.0  (sys-freebsd/freebsd-sbin)
[missing keyword]
[ virtual/dev-manager-0 stats: packages (6), max depth (1) ]


/martin

Re: [gentoo-dev] Re: Let's redesign the entire filesystem!

[Joshua Kinard]

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

On 03/14/2012 19:37, Greg KH wrote:

> On Wed, Mar 14, 2012 at 07:27:07PM -0400, Richard Yao wrote:
>>>> 3. Why not let the users choose where these directories go and support
>>>> both locations?
>>>
>>> Because a plethera of options is a sure way to make sure that half of
>>> them don't work over the long run.
>>>
>>> We aren't Debian here people, we don't support "everything" :)
>>
>> Gentoo provides far more options than Debian does, so this seems
>> somewhat contradictory to me.
> 
> Not really, I don't think we support systems without udev anymore,
> right?  And we get away with a lot of these different "options" at
> compile time, which makes it easier than what Debian has to handle, so
> perhaps it's not a fair comparison.

I already looked in the tree and nothing really stands out as a suitable
replacement for /dev management.  mdev might, but it's part of busybox and
not standalone as far as I know (at least, we don't have an independent
package for it).

For my simplistic setups, I apparently only need udev just to setup the
networking interfaces, because Linux has never created /dev/lo or /dev/ethX
(nor does it even support them).  Thus, CONFIG_DEVTMPFS can't set those up
at all.  If I could find a small utility that was like udev and which took
care of that one little element, I think I'd be able to boot my systems up
just fine.

Is it futureproof?  Not really.  I imagine plugging USB mass storage devices
into a udevless system might be problematic.  Food for thought.

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

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

--Emperor Turhan, Centauri Republic


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

Re: [gentoo-dev] Re: Let's redesign the entire filesystem!

[Richard Yao]

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

On 03/15/12 08:40, Joshua Kinard wrote:
> I already looked in the tree and nothing really stands out as a suitable
> replacement for /dev management.  mdev might, but it's part of busybox and
> not standalone as far as I know (at least, we don't have an independent
> package for it).

Busybox is installed as part of the system profile on amd64. You can
install mdev by doing this:

ln -s /bin/busybox /sbin/mdev

There is documentation in the busybox GIT for how to use it:

http://git.busybox.net/busybox/plain/docs/mdev.txt


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

Re: [gentoo-dev] Re: Let's redesign the entire filesystem!

[Walter Dnes]

On Thu, Mar 15, 2012 at 04:44:11PM -0400, Richard Yao wrote

> Busybox is installed as part of the system profile on amd64. You can
> install mdev by doing this:
> 
> ln -s /bin/busybox /sbin/mdev

  The official method is to build busybox with the "mdev" USE flag.  That
is the only way that virtual/dev-manager recognizes it, and doesn't try
to pull in udev, instead.  From the ebuild...

RDEPEND="|| (
                sys-fs/udev
                sys-apps/busybox[mdev]
                sys-fs/devfsd
                sys-fs/static-dev
                sys-freebsd/freebsd-sbin
        )"


> There is documentation in the busybox GIT for how to use it:
> 
> http://git.busybox.net/busybox/plain/docs/mdev.txt

  TOOT!!! (blowing my own horn).  See http://www.waltdnes.org/mdev/ for
instructions on replacing udev with mdev for simple Gentoo systems.
Hopefully more info will start arriving, allowing more complex systems
to work with mdev.

-- 
Walter Dnes <waltdnes@waltdnes.org>

Re: [gentoo-dev] Re: Let's redesign the entire filesystem!

[Walter Dnes]

On Sat, Mar 17, 2012 at 03:12:11AM -0400, Walter Dnes wrote

>   TOOT!!! (blowing my own horn).  See http://www.waltdnes.org/mdev/ for
> instructions on replacing udev with mdev for simple Gentoo systems.
> Hopefully more info will start arriving, allowing more complex systems
> to work with mdev.

  With more people getting interested, the project has been moved to
wiki format https://wiki.gentoo.org/wiki/Mdev to allow more people to
contribute.

-- 
Walter Dnes <waltdnes@waltdnes.org>

Re: [gentoo-dev] Re: Let's redesign the entire filesystem!

[Joshua Kinard]

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

On 03/14/2012 19:27, Richard Yao wrote:

> On 03/14/12 18:49, Greg KH wrote:
>> On Wed, Mar 14, 2012 at 06:39:05PM -0400, Richard Yao wrote:
>>> With that said, I have a few questions:
>>>
>>> 1. Why does no one mention the enterprise use case at all?
>>
>> It has been pointed out before, why constantly repeat ourselves.
> 
> Simple. No one has documented it. A webpage that makes a few vague
> references to "enterprise use" does not count as documentation.
> 
> I happened to figure it out when trying to rationalize why anyone would
> want this, but this is hardly obvious to those that imagine a computer
> as a self-sufficient single disk system.


You'll also find a lot of enterprise-specific decisions went into IPv6,
without necessarily stating them as being enterprise-specific.  I.e., the
requirement for Unique Local Addresses, which are IPv6's idea of RFC1918,
required to be "globally-unique".  When I quizzed someone about this one (I
think it was on ServerFault somewhere), I was basically told that "IPv6 is
not for home use".


>>> 2. Why not make rootfs a NFS mount with a unionfs at the SAN/NAS device?
>>
>> unionfs is still a "work in progress", some systems can't do that yet.
> 
> That sounds like something that needs to be fixed.


I thought UnionFS died?  Or was better handled by other "tricks" involving
filesystem overlays?


>>> 3. Why not let the users choose where these directories go and support
>>> both locations?
>>
>> Because a plethera of options is a sure way to make sure that half of
>> them don't work over the long run.
>>
>> We aren't Debian here people, we don't support "everything" :)
> 
> Gentoo provides far more options than Debian does, so this seems
> somewhat contradictory to me.


Agreed.  Debian is focused on an entirely different model of building a
Linux system, thus they have a narrower dependency chain and you sometimes
have to include packages that you don't necessarily care for because they're
required by a package that you do want to use.  We have USE flags to resolve
that issue.

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

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

--Emperor Turhan, Centauri Republic


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

Re: [gentoo-dev] Re: Let's redesign the entire filesystem!

[Richard Yao]

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

On 03/15/12 08:34, Joshua Kinard wrote:
> On 03/14/2012 19:27, Richard Yao wrote:
> 
>> On 03/14/12 18:49, Greg KH wrote:
>>>> 2. Why not make rootfs a NFS mount with a unionfs at the SAN/NAS device?
>>>
>>> unionfs is still a "work in progress", some systems can't do that yet.
>>
>> That sounds like something that needs to be fixed.
> 
> 
> I thought UnionFS died?  Or was better handled by other "tricks" involving
> filesystem overlays?

I know the UnionFS developer offline. I will ask him what the status of
unionFS is the next time I see him. :)


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

Re: [gentoo-dev] Re: Let's redesign the entire filesystem!

[Maxim Kammerer]

On Thu, Mar 15, 2012 at 22:45, Richard Yao <ryao@cs.stonybrook.edu> wrote:
> I know the UnionFS developer offline. I will ask him what the status of
> unionFS is the next time I see him. :)

Unionfs patchset is regularly released for new kernels, and bugs are
fixed. I wouldn't call the project "dead", I would call it "mature"
and "stable". I am not aware of the current state of affairs wrt.
Unionfs vs. aufs, and whether the propaganda at unionfs.org still
holds water, though. Too bad that there is no stacking filesystem in
the mainline kernel.

-- 
Maxim Kammerer
Liberté Linux (discussion / support: http://dee.su/liberte-contribute)

Re: [gentoo-dev] Re: Let's redesign the entire filesystem!

[Richard Yao]

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

On 03/14/12 14:56, Zac Medico wrote:
> On 03/14/2012 11:36 AM, Maxim Kammerer wrote:
>> On Wed, Mar 14, 2012 at 19:58, Matthew Summers
>> <quantumsummers@gentoo.org> wrote:
>>> Why is an in-kernel initramfs so bad anyway? I am baffled. Its quite
>>> nice to have a minimal recovery env in case mounting fails, etc, etc,
>>> etc.
>>
>> There is nothing bad about initramfs. I think that you are misreading
>> the arguments above.
> 
> Whatever the arguments may be, the whole discussion boils down to the
> fact that the only people who seem to have a "problem" are those that
> have a separate /usr partition and simultaneously refuse to use an
> initramfs.

I do not have a separate /usr partition, however I agree with Joshua
Kinard's stance regarding the /usr move. The point of having a separate
/usr was to enable UNIX to exceed the space constraints that a 1.5MB
hard disk placed on rootfs. As far as I know, we do not support a 1.5MB
rootfs so it would make sense to deprecate the practice of having things
that belong in / in /usr directory, as opposed to making /usr into a new /.

Deprecation of this practice would mean that people could type
/bin/command instead of /usr/bin/command in situations where absolute
paths are necessary. We could symlink things in /usr to rootfs for
compatibility with legacy software. In a more extreme case, we could
symlink /usr to /, which would make plenty of sense given that we do not
need a separate /usr at all.


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

Re: [gentoo-dev] Re: Let's redesign the entire filesystem!

[Zac Medico]

On 03/14/2012 01:03 PM, Richard Yao wrote:
> On 03/14/12 14:56, Zac Medico wrote:
>> On 03/14/2012 11:36 AM, Maxim Kammerer wrote:
>>> On Wed, Mar 14, 2012 at 19:58, Matthew Summers
>>> <quantumsummers@gentoo.org> wrote:
>>>> Why is an in-kernel initramfs so bad anyway? I am baffled. Its quite
>>>> nice to have a minimal recovery env in case mounting fails, etc, etc,
>>>> etc.
>>>
>>> There is nothing bad about initramfs. I think that you are misreading
>>> the arguments above.
>>
>> Whatever the arguments may be, the whole discussion boils down to the
>> fact that the only people who seem to have a "problem" are those that
>> have a separate /usr partition and simultaneously refuse to use an
>> initramfs.
> 
> I do not have a separate /usr partition, however I agree with Joshua
> Kinard's stance regarding the /usr move. The point of having a separate
> /usr was to enable UNIX to exceed the space constraints that a 1.5MB
> hard disk placed on rootfs. As far as I know, we do not support a 1.5MB
> rootfs so it would make sense to deprecate the practice of having things
> that belong in / in /usr directory, as opposed to making /usr into a new /.
> 
> Deprecation of this practice would mean that people could type
> /bin/command instead of /usr/bin/command in situations where absolute
> paths are necessary. We could symlink things in /usr to rootfs for
> compatibility with legacy software. In a more extreme case, we could
> symlink /usr to /, which would make plenty of sense given that we do not
> need a separate /usr at all.

I'm not seeing any compelling benefits here that would justify a lack of
conformity with other *nix distros. It seems almost as though it's an
attempt to be different for the sake of being different, perhaps a
symptom of something like NIH syndrome.
-- 
Thanks,
Zac

Re: [gentoo-dev] Re: Let's redesign the entire filesystem!

[Richard Yao]

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

On 03/14/12 16:55, Zac Medico wrote:
> On 03/14/2012 01:03 PM, Richard Yao wrote:
>> I do not have a separate /usr partition, however I agree with Joshua
>> Kinard's stance regarding the /usr move. The point of having a separate
>> /usr was to enable UNIX to exceed the space constraints that a 1.5MB
>> hard disk placed on rootfs. As far as I know, we do not support a 1.5MB
>> rootfs so it would make sense to deprecate the practice of having things
>> that belong in / in /usr directory, as opposed to making /usr into a new /.
>>
>> Deprecation of this practice would mean that people could type
>> /bin/command instead of /usr/bin/command in situations where absolute
>> paths are necessary. We could symlink things in /usr to rootfs for
>> compatibility with legacy software. In a more extreme case, we could
>> symlink /usr to /, which would make plenty of sense given that we do not
>> need a separate /usr at all.
> 
> I'm not seeing any compelling benefits here that would justify a lack of
> conformity with other *nix distros. It seems almost as though it's an
> attempt to be different for the sake of being different, perhaps a
> symptom of something like NIH syndrome.

How did RedHat justify that lack of conformity that resulted from moving
everything into /usr in the first place? The original UNIX did not have
anything in /usr. The /usr split was caused by Bell Labs having to grow
UNIX past the constraints of a 1.5MB hard drive. Since we are no longer
limited by such space constraints, I fail to see why we should not
deprecate /usr.

In the meantime, it should be possible to create a global usr USE flag
that enables/disables gen_usr_ldscript. It would then be possible to
delete all of the usr ldscripts, dump /usr into / and symlink /usr to /.
The dynamic linker would go to / before /usr and it would be trivial to
modify $PATH to ignore /usr entirely. Legacy software that requires
/usr/{bin,sbin} would still work while those that want a separate /usr
mount could symlink /usr/{bin,include,libexec,sbin} into their rootfs
counterparts.


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

Re: [gentoo-dev] Re: Let's redesign the entire filesystem!

[Zac Medico]

On 03/14/2012 02:05 PM, Richard Yao wrote:
> How did RedHat justify that lack of conformity that resulted from moving
> everything into /usr in the first place?

Does it really matter? What people in the
separate-/usr-without-initramfs camp really want is continued support
for the "/ is a self-contained boot disk that is independent of /usr"
use case, because without such support, the
separate-/usr-without-initramfs approach that they're accustomed to
becomes impossible.

The /usr merge [1] can be viewed as just one of many signs of a
widespread shift away from supporting the heavy burden of the "/ is a
self-contained boot disk that is independent of /usr" use case.

[1] http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge
-- 
Thanks,
Zac

Re: [gentoo-dev] Re: Let's redesign the entire filesystem!

[Joshua Kinard]

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

On 03/14/2012 16:55, Zac Medico wrote:

>> Deprecation of this practice would mean that people could type
>> /bin/command instead of /usr/bin/command in situations where absolute
>> paths are necessary. We could symlink things in /usr to rootfs for
>> compatibility with legacy software. In a more extreme case, we could
>> symlink /usr to /, which would make plenty of sense given that we do not
>> need a separate /usr at all.
> 
> I'm not seeing any compelling benefits here that would justify a lack of
> conformity with other *nix distros. It seems almost as though it's an
> attempt to be different for the sake of being different, perhaps a
> symptom of something like NIH syndrome.


Gentoo, by its very nature, has always been regarded as somewhat
non-conformist.  When Gentoo first popped onto the scene, most other distros
didn't do colors in the terminal.  We did.  And it all branches out from there.

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

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

--Emperor Turhan, Centauri Republic


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

Re: [gentoo-dev] Re: Let's redesign the entire filesystem!

[Joshua Kinard]

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

On 03/14/2012 14:56, Zac Medico wrote:

> On 03/14/2012 11:36 AM, Maxim Kammerer wrote:
>> On Wed, Mar 14, 2012 at 19:58, Matthew Summers
>> <quantumsummers@gentoo.org> wrote:
>>> Why is an in-kernel initramfs so bad anyway? I am baffled. Its quite
>>> nice to have a minimal recovery env in case mounting fails, etc, etc,
>>> etc.
>>
>> There is nothing bad about initramfs. I think that you are misreading
>> the arguments above.
> 
> Whatever the arguments may be, the whole discussion boils down to the
> fact that the only people who seem to have a "problem" are those that
> have a separate /usr partition and simultaneously refuse to use an
> initramfs.


I refuse to use an initramfs as this point in time because I haven't had to
use one in the past 10 years to get my Gentoo installs to boot.  Right now,
all three active Gentoo installs that I have (x86_64, Vbox, MIPS) boot
*fine* with a separate /usr and no initramfs.  That, in my opinion, is not
"broke", despite statements made to the contrary.

It only became "broke" when individuals not involved with Gentoo declared it
to be "broke", and then back it up with use-case scenarios that are really
only applicable to their distribution of choice.

I'm not saying that I'll continue to not use an initramfs, but I would like
for some Gentoo-specific reasoning to be offered as to why we have to follow
along with this change.  Constantly referring to Fedora or Freedesktop
websites for their reasoning doesn't matter to me.  I don't use Fedora nor
do I use X11 (at least the server.  I tunnel 2-5 X11 apps over SSH, however).

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

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

--Emperor Turhan, Centauri Republic


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

Re: [gentoo-dev] Re: Let's redesign the entire filesystem!

[Jeroen Roovers]

On Wed, 14 Mar 2012 12:58:26 -0500
Matthew Summers <quantumsummers@gentoo.org> wrote:

> __Everyone__ is already using an initramfs, therefore there are no
> initramfs-less systems anymore (it may just be empty).

I happen to understand you're not attempting to start a flame war here,
but it may not obvious to everyone.


     jer (no initrds)

Re: [gentoo-dev] Re: Let's redesign the entire filesystem!

[Luca Barbato]

On 3/14/12 10:58 AM, Matthew Summers wrote:

> __Everyone__ is already using an initramfs, therefore there are no
> initramfs-less systems anymore (it may just be empty). Every single
> person reading this thread that has not already done so needs to
> immediately go read the relevant documentation located in
> /usr/src/linux/Documentation/filesystems/ramfs-rootfs-initramfs.txt,
> then and only then can a real discourse be had.

Yawn, I don't and I won't since I don't need it. Why should I?

> Why is an in-kernel initramfs so bad anyway? I am baffled. Its quite
> nice to have a minimal recovery env in case mounting fails, etc, etc,
> etc.

Because at least for me is *totally* pointless.

My main system is with a single partition so I shouldn't care much, I 
have a system that has a separate /usr so probably I'll have *some* pain 
once I'll upgrade it if I don't merge /usr and / partitions before.

Still the whole idea brings us back to the freebsd "everything in /usr" 
while would make more sense go the hurd way "everything in /" if there 
is a sound reason to merge those. Beside the whole 
/usr/share/id-data-du-jour-my-udev-rule-might-need and the I-want-glib 
and I-want-dbus bandwagon I hadn't seen any compelling reason.

Having anything as complex as dbus for early boot sounds dangerous or frail.

lu

Re: [gentoo-dev] Re: Let's redesign the entire filesystem!

[Rich Freeman]

On Wed, Mar 14, 2012 at 1:29 PM, Zac Medico <zmedico@gentoo.org> wrote:
> On 03/14/2012 10:11 AM, Maxim Kammerer wrote:
>> What's wrong with:
>>   * having an "early mounts" list file
>>   * having an "early modules" list file
>>   * init system in early boot (e.g., OpenRC in init.sh) loading "early
>> modules" and mounting "early mounts" from /etc/fstab
>
> You're assuming that the /sbin/init hasn't migrated to /usr/sbin/init.
> Other that that, it sounds like a perfect solution if you're in the "I'd
> rather die than use an initramfs" camp.

Well, anybody is welcome to create any replacement/addition for
(/usr)/sbin/init or (/usr)/sbin/rc that they wish.  If you make it
good enough, perhaps others will even use it.

Beyond that, anything else is just a suggestion.  In the end the folks
writing udev and systemd are writing code, which gets them a lot
further than emails do...  :)

Rich

Re: [gentoo-dev] Re: Let's redesign the entire filesystem!

[Luca Barbato]

On 3/14/12 10:59 AM, Rich Freeman wrote:
> Well, anybody is welcome to create any replacement/addition for
> (/usr)/sbin/init or (/usr)/sbin/rc that they wish.  If you make it
> good enough, perhaps others will even use it.

There is a SoC out there for that.

> Beyond that, anything else is just a suggestion.  In the end the folks
> writing udev and systemd are writing code, which gets them a lot
> further than emails do...  :)
>

People might be happy with what they have and might feel a bit 
threatened when they have to switch away from the DE they like because 
it forces on them an init system that they hate.

lu

Re: [gentoo-dev] Re: Let's redesign the entire filesystem!

[Joshua Kinard]

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

On 03/14/2012 13:59, Rich Freeman wrote:

> On Wed, Mar 14, 2012 at 1:29 PM, Zac Medico <zmedico@gentoo.org> wrote:
>> On 03/14/2012 10:11 AM, Maxim Kammerer wrote:
>>> What's wrong with:
>>>   * having an "early mounts" list file
>>>   * having an "early modules" list file
>>>   * init system in early boot (e.g., OpenRC in init.sh) loading "early
>>> modules" and mounting "early mounts" from /etc/fstab
>>
>> You're assuming that the /sbin/init hasn't migrated to /usr/sbin/init.
>> Other that that, it sounds like a perfect solution if you're in the "I'd
>> rather die than use an initramfs" camp.
> 
> Well, anybody is welcome to create any replacement/addition for
> (/usr)/sbin/init or (/usr)/sbin/rc that they wish.  If you make it
> good enough, perhaps others will even use it.
> 
> Beyond that, anything else is just a suggestion.  In the end the folks
> writing udev and systemd are writing code, which gets them a lot
> further than emails do...  :)

Debian has a small, yet fairly unique little package called "file-rc" that
replaces their more traditional init system with a single text file,
/etc/runlevels, to manage system services.  A small utility runs that parses
the text file and sets up the /etc/rc.x symlinks for you, based on that file.

Fairly novel little package.  Wholly-incompatible with Gentoo's system,
without fully replacing OpenRC, but I would actually be interested in seeing
something like this on Gentoo (such as something that simply parses and
executes rc-update to change things).

http://packages.debian.org/squeeze/file-rc

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

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

--Emperor Turhan, Centauri Republic


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

Re: [gentoo-dev] Re: Let's redesign the entire filesystem!

[Walter Dnes]

On Wed, Mar 14, 2012 at 08:04:31AM -0700, Greg KH wrote
> On Wed, Mar 14, 2012 at 10:51:44AM -0400, Philip Webb wrote:
> > 120314 Greg KH wrote:
> > > if you have /usr on a different filesystem today, with no initrd,
> > > your machine could be broken and you don't even know it.
> > 
> > Whatever do you mean ? -- if it were truly broken,
> > it wouldn't perform in some important & obvious respect.
> 
> Not always, no, it isn't obvious that something didn't start up
> correctly, or that it didn't fully load properly.  Some programs later
> on recover and handle things better.

  Throwing that one right back at you, if you have /usr on the same file
system, plus you boot with systemd, your machine could be broken and you
don't even know it.

-- 
Walter Dnes <waltdnes@waltdnes.org>

Re: [gentoo-dev] Re: Let's redesign the entire filesystem!

[Joshua Kinard]

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

On 03/14/2012 11:04, Greg KH wrote:

> 
> Not always, no, it isn't obvious that something didn't start up
> correctly, or that it didn't fully load properly.  Some programs later
> on recover and handle things better.


I'm well aware of what I run on my own box, and when something isn't
running, I figure it out pretty quickly.  I tested udev-181 in a Gentoo VM
that I put together recently, giving it a separate /usr, and made sure that
CONFIG_DEVTMPFS was enbaled.  The only service that failed to load properly
at startup was udev, specifically because udevadm couldn't locate libkmod
(likely because kmod installs into /usr/lib*, which wasn't available yet
because I also don't use an initramfs in my kernel).  Everything else worked
fine, and udev later started properly once localmount was complete.

I even tried, out of curiosity, to tweak things and moved udev from sysinit
to boot and then to default runlevel.  In 'boot', udevadm still fails to
load, so no change.  In 'default', only net.lo failed because the 'lo'
device didn't yet exist until after udev was running.  udev itself loaded
fine, and the networking scripts restarted themselves.

So with the one exception of networking, which in Linux, has never created
/dev nodes (has to be some historical piece on why), one almost doesn't need
udev at boot to even get things working on a very simple setup like mine.
And since udev is the one service that didn't load correctly, one COULD put
forth the hypothesis that it is udev that is "broken".  But I doubt that
will get much traction, right?

This does lead me to wonder if a light-weight udev could exist that lacks
half or more of the functionality of the current udev.  I'll be honest, I've
only edited my udev rules file once, and that was only when I installed a
Sun Happy Meal quad ethernet card in which all four ports utilize the same
MAC address and udev doesn't handle this very gracefully (if I had Solaris,
I could edit the card's firmware and change this setting).

Devtmpfs quite literally handles 98% of my particular usage scenario.  Does
that apply to everyone?  Nope.  Just an interesting observation.

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

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

--Emperor Turhan, Centauri Republic


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

Re: [gentoo-dev] Re: Let's redesign the entire filesystem!

[Rich Freeman]

On Thu, Mar 15, 2012 at 7:04 AM, Joshua Kinard <kumba@gentoo.org> wrote:
> This does lead me to wonder if a light-weight udev could exist that lacks
> half or more of the functionality of the current udev.  I'll be honest, I've
> only edited my udev rules file once, and that was only when I installed a
> Sun Happy Meal quad ethernet card in which all four ports utilize the same
> MAC address and udev doesn't handle this very gracefully (if I had Solaris,
> I could edit the card's firmware and change this setting).

You know - I had a similar issue, but with a pair of PL2303 USB RS232
interfaces.  That makes me wonder if there is a possible way to
enhance udev to better handle situations where devices have no unique
ID and thus tend to be difficult to access consistently across
reboots.  In my case I had to hack a rule so that I got a symlink if
the device was in a specific USB slot.  Use case is controlling tuners
for mythtv.

No doubt a simpler 80% solution could be created for udev, and likely
it would be easier to cut down on its dependencies as a result.
However, the other 20% of users will still need the more complete
solution.  Big distros that want to support lots of hardware with a
one-size-fits-all configuration will just deploy that complete
solution everywhere, which means that the only people maintaining the
simple solution would be people who like to tailor each system.

For most of the more enterprise-y OS providers (ie the ones with money
to pay devs), one-size-fits-all is a lot more sustainable.  You won't
find an edition of MS Windows that works only on PCs without scanners
and sound but uses 50MB less RAM, for example.

Sure, we don't have the same constraints as the enterprise-y distros,
but we do have the constraint that if we want to do things differently
we will spend a lot of time patching what we could otherwise simply
reuse as-is.

I don't think that split filesystem installs are going away anytime
soon.  In fact, when btrfs is finally mature we might see them
blossum.  Using subvolumes you could have more granular snapshotting
and mount options, while still maintaining a shared disk space pool
(with granular quotas).  If everything the distro is likely to mangle
is in a few subvolumes you can reverts snapshots on those without
losing changes in other subvolumes if you ran in production before
deciding to revert.  That gets you a lot more flexibility than a
single snapshot on root - especially in terms of recovery time (you
can still copy files between snapshots if you only snapshotted root -
in fact with reflinks this is very fast).

Rich

Re: [gentoo-dev] Re: Let's redesign the entire filesystem!

[Joshua Kinard]

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

On 03/15/2012 08:30, Rich Freeman wrote:

> 
> You know - I had a similar issue, but with a pair of PL2303 USB RS232
> interfaces.  That makes me wonder if there is a possible way to
> enhance udev to better handle situations where devices have no unique
> ID and thus tend to be difficult to access consistently across
> reboots.  In my case I had to hack a rule so that I got a symlink if
> the device was in a specific USB slot.  Use case is controlling tuners
> for mythtv.


I use a ton of the pl2303-based devices, too.  Except I'm usually in Windows
with them, so I just have to deal with Window's oddball way of renumbering
them sometimes when I unplug one and plug it right back into the same USB
slot (i.e., I lost COM11, and it's now COM14, which, ironically, is  outside
the range of TeraTerm)


> No doubt a simpler 80% solution could be created for udev, and likely
> it would be easier to cut down on its dependencies as a result.
> However, the other 20% of users will still need the more complete
> solution.  Big distros that want to support lots of hardware with a
> one-size-fits-all configuration will just deploy that complete
> solution everywhere, which means that the only people maintaining the
> simple solution would be people who like to tailor each system.

That, or udev making more of its functionality optional via its build system
(does it use autotools and configure, I never looked, to be honest?).  This
would allow additional USE flags to be added to enable or disable additional
functionality as needed.


> For most of the more enterprise-y OS providers (ie the ones with money
> to pay devs), one-size-fits-all is a lot more sustainable.  You won't
> find an edition of MS Windows that works only on PCs without scanners
> and sound but uses 50MB less RAM, for example.


Funny, but as much as I am against Windows on a server, Windows Server is
easier to turn off unneeded stuff than RHEL5 is.  Windows Server comes with
audio and TWAIN/IMAPI components disabled (or out right missing -- you have
to add them back in through server manager).  But try to remove features
like sound, CD burning, various media players, text-to-speech, etc, from a
fresh RHEL5 install, and you're in for a fight.  It's not necessarily RHEL's
fault, but more Gnome's fault because of the massive about of
interdependency that you get with Gnome, and the fact RH chose to just not
bother with it and build in a ton of stuff by default.

Ditto for an install of OpenSolaris that I did.


> I don't think that split filesystem installs are going away anytime
> soon.  In fact, when btrfs is finally mature we might see them
> blossum.  Using subvolumes you could have more granular snapshotting
> and mount options, while still maintaining a shared disk space pool
> (with granular quotas).  If everything the distro is likely to mangle
> is in a few subvolumes you can reverts snapshots on those without
> losing changes in other subvolumes if you ran in production before
> deciding to revert.  That gets you a lot more flexibility than a
> single snapshot on root - especially in terms of recovery time (you
> can still copy files between snapshots if you only snapshotted root -
> in fact with reflinks this is very fast).


ZFS encourages creating volumes and filesystems en masse.  Right down to a
separate ZFS mount for each user's home directory under /home, and /home
itself is a mount point.  So yeah, Btrfs, ZFS, etc...get an FS like those
two which not only encourage dozens of mount points, but which seamlessly
hide all the dirty details from you (and the users), and issues like this
will simply vanish into thin air.

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

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

--Emperor Turhan, Centauri Republic


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

Re: [gentoo-dev] Re: Let's redesign the entire filesystem!

[Greg KH]

On Thu, Mar 15, 2012 at 08:30:49AM -0400, Rich Freeman wrote:
> You know - I had a similar issue, but with a pair of PL2303 USB RS232
> interfaces.  That makes me wonder if there is a possible way to
> enhance udev to better handle situations where devices have no unique
> ID and thus tend to be difficult to access consistently across
> reboots.  In my case I had to hack a rule so that I got a symlink if
> the device was in a specific USB slot.  Use case is controlling tuners
> for mythtv.

Why not use the links in /dev/serial/ which are there for this specific
reason?

greg k-h

Re: [gentoo-dev] Re: Let's redesign the entire filesystem!

[Rich Freeman]

On Thu, Mar 15, 2012 at 10:42 AM, Greg KH <gregkh@gentoo.org> wrote:
>
> Why not use the links in /dev/serial/ which are there for this specific
> reason?
>

# ls -l /dev/serial
ls: cannot access /dev/serial: No such file or directory

Something in a newer version of udev perhaps?  Or would my defining my
own symlinks end up overriding some rule elsewhere.  I just added
these lines to /etc/udev/rules.d:
SUBSYSTEM=="tty", DRIVERS=="pl2303", KERNELS=="4-1:1.0",
KERNEL=="ttyUSB*", SYMLINK="mythser/rca1"
SUBSYSTEM=="tty", DRIVERS=="pl2303", KERNELS=="3-3:1.0",
KERNEL=="ttyUSB*", SYMLINK="mythser/rca2"

Rich

[gentoo-dev] /dev/serial/ (was "Let's redesign the entire filesystem!")

[Greg KH]

On Thu, Mar 15, 2012 at 03:04:36PM -0400, Rich Freeman wrote:
> On Thu, Mar 15, 2012 at 10:42 AM, Greg KH <gregkh@gentoo.org> wrote:
> >
> > Why not use the links in /dev/serial/ which are there for this specific
> > reason?
> >
> 
> # ls -l /dev/serial
> ls: cannot access /dev/serial: No such file or directory

Do you have your serial device plugged in?  If not, it will not show up.

> Something in a newer version of udev perhaps?

It went into udev version 136, way back in 2008, so odds are, you have
it on your system...

> Or would my defining my
> own symlinks end up overriding some rule elsewhere.  I just added
> these lines to /etc/udev/rules.d:
> SUBSYSTEM=="tty", DRIVERS=="pl2303", KERNELS=="4-1:1.0",
> KERNEL=="ttyUSB*", SYMLINK="mythser/rca1"
> SUBSYSTEM=="tty", DRIVERS=="pl2303", KERNELS=="3-3:1.0",
> KERNEL=="ttyUSB*", SYMLINK="mythser/rca2"

You do know that USB buses can be dynamically renumbered depending on
the phase of the moon, right?  Be careful here...

greg k-h

Re: [gentoo-dev] /dev/serial/ (was "Let's redesign the entire filesystem!")

[Rich Freeman]

On Thu, Mar 15, 2012 at 3:17 PM, Greg KH <gregkh@gentoo.org> wrote:
> On Thu, Mar 15, 2012 at 03:04:36PM -0400, Rich Freeman wrote:
>> # ls -l /dev/serial
>> ls: cannot access /dev/serial: No such file or directory
>
> Do you have your serial device plugged in?  If not, it will not show up.
>

Yup - it is plugged in, and the links in /dev/mythser show up fine.
Since I've been recording my TV shows on the correct channels I have
to assume the devices are working fine too.

> You do know that USB buses can be dynamically renumbered depending on
> the phase of the moon, right?  Be careful here...

Hmm - this has been stable for me for years, compared to just using
/dev/ttyUSBn.

In any case, I have no idea why nothing shows up in /dev/serial.  The
only device nodes I can find for serial are /dev/ttyUSBn and
/dev/mythser/n (the latter being from my own rules).

Rich

Re: [gentoo-dev] Re: Let's redesign the entire filesystem!

[Greg KH]

On Thu, Mar 15, 2012 at 07:04:52AM -0400, Joshua Kinard wrote:
> Devtmpfs quite literally handles 98% of my particular usage scenario.  Does
> that apply to everyone?  Nope.  Just an interesting observation.

devtmpfs does not handle device permissions.

As for a "smaller" udev, feel free to try, please realize that this that
is what udev used to be, before it was fixed to work properly.  udev is
very small and compact, but patches to make it smaller are always
welcome.

There's always mudev if you don't want to run udev, good luck with that.

greg k-h

Re: [gentoo-dev] Re: Let's redesign the entire filesystem!

[Joshua Kinard]

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

On 03/15/2012 10:41, Greg KH wrote:

> 
> There's always mudev if you don't want to run udev, good luck with that.


Got a link?  We don't have anything matching in the tree, and Google turns
up nothing relevant in the first few pages.

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

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

--Emperor Turhan, Centauri Republic


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

Re: [gentoo-dev] Re: Let's redesign the entire filesystem!

[Greg KH]

On Thu, Mar 15, 2012 at 08:47:12PM -0400, Joshua Kinard wrote:
> On 03/15/2012 10:41, Greg KH wrote:
> 
> > 
> > There's always mudev if you don't want to run udev, good luck with that.
> 
> 
> Got a link?  We don't have anything matching in the tree, and Google turns
> up nothing relevant in the first few pages.

Sorry, I think it's called 'mdev' and is part of busybox.

greg "no one asked me to adopt a package, amazing" k-h

Re: [gentoo-dev] Re: Let's redesign the entire filesystem!

[Richard Yao]

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

On 03/15/12 22:43, Greg KH wrote:
> On Thu, Mar 15, 2012 at 08:47:12PM -0400, Joshua Kinard wrote:
>> On 03/15/2012 10:41, Greg KH wrote:
>>
>>>
>>> There's always mudev if you don't want to run udev, good luck with that.
>>
>>
>> Got a link?  We don't have anything matching in the tree, and Google turns
>> up nothing relevant in the first few pages.
> 
> Sorry, I think it's called 'mdev' and is part of busybox.
> 
> greg "no one asked me to adopt a package, amazing" k-h

How about app-editors/bvi?


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

Re: [gentoo-dev] Re: Let's redesign the entire filesystem!

[Greg KH]

On Thu, Mar 15, 2012 at 11:01:19PM -0400, Richard Yao wrote:
> On 03/15/12 22:43, Greg KH wrote:
> > On Thu, Mar 15, 2012 at 08:47:12PM -0400, Joshua Kinard wrote:
> >> On 03/15/2012 10:41, Greg KH wrote:
> >>
> >>>
> >>> There's always mudev if you don't want to run udev, good luck with that.
> >>
> >>
> >> Got a link?  We don't have anything matching in the tree, and Google turns
> >> up nothing relevant in the first few pages.
> > 
> > Sorry, I think it's called 'mdev' and is part of busybox.
> > 
> > greg "no one asked me to adopt a package, amazing" k-h
> 
> How about app-editors/bvi?

A whole separate package for a tool that reimplements 'vim -b' mode?
That seems pointless, sorry.

At least find a package that people use :)

greg k-h

Re: [gentoo-dev] Re: Let's redesign the entire filesystem!

[Michael Orlitzky]

On 03/16/12 11:18, Greg KH wrote:
> 
> At least find a package that people use :)
> 

www-client/httrack?

Re: [gentoo-dev] Re: Let's redesign the entire filesystem!

[Richard Yao]

Take your pick:

http://www.gentoo.org/proj/en/qa/treecleaners/maintainer-needed.xml

On Fri, Mar 16, 2012 at 11:18 AM, Greg KH <gregkh@gentoo.org> wrote:
> On Thu, Mar 15, 2012 at 11:01:19PM -0400, Richard Yao wrote:
>> On 03/15/12 22:43, Greg KH wrote:
>> > On Thu, Mar 15, 2012 at 08:47:12PM -0400, Joshua Kinard wrote:
>> >> On 03/15/2012 10:41, Greg KH wrote:
>> >>
>> >>>
>> >>> There's always mudev if you don't want to run udev, good luck with that.
>> >>
>> >>
>> >> Got a link?  We don't have anything matching in the tree, and Google turns
>> >> up nothing relevant in the first few pages.
>> >
>> > Sorry, I think it's called 'mdev' and is part of busybox.
>> >
>> > greg "no one asked me to adopt a package, amazing" k-h
>>
>> How about app-editors/bvi?
>
> A whole separate package for a tool that reimplements 'vim -b' mode?
> That seems pointless, sorry.
>
> At least find a package that people use :)
>
> greg k-h

Re: [gentoo-dev] Let's redesign the entire filesystem! [was newsitem: unmasking udev-181]

[Marc Schiffbauer]

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

Am Montag, 12. März 2012, 21:22:26 schrieb Joshua Kinard:
[...]
> After all, /usr was originally for user data, not system data,
> until someone cooked up /home (I don't know the full exact history here, so
> feel free to correct me).

IIRC usr = unified system resources (not an abbrev. for "user")

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

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

Re: [gentoo-dev] Let's redesign the entire filesystem! [was newsitem: unmasking udev-181]

[James Broadhead]

On 13 March 2012 14:41, Marc Schiffbauer <mschiff@gentoo.org> wrote:
> Am Montag, 12. März 2012, 21:22:26 schrieb Joshua Kinard:
> [...]
>> After all, /usr was originally for user data, not system data,
>> until someone cooked up /home (I don't know the full exact history here, so
>> feel free to correct me).
>
> IIRC usr = unified system resources (not an abbrev. for "user")
>
> -Marc
> --
> 0x35A64134 - 8AAC 5F46 83B4 DB70 8317  3723 296C 6CCA 35A6 4134

Again, backwards justification for a directory name that was already in place.

Re: [gentoo-dev] Let's redesign the entire filesystem! [was newsitem: unmasking udev-181]

[James Cloos]

>>>>> "MS" == Marc Schiffbauer <mschiff@gentoo.org> writes:

MS> IIRC usr = unified system resources (not an abbrev. for "user")

Nope.  It is in fact for user.

Before sysv created /home, bsd used /usr for user dirs.

/usr/bin et all came later.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

Re: [gentoo-dev] Let's redesign the entire filesystem! [was newsitem: unmasking udev-181]

[Zac Medico]

On 03/14/2012 05:00 AM, James Cloos wrote:
>>>>>> "MS" == Marc Schiffbauer <mschiff@gentoo.org> writes:
> 
> MS> IIRC usr = unified system resources (not an abbrev. for "user")
> 
> Nope.  It is in fact for user.
> 
> Before sysv created /home, bsd used /usr for user dirs.
> 
> /usr/bin et all came later.

Anyway, "unified system resources" makes a great retro-active acronym,
don't you think? What's in a name?
-- 
Thanks,
Zac

[gentoo-dev] Re: Let's redesign the entire filesystem! [was newsitem: unmasking udev-181]

[Duncan]

Zac Medico posted on Wed, 14 Mar 2012 10:52:48 -0700 as excerpted:

> On 03/14/2012 05:00 AM, James Cloos wrote:
>>>>>>> "MS" == Marc Schiffbauer <mschiff@gentoo.org> writes:
>> 
>> MS> IIRC usr = unified system resources (not an abbrev. for "user")

>> Before sysv created /home, bsd used /usr for user dirs.

> Anyway, "unified system resources" makes a great retro-active acronym,
> don't you think? What's in a name?

It does, especially when it's literally the case, including a /usr/etc 
bind-mounted on a tmpfs-based rootfs, that by login time, all that's 
visible of rootfs is mountpoints, nothing else, and /usr literally IS the 
"unified system resource" filesystem.

-- 
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: Let's redesign the entire filesystem! [was newsitem: unmasking udev-181]

[Kent Fredric]

On 15 March 2012 07:48, Duncan <1i5t5.duncan@cox.net> wrote:
> It does, especially when it's literally the case, including a /usr/etc
> bind-mounted on a tmpfs-based rootfs, that by login time, all that's
> visible of rootfs is mountpoints, nothing else, and /usr literally IS the
> "unified system resource" filesystem.

Considering this pretty much eliminates using / for anything useful,
we might as well rename "/usr"  "/c"

Even if it /is/ just to confuse the windows crowd =)


-- 
Kent

perl -e  "print substr( \"edrgmaM  SPA NOcomil.ic\\@tfrken\", \$_ * 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"

[gentoo-dev] Re: Let's redesign the entire filesystem! [was newsitem: unmasking udev-181]

[Duncan]

Kent Fredric posted on Thu, 15 Mar 2012 09:10:53 +1300 as excerpted:

> On 15 March 2012 07:48, Duncan <1i5t5.duncan@cox.net> wrote:
>> It does, especially when it's literally the case, including a /usr/etc
>> bind-mounted on a tmpfs-based rootfs, that by login time, all that's
>> visible of rootfs is mountpoints, nothing else, and /usr literally IS
>> the "unified system resource" filesystem.
> 
> Considering this pretty much eliminates using / for anything useful,
> we might as well rename "/usr"  "/c"
> 
> Even if it /is/ just to confuse the windows crowd =)

LOL!  I've been off of MS over a decade now, and simply don't think of 
them that much any more.  I had no clue what you were referencing... 
until I read that last line.  You rather confused me! =:^)

-- 
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: Let's redesign the entire filesystem! [was newsitem: unmasking udev-181]

[Joshua Kinard]

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

On 03/14/2012 16:10, Kent Fredric wrote:

> 
> Considering this pretty much eliminates using / for anything useful,
> we might as well rename "/usr"  "/c"
> 
> Even if it /is/ just to confuse the windows crowd =)


Unless you're one of those that installs Windows into D:\ :)

I'd say call it /sys for NetWare's old SYS:\ volume, but that's already
taken by sysfs.

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

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

--Emperor Turhan, Centauri Republic


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

Re: [gentoo-dev] Re: newsitem: unmasking udev-181

[Luca Barbato]

On 3/11/12 10:33 AM, William Hubbs wrote:
> On Sat, Mar 10, 2012 at 07:28:41PM -0800, Luca Barbato wrote:
>> On 3/10/12 6:53 PM, Rich Freeman wrote:
>>> neither the genkernel nor dracut docs have specific instructions about
>>
>> I guess we could pour more effort in getting dracut more easy to use
>> and/or try to figure out which are the items that should be moved to /
>> and fix the remaining ones...
>
> I highly discourage moving more things to /.  If you google for things
> like, "case for usr merge", "understanding bin split", etc, you will
> find much information that is very enlightening about the /usr merge and
> the reasons for the /bin, /lib, /sbin ->  /usr/* split.

Our current init system doesn't have any problem with /usr being mounted 
later, but udev might have issues.

Same could be said about bluez and dbus.

> I'll start another thread about this farely soon, but for now I'll say
> that even though Fedora is a strong advocate of the /usr merge, it
> didn't start there. Solaris started this 15 years ago, and I think it
> would be a good thing for gentoo to implement the /usr merge at some
> point to make us more compatible with other unixes. Another thing to add
> is that it appears that at least Fedora and Debian are doing this.

Hurd got it first if I recall correctly. But hurd is a bit fringe I'd say.

lu

Re: [gentoo-dev] Re: newsitem: unmasking udev-181

[Joshua Kinard]

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

On 03/13/2012 01:11, Luca Barbato wrote:

> 
> Our current init system doesn't have any problem with /usr being mounted
> later, but udev might have issues.
> 
> Same could be said about bluez and dbus.


bluez and dbus aren't system-critical services, however.  udev kinda is,
along with key filesystem tools.

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

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

--Emperor Turhan, Centauri Republic


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

[gentoo-dev] Re: newsitem: unmasking udev-181

[Duncan]

Joshua Kinard posted on Tue, 13 Mar 2012 20:13:53 -0400 as excerpted:

> On 03/13/2012 01:11, Luca Barbato wrote:
> 
>> Our current init system doesn't have any problem with /usr being
>> mounted later, but udev might have issues.
>> 
>> Same could be said about bluez and dbus.
> 
> bluez and dbus aren't system-critical services, however.  udev kinda is,
> along with key filesystem tools.

Bluez is a critical system service if that's your keyboard and you need 
to do init-diagnostics.  Dbus isn't... yet... but it's likely to be, for 
some people at least, within a couple years, as systemd's going to be 
using it, and other init services will assume/require it before /they/ 
come up.

-- 
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: newsitem: unmasking udev-181

[Joshua Kinard]

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

On 03/14/2012 04:03, Duncan wrote:

> 
> Bluez is a critical system service if that's your keyboard and you need 
> to do init-diagnostics.  Dbus isn't... yet... but it's likely to be, for 
> some people at least, within a couple years, as systemd's going to be 
> using it, and other init services will assume/require it before /they/ 
> come up.


Ah, bluetooth keyboards.  The luddite in me finds those quite the oddity.  I
still use only PS/2, specifically because it's less complex and less likely
to fail on me in a time of need.

Or, put more comically:
http://megatokyo.com/strip/305

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

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

--Emperor Turhan, Centauri Republic


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

[gentoo-dev] Re: newsitem: unmasking udev-181

[Duncan]

Joshua Kinard posted on Wed, 14 Mar 2012 08:07:07 -0400 as excerpted:

> Ah, bluetooth keyboards.  The luddite in me finds those quite the
> oddity.
> I still use only PS/2, specifically because it's less complex and less
> likely to fail on me in a time of need.
> 
> Or, put more comically:
> http://megatokyo.com/strip/305

I was in that group for a long time, myself, but eventually graduated to 
a usb keyboard when I realized that the usb/wireless adapter I was using 
for combined mouse/keyboard, only needed one plug when it was using usb, 
two when using ps/2, and I was switching it around between computers.  So 
usb's the one I have setup in both BIOS and the kernel, now.

bluez keyboards require userspace, tho, I believe, thus the early-boot 
factor we're discussing.  If I had a choice I'd avoid that, just as you.  
But some folks don't have that choice, or if they do it's between that 
and a touchscreen, also requiring userspace.

I think rich0 is correct in viewing it as simply adding a few special-
casing scripts to the kernel tarball (initramfs), tho, adding to the 
already special-case asm and the bootloader requirements...  It's not 
exactly pleasant to have to adapt, but at least most of the linux world 
will eventually take it for granted.   Well, probably most already does, 
but now it's getting even MORE required.

-- 
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: newsitem: unmasking udev-181

[Walter Dnes]

On Wed, Mar 14, 2012 at 08:07:07AM -0400, Joshua Kinard wrote

> Ah, bluetooth keyboards.  The luddite in me finds those quite
> the oddity.  I still use only PS/2, specifically because it's less
> complex and less likely to fail on me in a time of need.

  Unicomp has licenced manufacturing rights to the IBM Model M keyboard,
with USB adapter, of course.  http://pckeyboard.com/page/product/UNI041A
Look Ma, no Windows keys!  If you do want Windows keys, you can order
http://pckeyboard.com/page/product/UNI0P4A

  And if you want an original with PS/2 connector, they also offer
http://pckeyboard.com/page/category/IBMKBD

-- 
Walter Dnes <waltdnes@waltdnes.org>

Re: [gentoo-dev] Re: newsitem: unmasking udev-181

[Joshua Kinard]

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

On 03/14/2012 17:13, Walter Dnes wrote:

> On Wed, Mar 14, 2012 at 08:07:07AM -0400, Joshua Kinard wrote
> 
>> Ah, bluetooth keyboards.  The luddite in me finds those quite
>> the oddity.  I still use only PS/2, specifically because it's less
>> complex and less likely to fail on me in a time of need.
> 
>   Unicomp has licenced manufacturing rights to the IBM Model M keyboard,
> with USB adapter, of course.  http://pckeyboard.com/page/product/UNI041A
> Look Ma, no Windows keys!  If you do want Windows keys, you can order
> http://pckeyboard.com/page/product/UNI0P4A
> 
>   And if you want an original with PS/2 connector, they also offer
> http://pckeyboard.com/page/category/IBMKBD


I actually have an original IBM Model M.  Manufacture date of July 22nd,
1987.  And I use Windows on a regular basis.  Yet, I get by without the
windows key quite well.  About the only two shortcuts I ever used were WIN+E
and WIN+R, for Explorer and Run.  It's not as useful of a key as many people
think it is.  It's actually more beneficial to those with disabilities, such
as low or impaired vision.

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

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

--Emperor Turhan, Centauri Republic


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

Re: [gentoo-dev] Re: newsitem: unmasking udev-181

[Robin H. Johnson]

On Thu, Mar 15, 2012 at 09:10:50AM -0400, Joshua Kinard wrote:
> I actually have an original IBM Model M.  Manufacture date of July 22nd,
> 1987.  And I use Windows on a regular basis.  Yet, I get by without the
> windows key quite well.  About the only two shortcuts I ever used were WIN+E
> and WIN+R, for Explorer and Run.  It's not as useful of a key as many people
> think it is.  It's actually more beneficial to those with disabilities, such
> as low or impaired vision.
And for remapping as a Meta key...

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

Re: [gentoo-dev] Re: newsitem: unmasking udev-181

[Dale]

Rich Freeman wrote:
> On Sat, Mar 10, 2012 at 9:27 PM, William Hubbs <williamh@gentoo.org> wrote:
>> here is the udev 181 unmasking news item.
>>
>> If all goes well, this will be committed to the tree  on 3/14 UTC.
> 
> I guess this might be OK for unstable, but before this goes stable we
> really need to improve the docs around this.  As far as I can tell
> neither the genkernel nor dracut docs have specific instructions about
> how to handle mounting /usr.  Since having a separate /usr is often
> the result of having a more complex configuration (nfs, lvm, mdraid,
> etc), instructions explaining how things work and how to handle
> variations is pretty important.  Perhaps genkernel automagically does
> the right thing in some cases, but I know that dracut does not unless
> you properly configure it.  I doubt either tool will handle more
> complex situations without some scripting.
> 
> I'm not really asking for automation here - just documentation and
> reasonable stability in how things work.
> 
> Again, this is likely more of a concern before this is stabilized.
> However, knowing what I went through to get my bind-mounted /usr on
> LVM+mdraid working with dracut, I can imagine that any unstable users
> with tricky setups could face a fun weekend.
> 
> Perhaps a suggestion for the news item.  I'd recommend that anybody
> who needs an initramfs to mount /usr get that working BEFORE they
> upgrade udev.  This situation is a heck of a lot easier to figure out
> if the system still can be booted when the initramfs doesn't work.
> 
> Rich
> 
> 


+1

Dale

:-)  :-)

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

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

[gentoo-dev] Re: newsitem: unmasking udev-181

[Duncan]

Rich Freeman posted on Sat, 10 Mar 2012 21:53:25 -0500 as excerpted:

> On Sat, Mar 10, 2012 at 9:27 PM, William Hubbs <williamh@gentoo.org>
> wrote:
>> here is the udev 181 unmasking news item.
>>
>> If all goes well, this will be committed to the tree  on 3/14 UTC.
> 
> I guess this might be OK for unstable, but before this goes stable we
> really need to improve the docs around this.

Definitely agreed.  Before it's unmasked to stable, there should be a 
nice step-by-step upgrade guide.  In general, ~arch users are expected to 
be able to take care of themselves to a large degree, while stable users, 
pretty much simply need to know how to follow the step-by-step 
instructions in the handbook well enough to get a running system.  Thus, 
for critical upgrades that are likely to leave the system unbootable if 
they're not handled correctly, they need and gentoo has in the past 
normally provided, a nice step-by-step upgrade guide.

It's a tall order in some ways, and I /think/ the baselayout-2/openrc 
upgrade broke that tradition to some extent as it was unmasked to stable 
before the docs were done properly, but that's in the past now and should 
remain the exception.

That is, unless we're prepared to change the definition of stable (or 
even simply get rid of it entirely, referring people that need it to arch 
or some other distro), and if we're doing that, there really should be a 
discussion about it and a proper decision, council or even full active 
dev vote, story on the gentoo.org front page, etc.  As I run ~arch 
anyway, I personally would certainly not oppose such an idea, but we 
shouldn't just let gentoo slip into it; if it's going to happen, it 
should be a deliberate decision taken after a discussion on the merits.

> I'm not really asking for automation here - just documentation and
> reasonable stability in how things work.

Exactly.

> Again, this is likely more of a concern before this is stabilized.

Right, but as it's headed for ~arch now, this is the time to get planning 
for stabilization.

> However, knowing what I went through to get my bind-mounted /usr on
> LVM+mdraid working with dracut, I can imagine that any unstable users
> with tricky setups could face a fun weekend.

Yes, indeed.  I'd actually suggest a 1-2 week advance notice news item 
for exactly that reason, even for ~arch, perhaps /especially/ for ~arch, 
since the nice upgrade guide isn't there yet.  Yes, that means delaying 
the unmasking at this point, but it can be done well, or it can be done 
haphazardly.

Actually, ideally, there'd be a good start on the upgrade guide for ~arch 
as well, tho it wouldn't need to be perfect.  Then ~arch users could be 
more effectively encouraged to do what they're /supposed/ to do, report 
bugs when things don't go well, so they can be fixed before unmasking to 
stable, for the upgrade guide that goes along with it, too! =:^)

But that's simply the ideal.  ~arch users should be able to take care of 
themselves, given a few days notice, anyway.  Using them to help debug 
the upgrade doc at the same time is indeed the ideal, but regardless of 
that, arch users should still get by, the chance to use them to debug 
corner-cases in the docs before unmasking to stable, is just lost.

> Perhaps a suggestion for the news item.  I'd recommend that anybody who
> needs an initramfs to mount /usr get that working BEFORE they upgrade
> udev.  This situation is a heck of a lot easier to figure out if the
> system still can be booted when the initramfs doesn't work.

Yes.  This is another reason to put the news item out there a couple 
weeks early, with the "strong recommendation" for those with a separate 
/usr to get the initramfs up and working BEFORE udev-181 is unmasked, and 
a couple weeks lead time on the news item, in ordered to let them do it.

IMO, I'm not the package maintainer or the arch folks that will be doing 
the stabilizing, nor the one that will have to deal with the bugs, etc.  
So just IMO.

-- 
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: newsitem: unmasking udev-181

[Petteri Räty]

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

On 11.03.2012 04:53, Rich Freeman wrote:
> On Sat, Mar 10, 2012 at 9:27 PM, William Hubbs <williamh@gentoo.org> wrote:
>> here is the udev 181 unmasking news item.
>>
>> If all goes well, this will be committed to the tree  on 3/14 UTC.
> 
> I guess this might be OK for unstable, but before this goes stable we
> really need to improve the docs around this.  As far as I can tell
> neither the genkernel nor dracut docs have specific instructions about
> how to handle mounting /usr.  Since having a separate /usr is often
> the result of having a more complex configuration (nfs, lvm, mdraid,
> etc), instructions explaining how things work and how to handle
> variations is pretty important.  Perhaps genkernel automagically does
> the right thing in some cases, but I know that dracut does not unless
> you properly configure it.  I doubt either tool will handle more
> complex situations without some scripting.
> 

The Display-If-Installed atom shows the news item to stable users once
it's committed. I am not sure at what point does Portage show it when
the atom is >= so we might want to evaluate the options. In the long
term we really should have a new revision that enables something like
Display-If-Installed && Display-If-Unmasked.

Regards,
Petteri


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

Re: [gentoo-dev] Re: newsitem: unmasking udev-181

[Zac Medico]

On 03/11/2012 04:03 AM, Petteri Räty wrote:
> The Display-If-Installed atom shows the news item to stable users once
> it's committed. I am not sure at what point does Portage show it when
> the atom is >= so we might want to evaluate the options. 

It's displayed after the package is installed, before emerge exits, just
after the message about config file updates.
-- 
Thanks,
Zac

Re: [gentoo-dev] Re: newsitem: unmasking udev-181

[Petteri Räty]

On 11.3.2012 17.33, Zac Medico wrote:
> On 03/11/2012 04:03 AM, Petteri Räty wrote:
>> The Display-If-Installed atom shows the news item to stable users once
>> it's committed. I am not sure at what point does Portage show it when
>> the atom is >= so we might want to evaluate the options. 
> 
> It's displayed after the package is installed, before emerge exits, just
> after the message about config file updates.

Based on this I think >= is better than < so people will get when they
actually update.

Regards,
Petteri

Re: [gentoo-dev] Re: newsitem: unmasking udev-181

[William Hubbs]

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

On Sun, Mar 11, 2012 at 11:28:19PM +0200, Petteri Räty wrote:
> On 11.3.2012 17.33, Zac Medico wrote:
> > On 03/11/2012 04:03 AM, Petteri Räty wrote:
> >> The Display-If-Installed atom shows the news item to stable users once
> >> it's committed. I am not sure at what point does Portage show it when
> >> the atom is >= so we might want to evaluate the options. 
> > 
> > It's displayed after the package is installed, before emerge exits, just
> > after the message about config file updates.
> 
> Based on this I think >= is better than < so people will get when they
> actually update.

That means that people won't be notified that they have the news item to
read until after they install >= sys-fs/udev-181.

Is that how we would want this to work?

William

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

Re: [gentoo-dev] Re: newsitem: unmasking udev-181

[Petteri Räty]

On 11.3.2012 23.43, William Hubbs wrote:
> On Sun, Mar 11, 2012 at 11:28:19PM +0200, Petteri Räty wrote:
>> On 11.3.2012 17.33, Zac Medico wrote:
>>> On 03/11/2012 04:03 AM, Petteri Räty wrote:
>>>> The Display-If-Installed atom shows the news item to stable users once
>>>> it's committed. I am not sure at what point does Portage show it when
>>>> the atom is >= so we might want to evaluate the options. 
>>>
>>> It's displayed after the package is installed, before emerge exits, just
>>> after the message about config file updates.
>>
>> Based on this I think >= is better than < so people will get when they
>> actually update.
> 
> That means that people won't be notified that they have the news item to
> read until after they install >= sys-fs/udev-181.
> 
> Is that how we would want this to work?
> 
> William

How do you plan to handle notifying stable users if you go with <?

Petteri

Re: [gentoo-dev] Re: newsitem: unmasking udev-181

[William Hubbs]

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

On Sun, Mar 11, 2012 at 11:48:19PM +0200, Petteri Räty wrote:
> On 11.3.2012 23.43, William Hubbs wrote:
> > On Sun, Mar 11, 2012 at 11:28:19PM +0200, Petteri Räty wrote:
> >> On 11.3.2012 17.33, Zac Medico wrote:
> >>> On 03/11/2012 04:03 AM, Petteri Räty wrote:
> >>>> The Display-If-Installed atom shows the news item to stable users once
> >>>> it's committed. I am not sure at what point does Portage show it when
> >>>> the atom is >= so we might want to evaluate the options. 
> >>>
> >>> It's displayed after the package is installed, before emerge exits, just
> >>> after the message about config file updates.
> >>
> >> Based on this I think >= is better than < so people will get when they
> >> actually update.
> > 
> > That means that people won't be notified that they have the news item to
> > read until after they install >= sys-fs/udev-181.
> > 
> > Is that how we would want this to work?
> > 
> > William
> 
> How do you plan to handle notifying stable users if you go with <?

I was thinking of another news item once we are ready to go stable.

What do you think?

William


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

Re: [gentoo-dev] Re: newsitem: unmasking udev-181

[Rich Freeman]

On Sun, Mar 11, 2012 at 7:15 PM, William Hubbs <williamh@gentoo.org> wrote:
>
> I was thinking of another news item once we are ready to go stable.
>
> What do you think?
>

I think that makes the most sense.  That news item can include links
to the documentation that gets written over the next few months.

Rich

Re: [gentoo-dev] Re: newsitem: unmasking udev-181

[Matthias Hanft]

Rich Freeman wrote:
>
> I think that makes the most sense.  That news item can include links
> to the documentation that gets written over the next few months.

In the German (not Gentoo-specific) newsgroup de.comp.os.unix.linux.misc,
someone mentioned that he upgraded to udev-180 and lost the device nodes
for the hard disk (or something like that) because CONFIG_DEVTMPFS was
not set in his kernel configuration.  He says udev>=180 needs DEVTMPFS
set.  Is there any issue with Gentoo's udev-181 and CONFIG_DEVTMPFS?
If so, you should include it in the documentation.

-Matt

Re: [gentoo-dev] Re: newsitem: unmasking udev-181

[Robin H. Johnson]

On Mon, Mar 12, 2012 at 06:01:21PM +0100, Matthias Hanft wrote:
> Rich Freeman wrote:
> >
> > I think that makes the most sense.  That news item can include links
> > to the documentation that gets written over the next few months.
> 
> In the German (not Gentoo-specific) newsgroup de.comp.os.unix.linux.misc,
> someone mentioned that he upgraded to udev-180 and lost the device nodes
> for the hard disk (or something like that) because CONFIG_DEVTMPFS was
> not set in his kernel configuration.  He says udev>=180 needs DEVTMPFS
> set.  Is there any issue with Gentoo's udev-181 and CONFIG_DEVTMPFS?
We already issue a warning if you do not have CONFIG_DEVTMPFS.

It is required.

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

Re: [gentoo-dev] Re: newsitem: unmasking udev-181

[Petteri Räty]

On 12.3.2012 1.15, William Hubbs wrote:
>>
>> How do you plan to handle notifying stable users if you go with <?
> 
> I was thinking of another news item once we are ready to go stable.
> 
> What do you think?
> 
> William
> 

We could reuse the same news item if we now release it as >= and then
release a new revision when it's ready for stable by changing the atom
to <. This way stable users would not get the same item twice.

Regards,
Petteri

Re: [gentoo-dev] Re: newsitem: unmasking udev-181

[Robin H. Johnson]

On Sat, Mar 10, 2012 at 09:53:25PM -0500, Rich Freeman wrote:
> On Sat, Mar 10, 2012 at 9:27 PM, William Hubbs <williamh@gentoo.org> wrote:
> > here is the udev 181 unmasking news item.
> >
> > If all goes well, this will be committed to the tree ?on 3/14 UTC.
> 
> I guess this might be OK for unstable, but before this goes stable we
> really need to improve the docs around this.  As far as I can tell
> neither the genkernel nor dracut docs have specific instructions about
> how to handle mounting /usr.  Since having a separate /usr is often
> the result of having a more complex configuration (nfs, lvm, mdraid,
> etc), instructions explaining how things work and how to handle
> variations is pretty important.  Perhaps genkernel automagically does
> the right thing in some cases, but I know that dracut does not unless
> you properly configure it.  I doubt either tool will handle more
> complex situations without some scripting.
With the new versions of genkernel as specified in the news item, you do
NOT need any specific instructions about /usr. Just upgrade your
genkernel and openrc, and (re)build your initramfs, done.

> Again, this is likely more of a concern before this is stabilized.
> However, knowing what I went through to get my bind-mounted /usr on
> LVM+mdraid working with dracut, I can imagine that any unstable users
> with tricky setups could face a fun weekend.
Your bind-mount /usr and a symlink at /usr to /home/usr are the most
troublesome cases for genkernel that I'm aware of.

For both of those cases, just add extra lines to /etc/initramfs.mounts
should suffice your needs. I realized that I hadn't given much
documentation in that file, so I added a much more detailed example in
genkernel-3.4.25-r1.

If you could please test your LVM+MDRAID+bind-mount setup with
genkernel-3.4.25-r1, I'd like to know your results.
genkernel --lvm --mdadm should cover most of it.

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

Re: [gentoo-dev] Re: newsitem: unmasking udev-181

[Walter Dnes]

On Sat, Mar 10, 2012 at 09:53:25PM -0500, Rich Freeman wrote

> Perhaps a suggestion for the news item.  I'd recommend that anybody
> who needs an initramfs to mount /usr get that working BEFORE they
> upgrade udev.  This situation is a heck of a lot easier to figure out
> if the system still can be booted when the initramfs doesn't work.

  Question... does it have to be an initramfs, or can the vast majority
of simple cases be handled by a simple initscript in /bin or /sbin that
mounts /usr, and does whatever else is required, before handing off
control to /sbin/init.

  I've migrated to mdev, so I won't be seeing this problem, but a simple
solution that works for 95% of users might be the way to go.  For the
more complex situations, an initramfs will be necessary.

-- 
Walter Dnes <waltdnes@waltdnes.org>

Re: [gentoo-dev] Re: newsitem: unmasking udev-181

[Canek Peláez Valdés]

On Tue, Mar 13, 2012 at 2:43 AM, Walter Dnes <waltdnes@waltdnes.org> wrote:
> On Sat, Mar 10, 2012 at 09:53:25PM -0500, Rich Freeman wrote
>
>> Perhaps a suggestion for the news item.  I'd recommend that anybody
>> who needs an initramfs to mount /usr get that working BEFORE they
>> upgrade udev.  This situation is a heck of a lot easier to figure out
>> if the system still can be booted when the initramfs doesn't work.
>
>  Question... does it have to be an initramfs, or can the vast majority
> of simple cases be handled by a simple initscript in /bin or /sbin that
> mounts /usr, and does whatever else is required, before handing off
> control to /sbin/init.
>
>  I've migrated to mdev, so I won't be seeing this problem, but a simple
> solution that works for 95% of users might be the way to go.  For the
> more complex situations, an initramfs will be necessary.

The devs are already discussing moving /bin/* to /usr/bin/* (if I
understood correctly), so this will not last.

And besides, genkernel and dracut are automatized; they *are* the
simple (and proper, IMHO) solution.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-dev] Re: newsitem: unmasking udev-181

[Joshua Kinard]

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

On 03/13/2012 05:14, Canek Peláez Valdés wrote:

> 
> And besides, genkernel and dracut are automatized; they *are* the
> simple (and proper, IMHO) solution.


My contention is that I shouldn't need an initramfs loaded into my kernel to
get my system into a minimally-usable state.  I've been running separate
/usr setups for 10+ years, and only now, such a setup breaks, hence my beef
with Fedora's assertion that such a setup is wrong.  And I'm not even doing
anything fancy!  No encryption, no lvm/evms, no software RAID (on x86/x64 --
MIPS systems run mdadm), plain ext3/ext4 filesystems.  I *shouldn't* need to
start including an initramfs in my kernel to work around this.

make menuconfig, make <bzImage|vmlinux[.32]>[, make modules[_install]], then
update the bootloader, is how I've done kernels for the longest time.  This
new approach makes the above command sequence invalid if under a separate /usr.

From a technical perspective, my argument is a moot point and is easily
remedied.  But I'm making it from a more philosophical standpoint because
what once was a working setup, however uncommon, is not any more, and that
to me is broken.  I've essentially lost some amount of "freedom" in my
choice of running a Linux box.

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

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

--Emperor Turhan, Centauri Republic


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

Re: [gentoo-dev] Re: newsitem: unmasking udev-181

[Stelian Ionescu]

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

On Tue, 2012-03-13 at 20:29 -0400, Joshua Kinard wrote:
> On 03/13/2012 05:14, Canek Peláez Valdés wrote:
> 
> > 
> > And besides, genkernel and dracut are automatized; they *are* the
> > simple (and proper, IMHO) solution.
> 
> 
> My contention is that I shouldn't need an initramfs loaded into my kernel to
> get my system into a minimally-usable state.  I've been running separate
> /usr setups for 10+ years, and only now, such a setup breaks, hence my beef
> with Fedora's assertion that such a setup is wrong.

You simply misunderstood their point

-- 
Stelian Ionescu a.k.a. fe[nl]ix
Quidquid latine dictum sit, altum videtur.
http://common-lisp.net/project/iolib


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

Re: [gentoo-dev] Re: newsitem: unmasking udev-181

[Maxim Kammerer]

On Wed, Mar 14, 2012 at 02:29, Joshua Kinard <kumba@gentoo.org> wrote:
> make menuconfig, make <bzImage|vmlinux[.32]>[, make modules[_install]], then
> update the bootloader, is how I've done kernels for the longest time.  This
> new approach makes the above command sequence invalid if under a separate /usr.

If your /usr doesn't require kernel modules (e.g., same harddisk and
filesystem as /), you can create an initramfs consisting of Busybox
and 2-line /init (mount /usr and switch_root), and forget about it
after adjusting bootloader configuration. I guess that OpenRC could
even opportunistically try to "fstabinfo --mount /usr 2>/dev/null" in
init.sh to support such usecases.

-- 
Maxim Kammerer
Liberté Linux (discussion / support: http://dee.su/liberte-contribute)

Re: [gentoo-dev] Re: newsitem: unmasking udev-181

[Robin H. Johnson]

On Tue, Mar 13, 2012 at 08:29:31PM -0400, Joshua Kinard wrote:
> make menuconfig, make <bzImage|vmlinux[.32]>[, make modules[_install]], then
> update the bootloader, is how I've done kernels for the longest time.  This
> new approach makes the above command sequence invalid if under a separate /usr.
And why does the requirement to create an initramfs ONCE and include in
your bootloader change that?

The minimal genkernel example I provided explicitly excludes all modules
from the initramfs, so that you almost never have to update it (just for
new features/bugfixes really).

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

Re: [gentoo-dev] Re: newsitem: unmasking udev-181

[Rich Freeman]

On Tue, Mar 13, 2012 at 8:29 PM, Joshua Kinard <kumba@gentoo.org> wrote:
>
> My contention is that I shouldn't need an initramfs loaded into my kernel to
> get my system into a minimally-usable state.  I've been running separate
> /usr setups for 10+ years, and only now, such a setup breaks, hence my beef
> with Fedora's assertion that such a setup is wrong.

I was thinking about this and here is another way to think about it.

Right now you can't boot a linux kernel without a whole bunch of c/asm
code in linux.  That code is necessary to do arch-specific setup,
locate the root device, mount it, and run init.

The new model is that you can't boot a linux kernel without a whole
bunch of c/asm code in linux, and a bunch of scripts and userspace
code in a blob (that can potentially be part of the kernel image).

You could view this as a simple refactoring of code.  Instead of all
the boot logic being in c/asm which is hard to tweak, now some of it
is written in bash and a bunch of userspace tools.  All of this can
just be viewed as part of the kernel - it can even be part of the same
file if you want.

Obviously this isn't a perfect analogy, as a bunch of userspace tools
already existed but now require the extra glue code to work (mounting
/usr).

Once upon a time you didn't even need grub or lilo to boot - you could
just stick the kernel at the start of your boot disk and the first 512
bytes of the kernel conveniently contained a boot sector.  That code
actually still exists but simply tells the user to bugger_off.

So, you really could just view this as another step in the evolution
of the linux boot process.  After seeing some of the more exotic boot
processes used in ARM/etc stuff like this just doesn't throw me for
much of a loop.  And, if you setup dracut/genkernel appropriately it
really is just one extra step to make your system bootable.

Rich

Re: [gentoo-dev] Re: newsitem: unmasking udev-181

[Robin H. Johnson]

On Tue, Mar 13, 2012 at 04:43:06AM -0400, Walter Dnes wrote:
>   Question... does it have to be an initramfs, or can the vast majority
> of simple cases be handled by a simple initscript in /bin or /sbin that
> mounts /usr, and does whatever else is required, before handing off
> control to /sbin/init.
Elsewhere on this list, you will find a script that does roughly what
you propose, written by WilliamH and myself. We're not going to support
it. There are too many corner cases that are hard to recover from with
the script - and MUCH easier with the 'debug' argument to a genkernel
initramfs.

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

[gentoo-dev] Re: newsitem: unmasking udev-181

[Ryan Hill]

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

On Sat, 10 Mar 2012 20:27:06 -0600
William Hubbs <williamh@gentoo.org> wrote:

> An initramfs which does this is created by >=sys-kernel/genkernel-3.4.25 or
> >=sys-kernel/dracut-017-r1. If you do not want to use these tools, be  
> sure any initramfs you create pre-mounts /usr.

We should really have some documentation on how to create a minimal initramfs
that mounts /usr (if we don't already, I haven't looked).  I've never needed
one until now and don't have the foggiest idea how it's done.  I can't be the
only one.

Also, the handbook still endorses having a separate partition for /usr and
includes it in the example setup.  This should be changed now, not when
stabilization time comes.  


-- 
fonts, gcc-porting
toolchain, wxwidgets
@ gentoo.org

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

Re: [gentoo-dev] Re: newsitem: unmasking udev-181

[Robin H. Johnson]

On Sun, Mar 11, 2012 at 12:49:11AM -0600, Ryan Hill wrote:
> On Sat, 10 Mar 2012 20:27:06 -0600
> William Hubbs <williamh@gentoo.org> wrote:
> 
> > An initramfs which does this is created by >=sys-kernel/genkernel-3.4.25 or
> > >=sys-kernel/dracut-017-r1. If you do not want to use these tools, be  
> > sure any initramfs you create pre-mounts /usr.
> 
> We should really have some documentation on how to create a minimal initramfs
> that mounts /usr (if we don't already, I haven't looked).  I've never needed
> one until now and don't have the foggiest idea how it's done.  I can't be the
> only one.
The quickest initramfs, assuming that ALL kernel modules you need to
boot are already compiled into your kernel:
genkernel --install --no-ramdisk-modules initramfs

Plus optionally, If you know you don't need any of these, include this
to make it really get much smaller:
--no-lvm --no-mdadm --no-dmraid --no-multipath --no-iscsi --no-disklabel
--no-firmware --no-zfs --no-gpg --no-luks

--disklabel is the one that most users will probably need, if they use
LABEL= or UUID= arguments in your fstab.

That will give you an initramfs of scripts + busybox.
On my box, it's about 724KiB.

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

[gentoo-dev] Re: newsitem: unmasking udev-181

[Duncan]

Robin H. Johnson posted on Sun, 11 Mar 2012 21:08:47 +0000 as excerpted:

> The quickest initramfs, assuming that ALL kernel modules you need to
> boot are already compiled into your kernel:
> genkernel --install --no-ramdisk-modules initramfs
> 
> Plus optionally, If you know you don't need any of these, include this
> to make it really get much smaller:
> --no-lvm --no-mdadm --no-dmraid --no-multipath --no-iscsi --no-disklabel
> --no-firmware --no-zfs --no-gpg --no-luks
> 
> --disklabel is the one that most users will probably need, if they use
> LABEL= or UUID= arguments in your fstab.
> 
> That will give you an initramfs of scripts + busybox.
> On my box, it's about 724KiB.

Thanks.  You just added concrete to what had to date been a rather hand-
wavy discussion, and it's quite useful. =:^)

Meanwhile, also note that there's PARTLABEL, PARTUUID and ID, that the 
mount manpage promises to honor.  I've not used these myself, but there 
was a thread on the btrfs list discussing GPT format and users of its 
partition-labels (as opposed to filesystem labels), that pointed out that 
mount honors these, since it internally uses the udev symlinks mechanism 
to support (fs) labels, etc, so they get support for gpt-partition-
labels, etc, essentially "for free".

That has implications both here and for openrc, the latter of which I 
appreciate well, as I run openrc-9999 now, having found it FAR easier to 
isolate and report problems with new versions on my apparently rather 
unusual system config (including fstab fs-label but not partlabel or uuid 
usage) directly from git, than from the MUCH too vague released-version 
changelogs.

-- 
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: newsitem: unmasking udev-181

[Robin H. Johnson]

On Sun, Mar 11, 2012 at 11:03:50PM +0000, Duncan wrote:
> Meanwhile, also note that there's PARTLABEL, PARTUUID and ID, that the 
> mount manpage promises to honor.  I've not used these myself, but there 
> was a thread on the btrfs list discussing GPT format and users of its 
> partition-labels (as opposed to filesystem labels), that pointed out that 
> mount honors these, since it internally uses the udev symlinks mechanism 
> to support (fs) labels, etc, so they get support for gpt-partition-
> labels, etc, essentially "for free".
What manpage are you reading?
# man 8 mount |grep PART
# man 2 mount |grep PART
Nada.

When the blkid tool can read PARTUUID/PARTLABEL, then it will just work
with genkernel, as we use blkid for doing that.

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

[gentoo-dev] Re: newsitem: unmasking udev-181

[Duncan]

Robin H. Johnson posted on Sun, 11 Mar 2012 23:14:46 +0000 as excerpted:

> On Sun, Mar 11, 2012 at 11:03:50PM +0000, Duncan wrote:
>> Meanwhile, also note that there's PARTLABEL, PARTUUID and ID, that the
>> mount manpage promises to honor.  I've not used these myself, but there
>> was a thread on the btrfs list discussing GPT format and users of its
>> partition-labels (as opposed to filesystem labels), that pointed out
>> that mount honors these, since it internally uses the udev symlinks
>> mechanism to support (fs) labels, etc, so they get support for
>> gpt-partition- labels, etc, essentially "for free".

> What manpage are you reading?
> # man 8 mount |grep PART # man 2 mount |grep PART Nada.
> 
> When the blkid tool can read PARTUUID/PARTLABEL, then it will just work
> with genkernel, as we use blkid for doing that.

mount (8) under device indication:

>>>>>

Most devices are indicated by a file name (of a block special device), 
like /dev/sda1, but there are other possibilities.  [...] It is possible 
to indicate a block special device using its volume LABEL or UUID (see 
the -L and -U options below).

The recommended setup is to use LABEL=<label> or UUID=<uuid> tags rather  
than /dev/disk/by-{label,uuid} udev symlinks in the /etc/fstab file. The 
tags are more readable, robust and portable.  The mount(8) command 
internally uses udev symlinks, so use the symlinks in /etc/fstab has no 
advantage over LABEL=/UUID=.  For more details see libblkid(3).

<<<<<

As I said, it wasn't apparent to me until someone pointed it out to me on 
the btrfs list, but apparently, mount understands SOMETHING= as 
referencing /dev/disk/by-something, using those symlinks internally, so 
while the manpage doesn't specifically mention PARTLABEL, etc, according 
to that person, it "just works".  Upon seeing that claim, I reread the 
manpage, and sure enough, that meaning can be seen "between the lines" if 
you already know to look for it.

I had intended to try it, since I use gptfdisk and gpt partitions pretty 
much universally now, and referencing the PARTLABEL would have meant that 
I could for instance do a mkfs and redo my backup partitions without 
having to update fstab's labels because I could use the partlabels 
instead.  Unfortunately, when I actually checked to see what symlinks 
udev was putting in /dev/disk/by-partlabel, while indeed the gpt 
partlabels for the physical disks were there, the partlabels for the
gpt-partitioned md/raid devices were NOT, and that's what I actually 
needed, so unfortunately I couldn't try using partlabels after all.  
That's why I've yet to actually verify the claim.

At some point I'll probably verify it with a USB attached external drive, 
as it's my last-resort backup, and/or on my netbook, with only one drive 
so no raid, but I've not gotten that far, yet.


FWIW, the thread started with someone complaining that a btrfs label on a 
multi-device filesystem (since btrfs can do that) was attached to the 
filesystem, NOT the device/partition.  Various people pointed out that 
it's a filesystem label and that btrfs thus had it correct.  Meanwhile, 
on one subthread I pointed out gpt partition labels as an alternative, 
but said I didn't think Linux could actually do much with them yet.  
That's when someone else replied that it could do more than I thought, 
mount and fstab handled partlabel, and he thought the kernel root= 
parameter could take it as well.

Here's his post on gmane:

http://permalink.gmane.org/gmane.comp.file-systems.btrfs/16023

As I said, after reading that, rereading the mount (8) manpage, it /did/ 
seem to hint that it should do so even if it doesn't outright say it, 
since it specifically mentions using udev's symlinks internally.

But as I've not tried it yet I have only his post and my reparsing of 
that manpage based on it, to go on.  Is it incorrect?

-- 
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: newsitem: unmasking udev-181

[Marc Schiffbauer]

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

On Sunday 11 March 2012 21:08:47 Robin H. Johnson wrote:
> On Sun, Mar 11, 2012 at 12:49:11AM -0600, Ryan Hill wrote:
> > On Sat, 10 Mar 2012 20:27:06 -0600
> > 
> > William Hubbs <williamh@gentoo.org> wrote:
> > > An initramfs which does this is created by >=sys-kernel/genkernel-3.4.25
> > > or
> > > 
> > > >=sys-kernel/dracut-017-r1. If you do not want to use these tools, be
> > > 
> > > sure any initramfs you create pre-mounts /usr.
> > 
> > We should really have some documentation on how to create a minimal
> > initramfs that mounts /usr (if we don't already, I haven't looked).  I've
> > never needed one until now and don't have the foggiest idea how it's
> > done.  I can't be the only one.
> 
> The quickest initramfs, assuming that ALL kernel modules you need to
> boot are already compiled into your kernel:
> genkernel --install --no-ramdisk-modules initramfs

But this will not mount /usr. At least it did not for me.
To make it work you have to 

# echo "/usr" >> /etc/initramfs.mounts

and recreate the ramdisk (genkernel ramdisk)

I had to look into the code for that as this seems not to be documented 
anywhere.

-Marc

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

Re: [gentoo-dev] Re: newsitem: unmasking udev-181

[Robin H. Johnson]

On Mon, Mar 12, 2012 at 03:09:39PM +0100, Marc Schiffbauer wrote:
> > The quickest initramfs, assuming that ALL kernel modules you need to
> > boot are already compiled into your kernel:
> > genkernel --install --no-ramdisk-modules initramfs
> But this will not mount /usr. At least it did not for me.
Ouch, nice catch.

I missed merging my commit to flip the default of mounting /usr when
that file is missing. I fixed that in 3.4.25.1 now.

3.4.25-r1 also installed /etc/initramfs.mounts by default, that's where
the documentation is.

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

[gentoo-dev] Re: newsitem: unmasking udev-181

[Ryan Hill]

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

On Sun, 11 Mar 2012 21:08:47 +0000
"Robin H. Johnson" <robbat2@gentoo.org> wrote:

> The quickest initramfs, assuming that ALL kernel modules you need to
> boot are already compiled into your kernel:
> genkernel --install --no-ramdisk-modules initramfs
> 
> Plus optionally, If you know you don't need any of these, include this
> to make it really get much smaller:
> --no-lvm --no-mdadm --no-dmraid --no-multipath --no-iscsi --no-disklabel
> --no-firmware --no-zfs --no-gpg --no-luks
> 
> --disklabel is the one that most users will probably need, if they use
> LABEL= or UUID= arguments in your fstab.
> 
> That will give you an initramfs of scripts + busybox.
> On my box, it's about 724KiB.

Thank you sir.  The last time I played with genkernel I had to kill the
result with a crucifix.  This should do the trick.


-- 
fonts, gcc-porting
toolchain, wxwidgets
@ gentoo.org

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

Re: [gentoo-dev] Re: newsitem: unmasking udev-181

[Sven Vermeulen]

On Sun, Mar 11, 2012 at 12:49:11AM -0600, Ryan Hill wrote:
> We should really have some documentation on how to create a minimal initramfs
> that mounts /usr (if we don't already, I haven't looked).  I've never needed
> one until now and don't have the foggiest idea how it's done.  I can't be the
> only one.

I just started the tracker [1] for the documentation changes and sent info
to gentoo-doc mailinglist about it. The upcoming days, I'll have the needed
updates trickle into the documents.

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

> Also, the handbook still endorses having a separate partition for /usr and
> includes it in the example setup.  This should be changed now, not when
> stabilization time comes.  

It's an example, and we still endorse it. Only will we now tell users to use
an initramfs with it.

Wkr,
	Sven Vermeulen

[gentoo-dev] Re: newsitem: unmasking udev-181

[Ryan Hill]

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

On Mon, 12 Mar 2012 18:34:37 +0000
Sven Vermeulen <swift@gentoo.org> wrote:

> On Sun, Mar 11, 2012 at 12:49:11AM -0600, Ryan Hill wrote:
> > We should really have some documentation on how to create a minimal initramfs
> > that mounts /usr (if we don't already, I haven't looked).  I've never needed
> > one until now and don't have the foggiest idea how it's done.  I can't be the
> > only one.
> 
> I just started the tracker [1] for the documentation changes and sent info
> to gentoo-doc mailinglist about it. The upcoming days, I'll have the needed
> updates trickle into the documents.
> 
> [1] https://bugs.gentoo.org/show_bug.cgi?id=407959

Thanks!


> > Also, the handbook still endorses having a separate partition for /usr and
> > includes it in the example setup.  This should be changed now, not when
> > stabilization time comes.  
> 
> It's an example, and we still endorse it. Only will we now tell users to use
> an initramfs with it.

That sounds good to me.


-- 
fonts, gcc-porting
toolchain, wxwidgets
@ gentoo.org

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

Re: [gentoo-dev] newsitem: unmasking udev-181

[Neil Bothwick]

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

On Sat, 10 Mar 2012 20:27:06 -0600, William Hubbs wrote:

> If all goes well, this will be committed to the tree  on 3/14 UTC.

A major change like this needs more notice than this. The news item
should give some reasonable notice of the change to give people time to
get their initramfs setup working and tested before it is needed in anger.


-- 
Neil Bothwick

Deja Foobar: A feeling of having made the same mistake before.

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

Re: [gentoo-dev] newsitem: unmasking udev-181

[Michał Górny]

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

On Sun, 11 Mar 2012 08:06:35 +0000
Neil Bothwick <neil@digimed.co.uk> wrote:

> On Sat, 10 Mar 2012 20:27:06 -0600, William Hubbs wrote:
> 
> > If all goes well, this will be committed to the tree  on 3/14 UTC.
> 
> A major change like this needs more notice than this. The news item
> should give some reasonable notice of the change to give people time
> to get their initramfs setup working and tested before it is needed
> in anger.

Maybe the ebuild should try to autodetect broken systems and prevent
merge then. Better safe than sorry; I guess we could even go with
having to set something in make.conf when /usr is on separate partition.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] newsitem: unmasking udev-181

[Neil Bothwick]

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

On Sun, 11 Mar 2012 09:41:02 +0100, Michał Górny wrote:

> > A major change like this needs more notice than this. The news item
> > should give some reasonable notice of the change to give people time
> > to get their initramfs setup working and tested before it is needed
> > in anger.  
> 
> Maybe the ebuild should try to autodetect broken systems and prevent
> merge then.

I use an initramfs, it does not mount /usr. The initramfs is embedded in
the kernel file. How would the ebuild evaluate that?


-- 
Neil Bothwick

"We demand rigidly defined areas of doubt and uncertainty!"

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

Re: [gentoo-dev] newsitem: unmasking udev-181

[Michał Górny]

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

On Sun, 11 Mar 2012 09:36:24 +0000
Neil Bothwick <neil@digimed.co.uk> wrote:

> On Sun, 11 Mar 2012 09:41:02 +0100, Michał Górny wrote:
> 
> > > A major change like this needs more notice than this. The news
> > > item should give some reasonable notice of the change to give
> > > people time to get their initramfs setup working and tested
> > > before it is needed in anger.  
> > 
> > Maybe the ebuild should try to autodetect broken systems and prevent
> > merge then.
> 
> I use an initramfs, it does not mount /usr. The initramfs is embedded
> in the kernel file. How would the ebuild evaluate that?

It would just say 'You seem to have separate /usr. Please ensure you
have a working initramfs which mounts it, and set FOOBARBAZ=yes in your
make.conf then'.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] newsitem: unmasking udev-181

[William Hubbs]

[-- Attachment #1.1: Type: text/plain, Size: 112 bytes --]

Here is the latest version of the news item; this gives a few days
notification before the unmasking.

William


[-- Attachment #1.2: 2012-03-14-udev-181-unmasking.en.txt --]
[-- Type: text/plain, Size: 829 bytes --]

Title: udev-181 unmasking
Author: William Hubbs <williamh@gentoo.org>
Content-Type: text/plain
Posted: 2012-03-14
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: <sys-fs/udev-181

udev-181 is being unmasked on 2012-03-17 UTC.

This news item is to inform you that once you upgrade to a version of
udev >=181, if you have /usr on a separate partition, you must boot your
system with an initramfs which pre-mounts /usr.

An initramfs which does this is created by >=sys-kernel/genkernel-3.4.25 or
>=sys-kernel/dracut-017-r1. If you do not want to use these tools, be
sure any initramfs you create pre-mounts /usr.

Also, if you are using OpenRC, you must upgrade to >= openrc-0.9.9.

For more information on why this has been done, see the following URL:
http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken

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

Re: [gentoo-dev] newsitem: unmasking udev-181

[Ulrich Mueller]

>>>>> On Sun, 11 Mar 2012, William Hubbs wrote:

> Here is the latest version of the news item; this gives a few days
> notification before the unmasking.

> [...]

> udev-181 is being unmasked on 2012-03-17 UTC.

You should remove the "UTC" here, or add a time.

Ulrich

[gentoo-dev] Re: newsitem: unmasking udev-181

[Duncan]

William Hubbs posted on Sun, 11 Mar 2012 12:26:57 -0500 as excerpted:

> Here is the latest version of the news item; this gives a few days
> notification before the unmasking.

Thanks.

-- 
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] newsitem: unmasking udev-181

[Robin H. Johnson]

On Sun, Mar 11, 2012 at 12:26:57PM -0500, William Hubbs wrote:
> An initramfs which does this is created by >=sys-kernel/genkernel-3.4.25 or
> >=sys-kernel/dracut-017-r1. If you do not want to use these tools, be
> sure any initramfs you create pre-mounts /usr.
Minor tweak:
>=sys-kernel/genkernel-3.4.25.1
As I missed enabling the new default.

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85