On Tue, 5 Apr 2011, Christopher Howard wrote:
> Forgive me if I ramble a bit... but I'm still working through the
> thoughts in my own mind:
>
> One of the cool things I have been exploring about Linux is how the
> /boot software/ can be distinct from the /system software/, if that
> makes sense. What I mean is, you can have an entire root file system
> with init scripts, coreutils, applications, user data, et cetera, et
> cetera. But your boot code and core OS code, that is, your boot loader,
> kernel, and initramfs can be on a totally different partition, or heck,
> even a different device. And you can use what ever boot loader you want
> (grub, lilo, syslinux, isolinux...) and (pretty much) what ever kernel
> version you want, and your own custom-built initramfs, and yet the
> system will run pretty much the same regardless once you've passed the
> boot stage.
I'm not so sure I'd define the line between boot & system sofware so
rigidly. The reality is that much of userland *is* boot code, along with
sysvinit, etc. Your initramfs more than likely includes an alternate
userland based on busybox, which the init process replaced by an ash script.
Everything needed to mount the root fs (regardless of where it is, local,
network, etc.), chroot, and launch the full init process. Not only is your
system really not useful until it can provide either a console or network
services, but that whole userland microcosm in your initramfs is entirely
optional. You don't *need* initramfs/initrd to boot. It just allows you to
have more complicated rootfs setups, like rootfs in LVM, etc.
In a nutshell, the UNIX design philosophy dictates that everything you need
to get a system to a usable state should be contained in / (/sbin, /bin,
/lib, /etc, etc.). *That* is your core OS. Everything else is optional,
and that includes /usr.
> So the nice thing about this is you can administratively separate the
> two: e.g., have generic boot software provided over PXEboot, but can
> your specialized root system provided by NFS.
Indeed. You could even just run rootfs completely out of initramfs, if you
wanted, and just mount /usr out of NFS.
> The only thing that doesn't quite fit into this nice, clean conceptual
> schema: kernel modules. Kernel modules don't get installed on the boot
> partition, they get installed in /lib/modules/<version-number>. So
> basically, they are system software, not boot software, and so in the
> end you have to keep this aspect of your system software synchronized
> with you boot (and core OS) software. That is, you always need to make
> sure that, if you build a new generic kernel, that each of your root
> systems gets the appropriate new modules and gets them installed in the
> correct place in the correctly named folder.
My initramfs always copies /lib/module/`uname -r` to the cpio archive. For
that matter, I also include /lib/firmware, something necessary if you're
going to boot off of a SAN. I believe most distro's scripts selectively
include necessary modules in order to access local DASD, etc. End sum,
kernel code, in modules or otherwise, cannot be considered "system"
software. Anything that runs within the kernel's address space, dynamically
loaded or not, is a proper part of the kernel.
All of that is to say that the problem you're presenting is really not a big
deal, and many of us have been dealing with that scenario for years.
> You can ignore the problem, of course, by compiling your kernel
> statically, but then in order to make it generic enough (with all
> possibly needed drivers) you end up with a kernel the size of Moby-Dick.
The only time my systems run a generic kernel is during an install. After
that I always run hardware & workload-specific kernels. Running a generic
kernel is yet one more attack vector you don't want to defend against.
Oh, and custom kernels avoid the problem you just mentioned. But, even if
you're hooked on generic (and unoptimized) kernels, the initramfs you can
append to your kernel image only needs the requisite modules necessary to
boot the rootfs. You don't have to include them all.
> I know there is a lot of overlap and ambiguity in what I just wrote. But
> I thought it might be worth the ridicule to see if anyone else has
> thought along similar lines.
It's all balancing act, and something every systems engineer deals with.
Your conjectures are well worth pondering.
--Arthur Corliss
Live Free or Die
---------
To unsubscribe, send email to <aklug-request@aklug.org>
with 'unsubscribe' in the message body.
Received on Wed Apr 6 17:38:11 2011
This archive was generated by hypermail 2.1.8 : Wed Apr 06 2011 - 17:38:11 AKDT