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