Booting process of Linux: Difference between revisions

Revision as of 07:42, 15 October 2007

Latest revision as of 15:56, 25 August 2025

(427 intermediate revisions by more than 100 users not shown)

Line 1:

{{Short description|Multi-stage initialisation process of operating system}}

{{Expert-subject|Linux}}

{{Technical|date=August 2025}}

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

The Linux [[booting]] process involves multiple stages and is in many ways similar to the [[BSD]] and other [[Unix]]-style boot processes, from which it is derived. Although the Linux booting process depends very much on the computer architecture, those architectures share similar stages and software components,{{Sfn|M. Tim Jones|2006|ps=, "The process of booting a Linux® system consists of a number of stages. But whether you're booting a standard x86 desktop or a deeply embedded PowerPC® target, much of the flow is surprisingly similar."|loc="Introduction"}} including system startup, [[bootloader]] execution, loading and startup of a [[Linux kernel]] image, and execution of various [[startup scripts]] and [[Daemon (computing)|daemons]].{{Sfn|M. Tim Jones|2006|ps=, "Figure 1. The 20,000-foot view of the Linux boot process"|loc="Overview"}} Those are grouped into 4 steps: system startup, bootloader stage, kernel stage, and init process.{{Sfn|M. Tim Jones|2006|ps=|loc="Linux booting process are grouped into 4 stages, based on IBM source"}}

When a Linux system is powered up or reset, its processor will execute a specific firmware/program for system initialization, such as the [[power-on self-test]], invoking the [[reset vector]] to start a program at a known address in flash/ROM (in embedded Linux devices), then load the bootloader into RAM for later execution.{{Sfn|M. Tim Jones|2006|ps=, "Figure 1. The 20,000-foot view of the Linux boot process"|loc="Overview"}} In [[IBM PC–compatible]] [[personal computers]] (PCs), this firmware/program is either a [[BIOS]] or a [[UEFI]] monitor, and is stored in the mainboard.{{Sfn|M. Tim Jones|2006|ps=, "Figure 1. The 20,000-foot view of the Linux boot process"|loc="Overview"}} In embedded Linux systems, this firmware/program is called [[boot ROM]].<ref>{{Cite book |last1=Bin |first1=Niu |title=2020 International Symposium on Computer Engineering and Intelligent Communications (ISCEIC) |last2=Dejian |first2=Li |last3=Zhangjian |first3=LU |last4=Lixin |first4=Yang |last5=Zhihua |first5=Bai |last6=Longlong |first6=He |last7=Sheng |first7=Liu |date=August 2020 |isbn=978-1-7281-8171-4 |pages=5–8 |chapter=Research and design of Bootrom supporting secure boot mode |doi=10.1109/ISCEIC51027.2020.00009 |s2cid=231714880}}</ref>{{Sfn|Alberto Liberal De Los Ríos|2017|loc=, "Linux Boot Process"|p=28}} After being loaded into RAM, the bootloader (also called first-stage bootloader or primary bootloader) will execute to load the second-stage bootloader{{Sfn|M. Tim Jones|2006|ps=, "Figure 1. The 20,000-foot view of the Linux boot process"|loc="Overview"}} (also called secondary bootloader).{{Sfn|M. Tim Jones|2006|loc=, "Stage 1 boot loader"}} The second-stage bootloader will load the kernel image into memory, decompress and initialize it, and then pass control to this kernel image.{{Sfn|M. Tim Jones|2006|ps=, "Figure 1. The 20,000-foot view of the Linux boot process"|loc="Overview"}} The second-stage bootloader also performs several operations on the system such as system hardware check, mounting the root device, loading the necessary kernel modules, etc.{{Sfn|M. Tim Jones|2006|ps=, "Figure 1. The 20,000-foot view of the Linux boot process"|loc="Overview"}} Finally, the first user-space process (<code>init</code> process) starts, and other high-level system initializations are performed (which involve with startup scripts).{{Sfn|M. Tim Jones|2006|ps=, "Figure 1. The 20,000-foot view of the Linux boot process"|loc="Overview"}}

==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.

