On Mon, May 04, 2015 at 10:48:06AM -0400, Steve Litt wrote:
> Hi all,
>
> I just documented the boot process, from Grub through init.
>
> See http://troubleshooters.com/linux/diy/howboot.htm
Comments/contributions for a few sections.

The Bootloader:
I can elaborate a little on grub stuff, though I'm most familiar with
grub4dos-chenall (a fork of a fork of "grub legacy") rather than grub2.

"set root=(hd2,msdos1)" or "root (hd0,8)" specify the filesystem that
all file paths are relative to.
So these stanzas are theoretically both ways of loading /boot/bzImage
and /boot/initrd.img from /dev/sda9 (grub legacy):

root (hd0,8)
kernel /boot/bzImage root=/dev/sda9
initrd /boot/initrd.img

kernel (hd0,8)/boot/bzImage root=/dev/sda9
initrd /boot/initrd.img


With "grub legacy" and derivatives, (hd0,0) is the first partition (",0")
of the first harddrive ("hd0").
Partitions are numbered in the same order as Linux orders them
(under most circumstances).

Grub2 has switched from a 0-based index to counting partitions, but
still counts hard drives from 0:
(hd0,msdos1) is the first partition on the first hard drive;
the "msdos" presumably indicates the partitioning scheme.

The Kernel's Role in Booting:
If you have a kernel with enough stuff builtin (drivers for your disk
controller like ata_piix, block device drivers like sd aka sd_mod,
*and* a filesystem driver for / like ext4 or xfs), you can boot without
an initramfs, by disabling initramfs support when you compile the kernel
or by booting with "noinitrd".
In this case, the kernel mounts the filesystem you specify with "root=...",
mounts devtmpfs on /dev (if you configured it to do so at compile time),
and executes /sbin/init* or the executeable specified with "init=..."
(must be an absolute path; symlinks work, as long as it's on the
same filesystem and resolves to an executable binary of ELF/A.OUT format,
or a script with a shebang line that resolves to such a binary).

*To be pedantic, the kernel actually executes the first init program
from a hardcoded list to be found; typically this is /sbin/init.

You can specify mount options for the root filesystem right after
"root=... " in the kernel commandline.

As far as programs the kernel launches directly other than init go, I'm
aware of two:
First, on hotplug events: if kernel.hotplug is set to the path of an
executable, the kernel will run that executable with an environment
describing the hotplug event.
If the USB subsystem was involved, the first argument will be "usb".
Second, on attempts to mount something with a specified filesystem type
or to access an OSS device when ALSA's OSS-compat layer has been
configured to "preclaim" them, the kernel will run
modprobe <MODALIAS>
where MODALIAS is some keyword generated from the device/filesystem/
underlying hardware (modinfo and /lib/modules/`uname -r`/modules.alias
are useful for finding out more about these).

The kernel also sends messages via the "netlink layer" to any service
that wants to listen.

The Role of the initramfs:
s/cnew/newc/
This is the SVR4 "new" ASCII-based format, commonly referred to as
"newc". Spelling that out might be helpful.

One important yet obscure detail for preparing an initramfs is that
cpio does *not* create the ancestors of a directory automatically, and
the kernel requires all ancestors to be created before extraction;
if you add
./lib
./lib/firmware
./lib/firmware/radeon/R100_cp.bin
to the input list of files, the initramfs will have /lib/firmware but
/lib/firmware/radeon will be missing so R100_cp.bin will not be
extracted.

The On-Disk Init System:

Another init system is toybox "oneit", which properly sets up a tty,
runs a process, and shuts down the system when said process exits.

busybox init is similar to sysvinit with the following exceptions:
-runlevels are not supported
-the "tag" in the first field is used as the name of a tty to run
a program on, so to set up a getty you usually do this:
tty1::respawn:/sbin/getty 38400 tty1

I would have described openrc differently:
OpenRC competes with the various rc packages as a way to run init
scripts (so sysv-rc, file-rc, and openrc are alternatives); it can
even be used with systemd or upstart if you want to do that.
Its main benefit is that you can write a basic script that acts
like a standard initscript in just a few lines.

Minimal Process Management:

I'd suggest a couple changes to the wording of the list:
 1. *Mount* /proc and /sys
 2. Populate /dev; initialize drivers and create devices in response
    to hotplug events (typically via udev, eudev, vdev, mdev)

On the whole, it's a fairly good overview.

HTH,
Isaac Dunham