How Linux Boots

Hardware POST and initial hardware boot loader

The hardware is powered up, a POST (Power-On Self-Test) occurs, and the initial boot loader takes over:

If on a PC, this is the rather limited BIOS which must determine the system MBR (Master Boot Record) and turn control over to it. The system MBR will be the MBR of the first populated media, examined in whatever order the BIOS examines them. The MBR of a piece of media is its first 512-byte sector.
If on an Alpha or a SPARC, this is instead the far more capable SRM (Alpha) or Boot ROM (SPARC), which is a mini-OS of its own.

System MBR and Linux boot loader

The system MBR should contain the Linux boot loader:

On a PC, this is GRUB, or perhaps LILO.
On an Alpha, this is aboot.

That boot loader is loaded into RAM and started, and it takes control of the system. Both GRUB and aboot are able to understand the Linux file systems; LILO must do everything in terms of physical addresses.

Linux boot loader menu

The boot loader may present the user with a choice of bootable operating systems, and it may time out and boot a default one.

If Xen is involved...

On a PC, something called Xen may be loaded by the boot loader.

Xen is a hypervisor, it is a relatively lightweight piece of software that arbitrates access to the hardware for operating systems running on that platform.

If Xen is booted via GRUB on a PC (and that's the only situation in which you're likely to find it), it will be passed the Linux kernel and other parameters for booting what's called the Domain0 or Dom0 operating system on that platform.

Loading the kernel

The boot loader uncompresses and loads the kernel image into RAM:

On a PC the bootable kernel image is one big file with three components:
— 512-byte boot block
— secondary boot loader
— gzip'ed kernel
On an Alpha the bootable kernel image is simply a gzip'ed kernel.

The kernel is started and it takes over.

Loading the initial RAM disk image

The kernel almost certainly will have been passed an initial RAM disk image (usually called "initrd") by the boot loader. This is needed to provide needed device-special files in /dev, as devices are now dymanically created by the udev daemon which is only started during the middle of the boot sequence. /dev will be an empty mount point, missing the needed stdin, stdout, stderr, null, random, and other devices.

The initrd may also contain some needed device drivers (e.g., for SCSI controller or SATA chipsets)

The initrd is uncompressed into RAM and mounted temporarily as the root of the filesystem (/). Then the file /linuxrc is run, possibly loading those device drivers.

Device discovery

The monolithic kernel (possibly plus some loadable modules loaded from the initrd) discovers the hardware.

Hardware discovery is a fairly black art. The individual components of the kernel (meaning the kernel image in RAM, which is monolithic kernel plus all currently loaded modules) try to detect their specific hardware (if any).

This might be done by trying to read from a specific hardware address, and interpreting any data read. It might include actively probing — writing some patterns into specific hardware addresses, and seeing what happens.

Of course, some kernel components (a.k.a. "drivers") are software-only, like the ability to run TCP/IP, or interpret specific file system formats.

When a kernel component successfully loads (for a module) and/or finds its hardware, it prints something that you will hope might be of use. This output is captured in the "kernel ring buffer" and simultaneously printed onto the console.

The kernel ring buffer contents can be viewed after the system is up and running with the command dmesg.

Mounting the real root filesystem

The kernel was passed information by the boot loader about which partition to mount as "/". If you are very curious about details, this is passed as "major, minor" device numbers. For traces of this, try this command after your system is up and running: cat /proc/cmdline

The initrd is unmounted and the real root filesystem is mounted in read-only mode as "/". More hardware may be discovered as this happens.

The kernel starts `/sbin/init`

The init process reads its configuration files for several pieces of information. With the classic init program, /etc/inittab contains this information.

What script is run to perform the sysinit process? The answer is probably /etc/rc.d/rc.sysinit
What run state is defined as initdefault
What scripts must be run to reach the default run state? Those will be all lines containing the default run state label as the second colon-delimited field. They will be run in the order that they appear.

Your /etc/inittab file probably resembles:

# The default run level
id:3:initdefault
# System initialization
si::sysinit:/etc/rc.d/rc.sysinit
# Do the SYSV stuff
[....]
l3:3:/etc/rc.d/rc 3
[....]
# Run gettys
1:12345:respawn:/sbin/mingetty tty1
2:2345:respawn:/sbin/mingetty tty2
3:2345:respawn:/sbin/mingetty tty3
[....]

However, things work a little differently if your Linux system uses the "Upstart" version of init. This will be the case if your Linux is based on a Debian or Ubuntu distribution, or RHEL/CentOS 6 and later. Instead of a single file /etc/inittab, the init program is configured by a collection of files in the directory /etc/event.d/. Basically, each Upstart file in /etc/event.d/ plays the role of one line from the traditional file /etc/inittab.

The kernel starts /sbin/init because that is what it is programmed to do — at least by default. This is why you can break into a Linux system by passing the following argument from the boot loader:
init=/bin/sh
Since init doesn't run, /etc/rc.d/rc.sysinit doesn't run, and the system will be in a somewhat odd state. You would need to do the following to do what you want and not cause far worse problems, but at least you are in:

Mount /proc:
# mount /proc
Ignore any claim that it was already mounted, as that is based on stale information left in /etc/mtab from before the previous shutdown.
Remount the root file system in read-write mode:
# mount -o remount,rw /
Manually mount any other file systems you need, like /usr and maybe /var and others.
Do your rescue work.
Unmount the file systems in reverse order.
Reboot with something like <Ctrl><Alt><Del>

`init` takes over

Given the above, your init would:

Run /etc/rc.d/rc.sysinit which will:
- Possibly run fsck on "/" if it wasn't cleanly unmounted the last time, and so it might be corrupted.
- Remount "/" in read-write mode.
- Run fsck on the other file systems as needed, then mount them as per /etc/fstab
- Save the kernel ring buffer as soon as possible with: dmesg > /var/log/dmesg
- Possibly forcibly load kernel modules with
- modprobe to support oddities like filesystems on USB devices, or exotic (meaning non-ext2/ext3) filesystems.
Run /etc/rc.d/rc 3. The script /etc/rc.d/rc does this:
- Look in the directory named /etc/rc.d/rcN.d, where "N" is replaced with its argument ("3" in this case).
- Run every script there named "K??something", in the order they are listed, with an argument of "stop".
- Run every script there named "S??something", in the order they are listed, with an argument of "start".
- You will notice that the things in /etc/rc.d/rc?.d/* are symbolic links pointing to the real boot scripts in /etc/rc.d/init.d/* (In Solaris, these are hard links).
The script rc does the main work, at least the work specific to different run states. But our init will continue to run some instances of /sbin/mgetty to start the login processes on the virtual consoles.

At this point, the system is up and running!

The Bootchart project has a tool that gathers information and creates charts of process and timing information. It seems like it's mainly being used by people trying to speed the boot process, but it might help you answer your questions or otherwise investigate the booting process: http://www.bootchart.org/"