03. Pre-system boot

0. Power on. What now? Run a program? What program? All we have is CPU and pristine clean RAM
   • — Use ROM dude. Copy it to the pre-defined address of RAM and start there

1. ROM:

   • What we have in ROM?

     • BIOS (if any) — to make a simple I/O operations (video, keyboard, primitive disk)

     • or more complex firmware like EFI

   • ⇒ At least we can
     • select the device to boot from

     • and boot something from it. Call it primary loader.

2. Primary loader:

   • Very small. Like, less than one sector on disk
   • Very dull. What you can program into 446 bytes?
   • Specific by the device it resides:
     • Knows how to read blocks from device

     • Knows what to read ad run from this device (e. g. by hardcoding a list of blocks to read just into primary loader code)

   • Can load almost and run any amount of code from the fixed place of the device and run it. Call it secondary loader

3. Secondary loader:

   • Very smart (must be):
     • Must recognize a umber filesystems (e. g. ext2, ext3, ext4, jfs, xfs, btrfs, zfs, HPFS, ...) to find loadable file on

     • Must recognize a number of formats (e. g. linux, BSD, windows, OS/X etc) to load any OS kernel

     • Must have an ability to load and link modules (drivers) with the kernel

       • Why? Because no modern kernel is so monolith to include all the dirivers in it, and disk driver is sufficient to the kernel, that must mount that versy disk as root

   • IRL: No such thing as universal boot loader

     • Knows about disk partition and filesystems

     • Can select and boot specific OS kernel or something alike from the given FS

     • Can boot other secondary loader to boot another OS (e. g. windows)

4. OS kernel:

   • Checks and tunes hardware
   • mounts root filesystem
   • initial OS startup

So, theoretically:

0. BootROM
   • Select a device to boot from
   • Load a Boot block from it
1. Boot block (primary loader)

   • (almost never) select a secondary loader

   • load and boot a secondary loader from the current device
2. Boot program (secondary loader)
   • Select and boot variant (one of kernels available and parameters) and boot it
   • or select and chainload another secondary loader (capable for boot other type kernels)
3. Kernel
   • check and set-up devices
   • find filesystem to mount as root, mount it and initiate OS startup

The locked key problem:

1. Kernel is to mount / directory from the particular filesystem of the particular partition on the particular hard disk drive connected to the particular disk controller

2. There are so many filesystem types, disks and disk controllers, that no kernel has them compiled in. Those are loadable modules, that collected as files on the particular filesystem (often in the /lib/modules directory). The kernel shall load some of them first

3. See (1.)

Linux: lazy and simple

• Suppose we already loaded the kernel, and it has an access to the small filesystem contains minimal set of modules and executables, enough to mount «/».

• Then no problem to re-mount from this tiny storage to actual root and run a full OS
• The solution:

  • Create an archive this just-need-to-mount-root set of modules and binaries. Call it Initial virtual disk (initrd, initramfs, name it).

  • Teach secondary loader to load two files instead of just kernel (kernel and initrd). No other capabilities is needed (no individual module loading, no kernel linking, etc.)

  • Teach kernel to mount initrd from memory as filesystem and boot from it.

  • We get a tiny all-in-memory linux-based OS that can load all the modules, unomunt and purge memory of initrd, mount actual root and boot from it
  • PROFIT

Example (VirualBox VM)

TODO