On Fri, 26 Jul 2024 at 10:49, Bryce <[email protected]> wrote:
> I see. So the third stage bootloader loads the kernel into memory, as well as
> the boot_archive, informs the kernel where the archive is (in memory), then
> the kernel uses the drivers and such in the programs to load the root and
> execute /sbin/init?
>
> I checked the filelist document in
> https://github.com/illumos/illumos-gate/blob/master/usr/src/cmd/boot/filelist/i386/filelist.ramdisk
> and didn't see an /init, do does that mean that whatever the kernel does at
> that time is completely controlled by the drivers (as I would expect)?
There are two distinct styles of boot archive:
(a) Archive style; e.g., CPIO. Essentially a cache of files from
the real root file system, kept in sync by bootadm(8). This
cache only needs to contain:
- kernel modules required to locate and mount the root
file system from whichever devices house it
- any data files (e.g., path_to_inst(5) and system(5) and
so on) that are needed before the root file system is
mounted
(b) Ramdisk style; i.e., a ufs(4FS) image. This is an entire
root file system, made available to the kernel by the boot
loader. There are a minimal set of routines in the base
kernel that can pick files out of a UFS image like they can
for a CPIO archive, before the file system is actually
mounted.
In addition to the kernel ("unix") and the boot archive (described
above) the boot loader provides either or both of a command line
string, and/or an environment (a list of string key-value pairs).
In this environment, we provide some additional properties that tell
the kernel which file system driver to use and how to locate the
file system (e.g., a /devices path to the disk, or some information
about the network for NFS root, etc).
In the archive case, the loader must provide enough detail that when
the kernel calls vfs_mountroot(), we can locate and mount the root
file system. Modules and data needed before that point come from
the archive, and after that point, come from the newly mounted file
system. The init process is started _after_ that, so we don't need
to include it in the archive.
In the ramdisk case, the kernel first treats the UFS image as an
archive up until vfs_mountroot(), when it "mounts" the UFS image
in-place in RAM and things proceed normally as if it were accessing
a physical disk -- with the obvious caveat that changes will be
destroyed on reboot. This is how install images work today; they
boot from an ISO or a USB image into this kind of ramdisk and then
load other software by finding and mounting the boot device later
from usermode. It's also how SmartOS works.
At Oxide, we've got a prototype for a new kind of booting, using a
combination of a CPIO boot archive that contains drivers for disks
and the ZFS modules, and then having the kernel load a ramdisk image
from a slice on an NVMe device into RAM. To do this, I had to add
new hooks into the main() routine of the kernel just prior to
vfs_mountroot() so that we could inject some custom behaviour from a
separate kernel module we build. It's designed to be customisable
without changing the base kernel source, but also not quite ready to
upstream to mainline illumos -- though I'm keen to get it up there
eventually!
If you want to get started with a minimal boot-to-ramdisk system, I
would probably look at SmartOS, as that's what it is! It uses the
UFS ramdisk approach today, and that ramdisk is able to locate other
resources on physical disks as needed, etc. We also have some tools
the allow building images automatically from templates:
https://github.com/illumos/image-builder
There is no documentation there right now, but I have some examples
of how to use it up here:
https://github.com/jclulow/omnios-image-builder
I have, in my home directory, other templates I'm yet to add there
which can construct a custom OmniOS-based ramdisk image that you can
add software and custom boot-time behaviour to. If you want me to
throw that up in there, let me know.
Happy to answer any questions, as I know this is a lot to take in!
It would help to have more concrete specifics about how you're
looking to operate the system you're building, what software you're
hoping to include, how autonomous it should be, how you're hoping to
update it, etc.
Cheers.
--
Joshua M. Clulow
http://blog.sysmgr.org
------------------------------------------
illumos: illumos-discuss
Permalink:
https://illumos.topicbox.com/groups/discuss/Tc9bfa679c7294ee7-Ma01a51d0c7fe2e4bc5c02ceb
Delivery options: https://illumos.topicbox.com/groups/discuss/subscription
