Re: support for merged /usr in Debian
On 07/01/16 08:36, Paul Wise wrote:
> $something should
> automatically manage the contents of /bin /sbin /lib (/boot?) based on
> the tools needed to mount /usr (perhaps plus some more recovery
> tools)
I really don't think that's a good approach, particularly as a default.
We already have tools to make a minimal bootable environment that can
mount /usr and do some limited recovery, and the result is called an
initramfs. If you want a lighter-weight initramfs for environments where
those generated by initramfs-tools or dracut are overkill, Christian
Seiler has a nice proof-of-concept elsewhere in the thread, which
apparently compiles to less than 16K.
If you're using binaries in /usr and copying a dependency-closure subset
of them to the root filesystem, what makes that any better than using
binaries in /usr and copying a dependency-closure subset of them into
the initramfs? You basically end up doing a 2-phase boot (mount /usr,
then start the parallelizable part of the boot process) either way.
One key difference that I can see is that the initramfs has one job - it
mounts critical filesystems and is dropped from RAM - so any special
configuration that it needs doesn't interfere with normal operation. The
root filesystem (without /usr, if your /usr is separate) has two jobs:
it has to mount /usr, and it has to be the real root filesystem
afterwards. For instance, the tools in /bin and /sbin are reading the
same configuration in /etc, and system-integration glue in /etc or /lib,
that you use for the fully functional system, including arbitrary
/{etc,lib}/udev hooks (which might run helpers with long dependency
chains), arbitrary PAM modules, arbitrary NSS modules... all of which
you probably want, *later*, or you wouldn't have installed them, but not
before /usr comes up.
To make this plan work, you'd need to somehow make sure that all the
tools used between "start init" and "mount /usr" were running in a mode
where they avoided doing anything that couldn't be done before mounting
/usr. That sounds suspiciously like reinventing the initramfs, but with
the additional constraint that it has to work with the same /etc as the
fully-featured system.
If I absolutely had to implement your plan, I'd do it by writing a
minimal pid-1 which does the minimum necessary to mount /usr, then execs
the real init (sysvinit, systemd, whatever)... which, again, is sounding
suspiciously similar to an initramfs, in which the kernel executes a
script or binary (typically /init or /linuxrc) as pid 1, and that
process is expected to finish by exec'ing the real init.
If you're on an embedded platform where the bootloader doesn't
understand initramfs, it's entirely possible to embed a small initramfs
in the kernel image itself (AIUI, initramfs-capable kernels always have
one, but it's usually empty) - CONFIG_INITRAMFS_SOURCE is the option to
look for. Christian's 16K initramfs sounds ideal for that.
S
Reply to: