Personal "Rough Notes & Useful Links

User Tools

Site Tools


The Linux Boot Process

This document is some very rough Personal Notes. As such, some information in this may not be correct. Any errors or omissions introduced into this information would be my mistake, so that should not be held against any sources I have used to help put this together.
Terms of Use:
Any “fair use” quoted text remains the property of the original source. As such, the Terms of Use from the original document would apply to that. The rest is covered under the CC Attribution-Share Alike 3.0 Unported terms selected for this wiki.

Power ON

  • Pushing the Power Button (or something else like Wake-on-Lan) sequences the electronics to the “fully on” state.


Basic Input Output System (First written for the original IBM PC.)

  • POST – Power On Self-Test
    • Detects devices and performs some very basic tests that the hardware is functional
    • initializes the hardware, including the screen and keyboard
  • The BIOS provides primitive access to hardware such as Drive Media & Networking (so the system can boot)

MBR/EFI Bootstrap

From the saying/concept “to pull yourself up by your bootstraps.” … 1st access of the Drives or Boot Media

  • Once the POST is completed, the system “Bootstraps” to pass control from the BIOS to the Boot Loader.
    • for MBR (Master Boot Record), the 1st sector on a hard drive contains the code needed to load the Boot Loader
    • for more recent Extensible Firmware Interface (EFI) or Unified Extensible Firmware Interface (UEFI) systems, the code to load the Boot Loader is found in the EFI partition
  • the BIOS/MBR method:
    • On IBM PC-compatible computers, the BIOS bootstrapping firmware loads and executes the master boot record.
    • The MBR is the initial boot loader (Bootstrap Loader) which resides in the first 512 byte sector of the storage device.
      • This must be the 1st sector of the device, and not the 1st sector of a partion, etc..
    • Bootstraping the system in this manner examines the partition table and finds a bootable partition, then searches for the installed Boot Loader package – to select & load the desired OS.
  • the EFI/UEFI method:
    • the UEFI firmware reads its Boot Manager data to determine which UEFI application is to launch from where.
      • usually this means identifying on which disk and partition the EFI partition can be found.
    • The firmware then launches the UEFI application (the Boot Loader) as defined in the boot entry for this boot firmware.
      • GRUB 2 and elilo serve as conventional, full-fledged standalone UEFI boot managers for Linux. Once loaded by UEFI firmware, both can load kernel images from all devices, partitions and file systems they support.
“UEFI (Unified Extensible Firmware Interface) was developed among others to support hard-disks larger than 2TB in sizes, an impossible achievement by using the traditional BIOS-MBR method, which limits the filesystem sizes to maximum 2TB and and the maximum number of primary partitions to three (with the fourth being extended). UEFI works hand-in-hand with GPT partition table on hard drives no matter of what size the hard drive has, as long as the system is booted from UEFI mode, making impossible to use MBR once the system was started in UEFI mode. You can use GPT on UEFI systems only if the system in started in BIOS Legacy Mode by tampering with UEFI settings. Also, all partitions from a GPT table layout are now primary by default and can support up to 9.4 zettabytes in sizes with a number of 128 partitions.”

Boot Loader

“A number of boot loaders exist for Linux; the most common ones are GRUB (for GRand Unified Boot loader) and ISOLINUX (for booting from removable media). Most Linux boot loaders can present a user interface for choosing alternative options for booting Linux, and even other operating systems that might be installed.”

  • when booting Linux the Boot Loader needs to load both the kernel image and the initial RAM disk
    • In the Linux directory structure, the Boot Loader resides under /boot
    • a (text based) splash screen may be displayed, to choose which Operating System (OS) or even which kernel version to boot
    • for Linux, the Boot Loader loads the (selected) kernel, and also loads the initial RAM-based file system (initramfs) into memory – so that can be used directly by the kernel

Kernel for Linux OS

“The boot loader loads the selected kernel image (in the case of Linux) and passes control to it. Kernels are almost always compressed, so its first job is to uncompress itself. After this, it will check and analyze the system hardware and initialize any hardware device drivers built into the kernel.”

Intial initramfs RAM Disk

  • initramfs is the temporary ramdisk image, which contains all the files required for the kernel to initialize the hardware and mount the root filesystem.
    • udev (for User Device) is responsible for figuring out which devices are present, locating the needed drivers, and loading them.
    • All partitions and/or volumes for the root filesystem are found, checked for errors (as appropriate), then mounted.
    • Then the mount program notifies the OS that each part of the filesystem is ready for use, and associated with the proper mount point in the filesystem hierarchy.
  • Once the root filesystem has been mounted, initramfs is cleared from RAM, and the init program on the root filesystem (/sbin/init) is executed

/sbin/init and Services

  • After the kernel has initialized all the hardware, and mounted the root filesystem, then the kernel runs /sbin/init
  • init is the parent or 1st process (PID 1) which starts the other processes needed to get the OS running.
    • Only kernel processes (the inner workings of the OS) are handled directly by the kernel – instead of init
  • init is also the “manager of last resort” – which keeps the system running in a clean & properly functioning manner.
    • it provides the ability to terminate or restart any non-kernel processes (programs and services) that stop responding
  • When a user logs in or out, init will also start or restart user login services.

Command Shell via getty

“Near the end of the boot process, init starts a number of text-mode login prompts (done by a program called getty). These enable you to type your username, followed by your password, and to eventually get a command shell.”

X Windows System

  • If used, loading the X Window System is the final step in the boot process
  • The Display Manager service keeps track of the displays being provided, and loads the X server
  • The Display Manager handles graphical logins, then starts the appropriate desktop environment after a user login.
kb/linux/bootprocess.txt · Last modified: 2016/01/13 20:35 (external edit)