Linux startup process

From Wikipedia, the free encyclopedia - View original article

Jump to: navigation, search

The Linux startup process is the process of Linux-operating system initialization. It is in many ways similar to the BSD and other Unix style boot processes, from which it derives.


Early stages of the Linux startup process depend very much on the computer architecture. IBM PC compatible hardware is one architecture Linux is commonly used on; on these systems, the BIOS plays an important role, which might not have exact analogs on other systems. In the following example, IBM PC compatible hardware is assumed:

  1. The BIOS performs startup tasks specific to the actual hardware platform.
  2. Once the hardware is enumerated and the hardware which is necessary for boot is initialized correctly, the BIOS loads and executes the boot code from the configured boot device. This boot code contains phase 1 of a Linux boot loader; phase 1 loads phase 2, which is the bulk of the boot loader code. Some loaders may use an intermediate phase (known as phase 1.5) to achieve this, since they are designed to be able to interpret filesystem layouts to locate the phase 2 loader.
  3. The boot loader often presents the user with a menu of possible boot options. The boot loader can be configured to time out if the user does not interact with the boot loader, thus selecting a default kernel and system configuration. After the selection is made, or after reaching a selection time-out, boot loader loads the kernel, which decompresses itself and sets up system functions such as essential hardware and memory paging, before calling start_kernel().
  4. start_kernel() then performs the majority of system setup (interrupts, the rest of memory management, device and driver initialization, etc.) before spawning separately, the idle process and scheduler, and the init process (which is executed in user space).
  5. The init process executes scripts as needed that set up all non-operating system services and structures in order to allow a user environment to be created. Usually, these scripts then present the user with a way to authenticate and thus login into the system.

On shutdown, init is called to close down all user space functionality in a controlled manner, again via scripted directions, following which init terminates and the kernel executes its own shutdown.

However, as of February 2014 Linux distributions such as Debian,[1] Arch, Fedora, and openSUSE have moved to systemd, which replaces init process as the first process executed in user space during the Linux startup. At the same time, systemd replaces the traditional init system based on shell scripts with a set of daemons having their initialization instructions recorded in declarative configuration files.

Early user space[edit]

Main article: initramfs

initramfs, also known as early user space, has been available since version 2.5.46 of the Linux kernel,[2] with the intent to replace as many functions as possible that previously the kernel would have performed during the start-up process. Typical uses of early user space are to detect what device drivers are needed to load the main user space file system and load them from a temporary filesystem.

Boot loader phase[edit]

The boot loader phase varies by computer architecture. Since the earlier phases are not specific to the operating system, the BIOS-based boot process for x86 and x86-64 architectures is considered to start when the master boot record (MBR) code is executed in real mode and the first-stage boot loader is loaded, which is typically a part of LILO or GRUB.[3] From that point, the boot process continues as described below.

The first-stage boot loader (stored within the MBR or the volume boot record) loads the remainder of the boot loader, which typically gives a prompt asking which operating system (or type of session) the user wishes to initialize. LILO and GRUB differ in some ways:[3]


Main article: GNU GRUB
  1. The first-stage loader (stage1) is loaded and executed either by the BIOS from the Master boot record (MBR) or by another boot loader from the partition boot sector.
  2. If necessary, an intermediate stage loader (stage1.5) is loaded and executed by the first-stage loader. This may be necessary if the second-stage loader is not contiguous, or if the filesystem or hardware requires special handling in order to access the second-stage loader.
  3. The second-stage loader (stage2) is then loaded and executed. This displays the GRUB startup menu, which allows the user to choose an operating system or to examine and edit startup parameters.
  4. After an operating system is chosen, GRUB loads its kernel into memory and passes control to the kernel. Alternatively, GRUB can pass control of the boot process to another boot loader, using chain loading.


Main article: LILO (boot loader)

LILO, the older of the two boot loaders, is almost identical to GRUB in process, except that its command line interface allows only selection of options previously recorded in the boot sector and map file. Thus all changes must be made to its configuration and written to the boot sector and map file, and then the system restarted. An error in configuration can therefore leave a disk unable to be booted without use of a separate boot device (floppy disk etc.) containing a program capable of fixing this.[5] Additionally, it does not understand filesystems. Instead, locations of image files are stored within the boot sector and map file directly[5] and the BIOS is used to access them directly.


Main article: Loadlin

Yet another way to boot Linux is from DOS or Windows 9x, where the Linux kernel completely replaces the running copy of this operating system. This can be useful in the case of hardware which needs to be switched on via software and for which such configuration programs are only available for DOS, whereas not for Linux, those being proprietary to the manufacturer and kept an industry secret. This tedious booting method is less necessary nowadays, as Linux has drivers for a multitude of hardware devices, but it has seen some use in mobile devices.

Another case is when the Linux is located on a storage device which is not available to the BIOS for booting: DOS or Windows can load the appropriate drivers to make up for the BIOS limitation, and boot Linux from there.

Kernel phase[edit]

The kernel in Linux handles all operating system processes, such as memory management, task scheduling, I/O, interprocess communication, and overall system control. This is loaded in two stages - in the first stage the kernel (as a compressed image file) is loaded into memory and decompressed, and a few fundamental functions such as basic memory management are set up. Control is then switched one final time to the main kernel start process. Once the kernel is fully operational – and as part of its startup, upon being loaded and executing – the kernel looks for an init process to run, which (separately) sets up a user space and the processes needed for a user environment and ultimate login. The kernel itself is then allowed to go idle, subject to calls from other processes.

Kernel loading stage[edit]

The kernel as loaded is typically an image file, compressed into either zImage or bzImage formats with zlib. A routine at the head of it does a minimal amount of hardware setup, decompresses the image fully into high memory, and takes note of any RAM disk if configured.[6] It then executes kernel startup via ./arch/i386/boot/head and the startup_32 () (for x86 based processors) process.

Kernel startup stage[edit]

Source: IBM description of Linux boot process

The startup function for the kernel (also called the swapper or process 0) establishes memory management (paging tables and memory paging), detects the type of CPU and any additional functionality such as floating point capabilities, and then switches to non-architecture specific Linux kernel functionality via a call to start_kernel().

start_kernel executes a wide range of initialization functions. It sets up interrupt handling (IRQs), further configures memory, starts the Init process (the first user-space process), and then starts the idle task via cpu_idle(). Notably, the kernel startup process also mounts the initial RAM disk ("initrd") that was loaded previously as the temporary root file system during the boot phase. The initrd allows driver modules to be loaded directly from memory, without reliance upon other devices (e.g. a hard disk) and the drivers that are needed to access them (e.g. a SATA driver). This split of some drivers statically compiled into the kernel and other drivers loaded from initrd allows for a smaller kernel. The root file system is later switched via a call to pivot_root() which unmounts the temporary root file system and replaces it with the use of the real one, once the latter is accessible. The memory used by the temporary root file system is then reclaimed.

Thus, the kernel initializes devices, mounts the root filesystem specified by the boot loader as read only, and runs Init (/sbin/init) which is designated as the first process run by the system (PID = 1).[3] A message is printed by the kernel upon mounting the file system, and by Init upon starting the Init process. It may also optionally run Initrd[clarification needed] to allow setup and device related matters (RAM disk or similar) to be handled before the root file system is mounted.[3]

According to Red Hat, the detailed kernel process at this stage is therefore summarized as follows:[4]

"When the kernel is loaded, it immediately initializes and configures the computer's memory and configures the various hardware attached to the system, including all processors, I/O subsystems, and storage devices. It then looks for the compressed initrd image in a predetermined location in memory, decompresses it, mounts it, and loads all necessary drivers. Next, it initializes virtual devices related to the file system, such as LVM or software RAID before unmounting the initrd disk image and freeing up all the memory the disk image once occupied. The kernel then creates a root device,[clarification needed] mounts the root partition read-only, and frees any unused memory. At this point, the kernel is loaded into memory and operational. However, since there are no user applications that allow meaningful input to the system, not much can be done with it." An initramfs-style boot is similar, but not identical to the described initrd boot.

At this point, with interrupts enabled, the scheduler can take control of the overall management of the system, to provide pre-emptive multi-tasking, and the init process is left to continue booting the user environment in user space.

Init process[edit]

SysV init[edit]

Init is the father of all processes. Its primary role is to create processes from a script stored in the file /etc/inittab. This file usually has entries which cause init to spawn gettys on each line that users can log in. It also controls autonomous processes required by any particular system. A run level is a software configuration of the system which allows only a selected group of processes to exist. The processes spawned by init for each of these run levels are defined in the /etc/inittab file.

— manual page for Init[7]

Init's job is "to get everything running the way it should be"[8] once the kernel is fully running. Essentially it establishes and operates the entire user space. This includes checking and mounting file systems, starting up necessary user services, and ultimately switching to a user-environment when system startup is completed. It is similar to the Unix and BSD init processes, from which it derived, but in some cases has diverged or became customized. In a standard Linux system, Init is executed with a parameter, known as a runlevel, that takes a value from 0 to 6, and that determines which subsystems are to be made operational. Each runlevel has its own scripts which codify the various processes involved in setting up or leaving the given runlevel, and it is these scripts which are referenced as necessary in the boot process. Init scripts are typically held in directories with names such as "/etc/rc...". The top level configuration file for init is at /etc/inittab.[8]

During system boot, it checks whether a default runlevel is specified in /etc/inittab, and requests the runlevel to enter via the system console if not. It then proceeds to run all the relevant boot scripts for the given runlevel, including loading modules, checking the integrity of the root file system (which was mounted read-only) and then remounting it for full read-write access, and sets up the network.[3]

After it has spawned all of the processes specified, init goes dormant, and waits for one of three events to happen: processes that started to end or die, a power failure signal,[clarification needed] or a request via /sbin/telinit to further change the runlevel.[7]

This applies to SysV-style init.


Main article: systemd


Main article: Upstart

See also[edit]


  1. ^ Bdale Garbee (2014-02-11), Bug#727708: call for votes on default Linux init system for jessie 
  2. ^ "Initramfs arrives". Retrieved 14 November 2011. 
  3. ^ a b c d e f Linux Boot Process - by Kim Oldfield (2001)
  4. ^ a b "Product Documentation". 2013-09-30. Retrieved 2014-01-22. 
  5. ^ a b c "Product Documentation". 2013-09-30. Retrieved 2014-01-22. 
  6. ^ IBM description of Linux boot process at the Wayback Machine (archived May 31, 2008)
  7. ^ a b init
  8. ^ a b From Power Up To Bash Prompt: Init

External links[edit]