Linux startup process

The Linux startup process is the process by which Linux-based operating systems initialize. It is in many ways similar to the BSD and other Unix style boot processes, from which it derives.

Overview of typical process

In Linux, the flow of control during a boot is from BIOS, to boot loader, to kernel. The kernel then starts the scheduler (to allow multi-tasking) and runs Init (which sets up the user environment and allows user interaction and login), at which point the kernel goes idle unless called externally.

In detail:
# The BIOS performs hardware-platform specific startup tasks
# Once the hardware is recognized and started correctly, the BIOS loads and executes the partition boot code from the designated boot device, which contains phase 1 of a Linux boot loader. Phase 1 loads phase 2 (the bulk of the boot loader code). Some loaders may use an intermediate stage to achieve this (known as phase 1.5) since modern large disks may not be fully readable without further code.
# The boot loader often presents the user with a menu of possible boot options. It then loads the kernel, which decompresses into memory, and sets up system functions such as essential hardware and memory paging, before calling start_kernel().
# start_kernel() then performs the majority of system setup (interrupts, the rest of memory management, device initialization, drivers, etc) before spawning separately, the idle process and scheduler, and the Init process (which is executed in user space).
# The scheduler effectively takes control of the system management, as the kernel goes dormant (idle).
# The Init process executes scripts as needed that set up all non-kernel services and structures in order to allow a user environment to be created, and then presents the user with a login screen.

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.

Boot loader phase

The boot loader phase varies by platform. Since the earlier phases are not specific to the OS, the boot process is considered to start:
* For x86 or x86-64: when the partition boot sector code is executed in real mode and loads the first stage boot loader (typically a part of LILO or GRUB).From that point, the boot process continues as follows:

The first stage boot loader 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. Under LILO, this is done via the map installer which reads the configuration file /etc/lilo.conf to identify the available systems. It includes data such as boot partition and kernel location for each, as well as customized options if any. Upon selection, the appropriate kernel is loaded into RAM memory as an image file ("initrd"), and along with the appropriate parameters, control is passed to it.

LILO and GRUB differ in some ways:http://oldfield.wattle.id.au/luv/boot.html Linux Boot Process - by Kim Oldfield (2001)] ]
* LILO does not understand file systems, so it uses raw disk offsets and the BIOS for data load. It loads the menu code, and then depending on the response loads either the 512 byte disk sectors for an MBR system such as Microsoft Windows, or the kernel image for Linux.
* GRUB by contrast does have understanding of the common ext2 and ext3 file systems.http://www.redhat.com/docs/manuals/linux/RHL-9-Manual/ref-guide/s1-boot-init-shutdown-process.html] Because GRUB stores its data in a configuration file rather than the MBR and contains a command line interface, it is often easier to rectify or modify GRUB if misconfigured or corrupt.http://www.redhat.com/docs/manuals/linux/RHL-9-Manual/ref-guide/s1-grub-lilo.html]

GRUB

:"Source: [http://www.redhat.com/docs/manuals/linux/RHL-9-Manual/ref-guide/s1-grub-whatis.html Red Hat GRUB description] ."
# The first stage loader is read by the BIOS from the MBR (master boot record).
# The first stage loads the rest of the boot loader (second stage). If the second stage is on a large drive, sometimes an intermediate 1.5 stage is loaded, which contains extra code to allow cylinders above 1024, or LBA type drives, to be read. The 1.5 boot loader is stored (if needed) in the MBR or the boot partition.
# The second stage boot loader executes, and displays the GRUB startup menu. It also allows choice of operating environment, and examination of system parameters.
# When an operating system is chosen, it is loaded and control is passed.GRUB supports both direct and chain-loading boot methods, LBA, ext2, and "a true command-based, pre-OS environment on x86 machines". It contains three interfaces: a selection menu, a configuration editor, and a command line console.

LILO

LILO, the older of the two boot loaders, is almost identical to GRUB in process, except that it does not contain a command line interface. Thus all changes must be made to its configuration and written to the MBR, 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. Additionally it does not understand file systems, instead locations of image files are stored within the MBR directly and the BIOS is used to access them directly.

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 used to be helpful in the past. 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

The kernel in Linux handles core 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 fundamentals 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

The kernel as loaded is typically an image file, compressed into either zImage or bzImage formats with zlib. It contains a header program which does a minimal amount of hardware setup, decompresses the image fully into high memory, taking note of any RAM disk if configured. [http://www-128.ibm.com/developerworks/library/l-linuxboot/index.html IBM description of Linux boot process] ] It then executes kernel startup via ./arch/i386/boot/head and the startup_32 () (for x86 based processors) process.

Kernel startup stage

:"Source: [http://www-128.ibm.com/developerworks/library/l-linuxboot/index.html 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 filing system during the boot phase. This allows driver modules to be loaded without reliance upon other physical devices and drivers, and keeps the kernel smaller. 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). 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 to allow setup and device related matters (RAM disk or similar) to be handled before the root file system is mounted.

According to Red Hat, the detailed kernel process at this stage is therefore summarized as follows: :"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, 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."

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 (SysV init style only)

:

Init's job is "to get everything running the way it should be" [http://axiom.anu.edu.au/~okeefe/p2b/power2bash/power2bash-6.html From Power Up To Bash Prompt: Init ] ] 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-based 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 1 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.

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.

In detail, according to Red Hat, the init process follows the following steps:
# It looks at the sysinit script, which "sets the environment path, starts swap, checks the file systems, and takes care of everything the system needs to have done at system initialization." This includes the system and hardware clock, special serial port processes, and the like.
# Init then looks at the specific runlevel, as specified in that runlevels configuration.
# Init then sets the source function library for the system. This spells out how to start or kill a program and how to determine the PID of a program.
# It then starts all applicable processes and creates a login session for the user.

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

This applies to SysV-style init binaries. Other init binaries may behave differently.

See also

* SYSLINUX
* Windows NT Startup Process
* Windows Vista startup process

Notes

References

* [http://axiom.anu.edu.au/~okeefe/p2b/power2bash/power2bash.html Greg O'Keefe - From Power Up To Bash Prompt]
* [http://www-128.ibm.com/developerworks/library/l-linuxboot/index.html IBM description of Linux boot process] a developerWorks article by M. Tim Jones