Re: [gentoo-dev] Re: udev <-> mdev

[Rich Freeman]

On Sun, Jul 15, 2012 at 2:25 PM, Duncan <1i5t5.duncan@×××.net> wrote:
> So I have the general idea,
> but doing it from an initr* with limited tools available will be
> interesting.
>

Dracut modules can specify any tools they need, and they will be
loaded into the initramfs.  Obviously you'll want to use some
discretion here.

> As for the tmpfs rootfs itself, I have the vague idea that I'd
> "simply" (note the scare-quotes) use what's normally the initial root
> that's essentially thrown away, only I'd not throw it away, I'd just
> mount everything on top, keep using it, and /somehow/ ensure that
> anything running from it directly terminates one way or another, so that
> I don't have old processes stuck around using the mounted-over points.

I suspect you could do that, but you'd probably have to change the
cleanup code, and you need to keep in mind that the initramfs runs on
ramfs and not tmpfs.  While similar there are a few important
differences.  Ramfs does not support size limits, so you can
extinguish all of your ram easily enough.  Ramfs also does not swap,
which means that any actual content in that filesystem will waste ram,
whether it is used or not.  Anything that writes to it could wipe out
all your memory even if you have swap available.  The design of ramfs
is designed for simplicity rather than robustness (you can support an
initramfs on a system that otherwise lacks the drivers for tmpfs.

> Which is why I keep /usr (and /lib64 and /usr/lib64) on rootfs currently,
> tho the traditional /usr/src/, /usr/local, and /usr/portage are either
> pointed elsewhere with the appropriate vars or mountpoints/symlinks to
> elsewhere.  Of course that'd have to change a bit for a tmpfs rootfs,
> since /lib64, /usr and /etc would obviously be mounted from elsewhere,
> but they could still be either symlinked or bind-mounted to the
> appropriate location on the single (read-only) system-filesystem.

Giving it a little thought, the simplest tmpfs-based root would be one
that defines a tarball as a the root.  The system would create a
tmpfs, extract the tarball to it, and then use the existing fstab-sys
module to mount stuff on top of that.  This gives you the option of
actually putting some content in the tarball, or just storing an empty
directory structure in it.  A tarball would let you set
permissions/etc and be a bit more generic than writing a custom
script.  If you wrote a module to do this I wouldn't be suprised if
upstream let you merge it.  You'd just need to define some kind of
sane syntax for it (root=TAR=path...to...tarball - though how a path
works with nothing mounted you'd have to define).  Maybe you define
the tarball at initramfs creation (as is done with fstab.sys and
mdadm.conf).

>
> FWIW I remember being truly fascinated with the power of symlinks when I
> first switched from MS.  Now I consider them normal, but the power and
> flexibility of bind-mounts still amazes me, especially since, as with
> symlinks, it's possible to bind-mount individual files, but unlike
> symlinks (more like hard-links but cross-filesystem), it's possible to
> have some of the bind-mounts read-write (or dev, exec, etc) while others
> are read-only (or nodev, noexec...).

Yup, my /usr and /var are bind-mounts - I was following the
pre-initramfs raid guide and had my root on a raid1, and wanted to
keep it minimal.  However, rather than having 47 individual
filesystems in lvm I only defined a few and bind-mounted half the tree
off of one of them.  Fstab.sys seems to handle that just fine
(mounting the main mountpoint first, and the bind mounts afterwards).

Rich