For each of these stages and components, there are different variations and approaches; for example, [[GNU GRUB|GRUB]], [[systemd-boot]], [[coreboot]] or [[Das U-Boot]] can be used as bootloaders (historical examples are [[LILO (boot loader)|LILO]], [[SYSLINUX]] or [[Loadlin]]), while the startup scripts can be either traditional [[init]]-style, or the system configuration can be performed through modern alternatives such as [[systemd]] or [[Upstart (software)|Upstart]].

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 <code>start_kernel()</code>.

# <code>start_kernel()</code> 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.

== System startup ==

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.

System startup has different steps based on the hardware that Linux is being booted on.{{Sfn|M. Tim Jones|2006|loc=, "System startup"}}

[[IBM PC compatible]] hardware is one architecture Linux is commonly used on; on these systems, the [[BIOS]] or [[UEFI]] firmware plays an important role.

==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 architecture|x86]] or [[x64]]: when the partition boot sector code is executed in [[real mode]] and loads the first stage [[boot loader]] (typically a part of [[LILO (boot loader)|LILO]] or [[GRUB]]).

From that point, the boot process continues as follows:

In BIOS systems, the BIOS will respectively perform power-on self test (POST), which is to check the system hardware, then enumerate local device and finally initialize the system.{{Sfn|M. Tim Jones|2006|loc=, "System startup"}} For system initialization, BIOS will start by searching for the bootable device on the system which stores the OS. A bootable device can be storage devices like floppy disk, CD-ROM, USB flash drive, a partition on a hard disk (where a hard disk stores multiple OS, e.g Windows and Fedora), a storage device on local network, etc.{{Sfn|M. Tim Jones|2006|loc=, "System startup"}} A hard disk to boot Linux stores the [[Master boot record|Master Boot Record]] (MBR), which contains the first-stage/primary bootloader in order to be loaded into RAM.{{Sfn|M. Tim Jones|2006|loc=, "System startup"}}

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 <code>/etc/lilo.conf</code> 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 [[parameter]]s, control is passed to it.

