[aklug] Re: Boot software / system software / Kernel Modules

From: Shane R. Spencer <shane@bogomip.com>
Date: Wed Apr 06 2011 - 09:04:21 AKDT

'Y' is a key operative to how the kernel understands what modules are compiled in
(including the ability to use an initrd). Your distribution for the most part has a
preference to what modules are included in the kernel image or what is simply a module.

Initramfs does the rest of the work if there are any tasks that need completed before
mounting a volume deemed as 'root'.

Boot loader understands how to find the kernel using whatever method it prefers, hard
drive offsets, filesystem awareness, etc... The boot loader software is not a kernel for
the most part but is simply a BIOS/BUS aware program that has enough magic to get loaded
up according to the specifications of the hardware attempting to find an operating system.
  Computing hardware typically wants an operating system to run on it therefore there are
methods to have that happen.

The bootloader then deals with the kernel image and if offered an initrd loads that into
memory and makes it available to the kernel before passing control off to the kernel in a
suicidal fashion.

The initrd is of a specific format and for the most part subscribes to the kernels
standards of file layout once extracted or mounted. The initrd archive is extracted to a
newly created ramdisk if it is an archive or simply loopback mounted (unverified) if it is
a filesystem type that is available to the kernel as a built in module. If it was an
archive the memory it was farting around in is reallocated after extraction.

The kernel has been in charge for quite a while in CPU time at this point and is fully
capable to do any kind of work. In most cases the initrds job as a series of programs
that execute in userspace and are dang happy to do so start loading up modules based on
the initrds init method which varies considerably depending on which initramfs generator
your installer/distribution uses. You can see for yourself the flow of the init process
by peeking in the initrd. In most cases there is a list of modules that require loading
that are contained in the initramfs (copied from /var/lib/modules/whatever during generation).

Once it has what it needs and has a competent grasp on what filesystem '/' should be on
the initramfs commits suicide (common theme) after mounting the root filesystem
appropriately and executes the init script on the root filesystem which it knows all about
because the generator told it specifically where it is thanks to LWN as well as the
ability of a distribution package maintainer to customize a package for a desired
execution later on.

Now you are in your 'distribution' proper.. It does it's things.. off we go.

The initramfs is not typically required for booting however it makes many many things more
accessible if used. For instance Debian has a hammed up version of initramfs-tools and
multiple packages that insert script hooks and binary inclusions for the next initramfs
generation to consider. This includes the ability to use iscsi roots, ask for a crypto
password, offer a minor or even major set of tools for diagnostics before mounting any
volumes, etc....

- Shane

On 04/05/2011 11:02 PM, 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>

---------
To unsubscribe, send email to <aklug-request@aklug.org>
with 'unsubscribe' in the message body.
Received on Wed Apr 6 09:04:10 2011

This archive was generated by hypermail 2.1.8 : Wed Apr 06 2011 - 09:04:11 AKDT