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

[Rich Freeman]

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

Well, the answer is a bit more nuanced.

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

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

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

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

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

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

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

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

Rich