In [[UEFI]] systems, the Linux kernel can be executed directly by UEFI firmware via the EFI boot stub,<ref>{{Cite web |title=EFI stub kernel - Gentoo Wiki |url=https://wiki.gentoo.org/wiki/EFI_stub_kernel |access-date=2020-11-02 |website=wiki.gentoo.org}}</ref> but usually uses [[GRUB 2]] or [[Gummiboot (software)|systemd-boot]] as a bootloader.<ref name="Intel2000">{{cite web |last=Kinney |first=Michael |date=1 September 2000 |title=Solving BIOS Boot Issues with EFI |url=http://systems.cs.colorado.edu/Documentation/IntelDataSheets/xscalemagazine.pdf |url-status=dead |archive-url=https://web.archive.org/web/20070123141151/http://systems.cs.colorado.edu/Documentation/IntelDataSheets/xscalemagazine.pdf |archive-date=23 January 2007 |access-date=14 September 2010 |pages=47–50}}</ref><ref name="ElReg1">{{cite news |date=23 September 2011 |title=MS denies secure boot will exclude Linux |url=https://www.theregister.co.uk/2011/09/23/ms_denies_uefi_lock_in/ |access-date=24 September 2011 |publisher=The Register}}</ref>

LILO and GRUB differ in some ways:<ref name="oldfield">http://oldfield.wattle.id.au/luv/boot.html Linux Boot Process - by Kim Oldfield (2001)]</ref>

* 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 [[Windows]], or the kernel image for Linux.<ref name="oldfield" />

* GRUB by contrast does have understanding of the common [[ext2]] and [[ext3]] file systems.<ref name="redhat_startup">http://www.redhat.com/docs/manuals/linux/RHL-9-Manual/ref-guide/s1-boot-init-shutdown-process.html</ref> 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.<ref name="redhat_lilo">http://www.redhat.com/docs/manuals/linux/RHL-9-Manual/ref-guide/s1-grub-lilo.html</ref>

If [[UEFI#Secure_Boot|UEFI Secure Boot]] is supported, a "shim" or "Preloader" is often booted by the UEFI before the bootloader or EFI-stub-bearing kernel.<ref>{{Cite web |title=Using a Signed Bootloader - Arch Wiki |url=https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot#Using_a_signed_boot_loader |access-date=2024-12-05 |website=wiki.archlinux.org}}</ref> Even if [[UEFI#Secure_Boot|UEFI Secure Boot]] is disabled this may be present and booted in case it is later enabled. It merely acts to add an extra signing key database providing keys for signature verification of subsequent boot stages without modifying the UEFI key database, and chains to the subsequent boot step the same as the UEFI would have.

===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 [[cylinder head]]s 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.

The system startup stage on embedded Linux system starts by executing the firmware / program on the on-chip [[boot ROM]], which then load bootloader / operating system from the storage device like eMMC, eUFS, NAND flash, etc.{{Sfn|Alberto Liberal De Los Ríos|2017|loc=, "Linux Boot Process"|p=28}} The sequences of system startup are varies by processors{{Sfn|Alberto Liberal De Los Ríos|2017|loc=, "Linux Boot Process"|p=28}} but all include hardware initialization and system hardware testing steps.{{Sfn|M. Tim Jones|2006|loc=, "System startup"}} For example in a system with an i.MX7D processor and a bootable device which stores the OS (including U-Boot), the on-chip boot ROM sets up the [[DDR SDRAM|DDR memory]] controller at first which allows the boot ROM's program to obtain the SoC configuration data from the external bootloader on the bootable device.{{Sfn|Alberto Liberal De Los Ríos|2017|loc=, "Linux Boot Process"|p=28}} The on-chip boot ROM then loads the U-Boot into DRAM for the bootloader stage.{{Sfn|Alberto Liberal De Los Ríos|2017|loc=, "Linux Boot Process"|p=29}}

===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.<ref name="redhat_lilo" /> Additionally it does not understand file systems, instead locations of image files are stored within the MBR directly<ref name="redhat_lilo" /> and the BIOS is used to access them directly.

== Bootloader stage ==

==Kernel phase==

In [[IBM PC compatible]]s, the first stage bootloader, which is a part of the MBR, is a 512-byte image containing the vendor-specific program code and a partition table.{{Sfn|M. Tim Jones|2006|loc=, "Stage 1 boot loader"}} As mentioned earlier in the introduction part, the first stage bootloader will find and load the second stage bootloader.{{Sfn|M. Tim Jones|2006|loc=, "Stage 1 boot loader"}} It does this by searching in the partition table for an active partition.{{Sfn|M. Tim Jones|2006|loc=, "Stage 1 boot loader"}} After finding an active partition, first stage bootloader will keep scanning the remaining partitions in the table to ensure that they're all inactive.{{Sfn|M. Tim Jones|2006|loc=, "Stage 1 boot loader"}} After this step, the active partition's boot record is read into RAM and executed as the second stage bootloader.{{Sfn|M. Tim Jones|2006|loc=, "Stage 1 boot loader"}} The job of the second stage bootloader is to load the Linux kernel image into memory, and optional initial RAM disk.{{Sfn|M. Tim Jones|2006|loc=, "Stage 2 boot loader"}} Kernel image isn't an executable kernel, but a [[Vmlinux|"compressed file" of the kernel]] instead, compressed into either [[Vmlinux|zImage or bzImage]] formats with [[zlib]].{{Sfn|M. Tim Jones|2006|loc=, "Kernel"}}

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 &ndash; and as part of its startup, upon being loaded and executing &ndash; 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.

In x86 PC, first- and second-stage bootloaders are combined into the [[GNU GRUB|GRand Unified Bootloader]] (GRUB), and formerly Linux Loader ([[LILO (bootloader)|LILO]]).{{Sfn|M. Tim Jones|2006|loc=, "Stage 2 boot loader"}} [[GRUB 2]], which is now used, differs from GRUB 1 by being capable of automatic detection of various operating systems and automatic configuration. The stage1 is loaded and executed either by the [[BIOS]] from the [[Master boot record]] (MBR). The intermediate stage loader (stage1.5, usually core.img) is loaded and executed by the stage1 loader. The second-stage loader (stage2, the /boot/grub/ files) is loaded by the stage1.5 and displays the GRUB startup menu that allows the user to choose an operating system or examine and edit startup parameters. After a menu entry is chosen and optional parameters are given, GRUB loads the linux kernel into memory and passes control to it. GRUB 2 is also capable of chain-loading of another bootloader. In [[UEFI]] systems, the stage1 and stage1.5 usually are the same UEFI application file (such as grubx64.efi for [[x64]] UEFI systems).

===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.<ref name="ibm_description">[http://www-128.ibm.com/developerworks/library/l-linuxboot/index.html IBM description of Linux boot process]</ref> It then executes kernel startup via <code>./arch/i386/boot/head</code> and the <code>startup_32 ()</code> (for x86 based processors) process.

Beside GRUB, there are some more popular bootloaders:

===Kernel startup stage===

* [[Gummiboot (software)|systemd-boot]] (formerly Gummiboot), a bootloader included with [[systemd]] that requires minimal configuration (for [[UEFI]] systems only).

:''Source: [http://www-128.ibm.com/developerworks/library/l-linuxboot/index.html IBM description of Linux boot process]''

* SYSLINUX/ISOLINUX is a bootloader that specializes in booting full Linux installations from FAT filesystems. It is often used for boot or rescue floppy discs, [[live USB]]s, and other lightweight boot systems. ISOLINUX is generally used by Linux [[live CD]]s and bootable install CDs.

* [[rEFInd]], a [[boot manager]] for [[UEFI]] systems.

* [[coreboot]] is a free implementation of the [[UEFI]] or [[BIOS]] and usually deployed with the [[system board]], and field upgrades provided by the vendor if need be. Parts of coreboot becomes the systems BIOS and stays resident in memory after boot.

* [[Das U-Boot]] is a bootloader for embedded systems. It is used on systems that do not have a BIOS/UEFI but rather employ custom methods to read the bootloader into memory and execute it.

Historical bootloaders, no longer in common use, include:

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 <code>start_kernel ()</code>.

* [[LILO (boot loader)|LILO]] does not understand or parse filesystem layout. Instead, a configuration file (<code>/etc/lilo.conf</code>) is created in a live system which maps raw offset information (mapper tool) about ___location of kernel and ram disks (initrd or initramfs). The configuration file, which includes data such as boot [[Disk partitioning|partition]] and [[Kernel (computer science)|kernel]] pathname for each, as well as customized options if needed, is then written together with bootloader code into MBR bootsector. When this bootsector is read and given control by BIOS, LILO loads the menu code and draws it then uses stored values together with user input to calculate and load the Linux kernel or [[Chain loading|chain-load]] any other [[Booting#Boot-loader|boot-loader]].

start_kernel executes a wide range of initialization functions. It sets up [[interrupt handling]] ([[IRQ]]s), further configures memory, starts the Init process (the first user-space process), and then starts the idle task via <code>cpu_idle ()</code>. 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 <code>pivot_root ()</code> 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.

* GRUB 1 includes logic to read common file systems at run-time in order to access its configuration file.<ref name="redhat_startup">{{cite web|url=http://www.redhat.com/docs/manuals/linux/RHL-9-Manual/ref-guide/s1-boot-init-shutdown-process.html |archive-url=https://web.archive.org/web/20080830065326/http://www.redhat.com/docs/manuals/linux/RHL-9-Manual/ref-guide/s1-boot-init-shutdown-process.html |url-status=dead |archive-date=2008-08-30 |title=Product Documentation |publisher=Redhat.com |date=2013-09-30 |access-date=2014-01-22}}</ref> This gives GRUB 1 ability to read its configuration file from the filesystem rather than have it embedded into the MBR, which allows it to change the configuration at run-time and specify disks and partitions in a human-readable format rather than relying on offsets. It also contains a [[command-line interface]], which makes it easier to fix or modify GRUB if it is misconfigured or corrupt.<ref name="redhat_lilo">{{cite web|url=http://www.redhat.com/docs/manuals/linux/RHL-9-Manual/ref-guide/s1-grub-lilo.html |title=Product Documentation |publisher=Redhat.com |date=2013-09-30 |access-date=2014-01-22}}</ref>

* [[Loadlin]] is a bootloader that can replace a running [[DOS]] or [[Windows 9x]] kernel with the Linux kernel at run time. This can be useful in the case of hardware that needs to be switched on via software and for which such configuration programs are proprietary and only available for DOS. This booting method is less necessary nowadays, as Linux has drivers for a multitude of hardware devices, but it has seen some use in [[mobile device]]s. Another use 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 ==

Thus, the kernel initializes devices, mounts the root filesystem specified by the boot loader as [[read only]], and runs [[Init process|Init]] (<code>/sbin/init</code>) which is designated as the first process run by the system ([[PID]] = 1).<ref name="oldfield" /> 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.<ref name="oldfield" />

The kernel stage occurs after the bootloader stage. The [[Linux kernel]] handles all operating system processes, such as [[memory management]], task [[scheduling (computing)|scheduling]], [[I/O]], [[interprocess communication]], and overall system control. This is loaded in two stages &ndash; in the first stage, the kernel (as a compressed image file) is loaded into memory and decompressed, and a few fundamental functions are set up such as basic memory management, minimal amount of hardware setup.{{Sfn|M. Tim Jones|2006|loc=, "Kernel"}} The kernel image is self-decompressed, which is a part of the kernel image's routine.{{Sfn|M. Tim Jones|2006|loc=, "Kernel"}} For some platforms (like ARM 64-bit), kernel decompression has to be performed by the bootloader instead, like U-Boot.{{Sfn|Alberto Liberal De Los Ríos|2017|loc=, "Bootloader"|p=20}}

For details of those steps, take an example with [[i386]] microprocessor. When its bzImage is invoked, function <code>start()</code> (of <code>./arch/i386/boot/head.S</code>) is called to do some basic hardware setup then calls <code>startup_32()</code> (located in <code>./arch/i386/boot/compressed/head.S</code>).{{Sfn|M. Tim Jones|2006|loc=, "Kernel"}} <code>startup_32()</code>will do basic setup to environment (stack, etc.), clears the [[.bss|Block Started by Symbol]] (BSS) then invokes <code>decompress_kernel()</code> (located in <code>./arch/i386/boot/compressed/misc.c</code>) to decompress the kernel.{{Sfn|M. Tim Jones|2006|loc=, "Kernel"}} Kernel startup is then executed via a different <code>startup_32()</code> function located in <code>./arch/i386/kernel/head.S</code>.{{Sfn|M. Tim Jones|2006|loc=, "Kernel"}} The startup function <code>startup_32()</code> for the kernel (also called the swapper or process 0) establishes [[memory management]] (paging tables and memory paging), detects the type of [[Central processing unit|CPU]] and any additional functionality such as [[floating point]] capabilities, and then switches to non-architecture specific Linux kernel functionality via a call to <code>start_kernel()</code> located in <code>./init/main.c</code>.{{Sfn|M. Tim Jones|2006|loc=, "Kernel"}}

According to [[Red Hat]], the detailed kernel process at this stage is therefore summarized as follows: <ref name="redhat_startup" />

:"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."

{{Anchor|Early user space}}<code>start_kernel()</code>executes a wide range of initialization functions. It sets up [[interrupt handling]] ([[Interrupt request|IRQ]]s), further configures memory, mounts the [[initrd|initial RAM disk]] ("initrd") that was loaded previously as the temporary root file system during the bootloader stage.{{Sfn|M. Tim Jones|2006|loc=, "Kernel"}} The initrd, which acts as a temporary root filesystem in RAM, allows the kernel to be fully booted and driver modules to be loaded directly from memory, without reliance upon other devices (e.g. a hard disk).{{Sfn|M. Tim Jones|2006|loc=, "Kernel"}} initrd contains the necessary modules needed to interface with peripherals,{{Sfn|M. Tim Jones|2006|loc=, "Kernel"}} e.g SATA driver, and support a large number of possible hardware configurations.{{Sfn|M. Tim Jones|2006|loc=, "Kernel"}} This split of some drivers statically compiled into the kernel and other drivers loaded from initrd allows for a smaller kernel.{{Sfn|M. Tim Jones|2006|loc=, "Kernel"}} [[initramfs]], also known as early user space, has been available since version 2.5.46 of the Linux kernel,<ref>{{cite web |last1=Corbet |first1=Jonathan |title=Initramfs arrives |date=6 November 2002 |url=https://lwn.net/Articles/14776/ |access-date=14 November 2011}}</ref> with the intent to replace as many functions as possible that previously the kernel would have performed during the startup process. Typical uses of early user space are to detect what [[device driver]]s are needed to load the main user space file system and load them from a [[temporary filesystem]]. Many distributions use [[dracut (software)|dracut]] to generate and maintain the initramfs image.

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.

The root file system is later switched via a call to <code>pivot_root()</code> which unmounts the temporary root file system and replaces it with the use of the real one, once the latter is accessible.{{Sfn|M. Tim Jones|2006|loc=, "Kernel"}} The memory used by the temporary root file system is then reclaimed.{{Clarify|date=March 2010}}

==Init process (SysV init style only)==

:{| style="border:1px black solid"

| "Init is the father of all [[process]]es. Its primary role is to create processes from a script stored in the file <code>/etc/inittab</code>. This file usually has entries which cause init to spawn [[getty]]s 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.

|- align="right"

|&ndash; manual page for Init<ref name="man_init">http://man.he.net/man8/init</ref>

|}

Finally, <code>kernel_thread</code> (in <code>arch/i386/kernel/process.c</code>) is called to start the Init process (the first user-space process), and then starts the idle task via <code>cpu_idle()</code>.{{Sfn|M. Tim Jones|2006|loc=, "Kernel"}}

Init's job is "to get everything running the way it should be" <ref name="p2b_6">http://axiom.anu.edu.au/~okeefe/p2b/power2bash/power2bash-6.html</ref> once the kernel is fully running. Essentially it establishes and operates the entirety of [[user space]]. This includes checking and mounting [[file system]]s, 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 become 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 [[script]]s 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 <code>"/etc/rc..."</code>. The top level configuration file for init is at <code>/etc/inittab</code>.<ref name="p2b_6" />

Thus, the kernel stage initializes devices, mounts the root filesystem specified by the bootloader as [[file system permissions|read only]], and runs [[Init process|Init]] (<code>/sbin/init</code>) which is designated as the first process run by the system ([[Process identifier|PID]] = 1).<ref name="oldfield">http://oldfield.wattle.id.au/luv/boot.html Linux Boot Process - by Kim Oldfield (2001)</ref> A message is printed by the kernel upon mounting the file system, and by Init upon starting the Init process.<ref name="oldfield" />

According to [[Red Hat]], the detailed kernel process at this stage is therefore summarized as follows:<ref name="redhat_startup" />

:"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 [[Logical Volume Manager (Linux)|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,{{Clarify|date=March 2010}} 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 ==

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 [[module]]s, 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 [[Computer network|network]].<ref name="oldfield" />

Once the kernel has started, it starts the [[init]] process,{{Sfn|M. Tim Jones|2006|loc=, "Init"}} a [[Daemon (computing)|daemon]] which then [[Bootstrapping#Software loading and execution|bootstraps]] the [[user space]], for example by checking and mounting [[file system]]s, and starting up other [[Process (computing)|processes]]. The init system is the first daemon to start (during booting) and the last daemon to terminate (during [[Shutdown (computing)|shutdown]]).

Historically this was the "SysV init", which was just called "init". More recent Linux distributions are likely to use one of the more modern alternatives such as [[systemd]]. Below is a summary of the main init processes:

In detail, according to Red Hat, the init process follows the following steps:<ref name="redhat_startup" />

# It looks at the sysinit script, which "sets the environment path, starts <code>[[swap]]</code>, 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.

* [[SysV init]] ({{Aka}} simply "init") is similar to the [[Unix]] and [[BSD]] init processes, from which it derived. In a standard Linux system, init is executed with a parameter, known as a [[runlevel]], which takes a value from 0 to 6 and determines which subsystems are made operational. Each runlevel has its own [[Script (computing)|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 <code>"/etc/rc..."</code>. The top level configuration file for init is at <code>/etc/inittab</code>.<ref name="p2b_6">{{cite web |title=From Power Up To Bash Prompt: Init |url=http://users.cecs.anu.edu.au/~okeefe/p2b/power2bash/power2bash-6.html |website=users.cecs.anu.edu.au}}</ref> 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 [[Loadable kernel module|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 [[Computer network|network]].<ref name="oldfield" /> 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,{{Clarify|date=March 2010}} or a request via <code>/sbin/telinit</code> to further change the runlevel.<ref name="man_init2">{{cite web |title=init |url=http://man.he.net/man8/init |website=man.he.net}}</ref>

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 <code>/sbin/telinit</code> to further change the runlevel.<ref name="man_init" />

* [[systemd]] is a modern alternative to SysV init. Like init, systemd is a daemon that manages other daemons. All daemons, including systemd, are [[background process]]es. [[Lennart Poettering]] and [[Kay Sievers]], software engineers that initially developed systemd,<ref>{{cite web |title=systemd README |url=http://cgit.freedesktop.org/systemd/systemd/tree/README |accessdate=2012-09-09 |website=freedesktop.org}}</ref> sought to surpass the efficiency of the init daemon in several ways. They wanted to improve the software framework for expressing dependencies, to allow more processing to be done in [[Parallel computing|parallel]] during system booting, and to reduce the [[computational overhead]] of the [[Shell (computing)|shell]]. Systemd's initialization instructions for each daemon are recorded in a declarative configuration file rather than a shell script. For [[inter-process communication]], systemd makes [[Unix ___domain socket]]s and [[D-Bus]] available to the running daemons. Systemd is also capable of aggressive parallelization.

Please note that this applies to SysV-style init binaries. Other init binaries may behave differently.

== See also ==

<!--== Differences from other boot processes==

{{sectstubPortal|Linux}}

* [[SYSLINUX]]

* [[Booting process of Android devices]]

* [[Booting process of macOS]]

* [[Booting process of Windows]]

===Unix= References ==

{{sectstubReflist|30em}}

===FreeBSD Works cited ===

{{sectstub}}

-->

* {{Cite web |last=M. Tim Jones |date=31 May 2006 |title=Inside the Linux boot process |url=http://www.ibm.com/developerworks/library/l-linuxboot/index.html |url-status=dead |archive-url=https://web.archive.org/web/20071011074709/http://www.ibm.com/developerworks/library/l-linuxboot/index.html |archive-date=2007-10-11 |access-date=2024-01-14 |website=IBM}}

==Sources==

*{{Cite book |last=Alberto Liberal De Los Ríos |url=https://github.com/ALIBERA/linux_book_2nd_edition |title=Linux Driver Development for Embedded Processors |publisher=Editorial Círculo Rojo; 1st edition |year=2017 |isbn=978-8491600190 |edition=2nd |publication-date=March 3, 2017 |language=English}}

* [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

== External links ==

==References==

* [[wikiversity:Linux/Reading_the_Linux_Kernel_Sources|Reading the Linux Kernel Sources]], Wikiversity

<references />

* {{webarchive |url=https://web.archive.org/web/20091023232400/http://axiom.anu.edu.au/~okeefe/p2b/power2bash/power2bash.html |date=Oct 23, 2009 |title=Greg O'Keefe - From Power Up To Bash Prompt }}

* [https://web.archive.org/web/20121105224739/http://www.bootchart.org/ Bootchart: Boot Process Performance Visualization]

* [https://lwn.net/Articles/632528/ The bootstrap process on EFI systems], [[LWN.net]], February 11, 2015, by Matt Fleming

{{Linux kernel}}

==See also==

{{Linux}}

* [[Windows NT Startup Process]]

{{Firmware and booting}}

[[Category:LinuSFSFSDFxBooting processes]]

[[Category:BootingLinux]]

[[Category:Linux kernel]]