# Booting process of Linux

> Mediated Wiki article. Canonical URL: https://mediated.wiki/source/Booting_process_of_Linux
> Markdown URL: https://mediated.wiki/source/Booting_process_of_Linux.md
> Source: https://en.wikipedia.org/wiki/Booting_process_of_Linux
> Source revision: 1344938803
> License: Creative Commons Attribution-ShareAlike 4.0 International (https://creativecommons.org/licenses/by-sa/4.0/)

Multi-stage initialisation process of operating system

This article may be too technical for most readers to understand. Please help improve it to make it understandable to non-experts, without removing the technical details. (August 2025) (Learn how and when to remove this message)

Linux kernel 6.1 booting on [Debian](/source/Debian) Bookworm

The Linux [booting](/source/Booting) process involves multiple stages and is in many ways similar to the [BSD](/source/BSD) and other [Unix](/source/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,[1] including system startup, [bootloader](/source/Bootloader) execution, loading and startup of a [Linux kernel](/source/Linux_kernel) image, and execution of various [startup scripts](/source/Startup_scripts) and [daemons](/source/Daemon_(computing)).[2] Those are grouped into 4 steps: system startup, bootloader stage, kernel stage, and init process.[3]

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](/source/Power-on_self-test), invoking the [reset vector](/source/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.[2] In [IBM PC–compatible](/source/IBM_PC%E2%80%93compatible) [personal computers](/source/Personal_computers) (PCs), this firmware/program is either a [BIOS](/source/BIOS) or a [UEFI](/source/UEFI) monitor, and is stored in the mainboard.[2] In embedded Linux systems, this firmware/program is called [boot ROM](/source/Boot_ROM).[4][5] After being loaded into RAM, the bootloader (also called first-stage bootloader or primary bootloader) will execute to load the second-stage bootloader[2] (also called secondary bootloader).[6] The second-stage bootloader will load the kernel image into memory, decompress and initialize it, and then pass control to this kernel image.[2] 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.[2] Finally, the first user-space process (init process) starts, and other high-level system initializations are performed (which involve with startup scripts).[2]

For each of these stages and components, there are different variations and approaches; for example, [GRUB](/source/GNU_GRUB), [systemd-boot](/source/Systemd-boot), [coreboot](/source/Coreboot) or [Das U-Boot](/source/Das_U-Boot) can be used as bootloaders (historical examples are [LILO](/source/LILO_(boot_loader)), [SYSLINUX](/source/SYSLINUX) or [Loadlin](/source/Loadlin)), while the startup scripts can be either traditional [init](/source/Init)-style, or the system configuration can be performed through modern alternatives such as [systemd](/source/Systemd) or [runit](/source/Runit).

## System startup

System startup has different steps based on the hardware that Linux is being booted on.[7]

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

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.[7] 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.[7] A hard disk to boot Linux stores the [Master Boot Record](/source/Master_boot_record) (MBR), which contains the first-stage/primary bootloader in order to be loaded into RAM.[7]

In UEFI systems, the Linux kernel can be executed directly by UEFI firmware via the EFI boot stub,[8] but usually uses [GRUB 2](/source/GRUB_2) or [systemd-boot](/source/Gummiboot_(software)) as a bootloader.[9][10]

If [UEFI Secure Boot](/source/UEFI#Secure_Boot) is supported, a "shim" or "Preloader" is often booted by the UEFI before the bootloader or EFI-stub-bearing kernel.[11] Even if [UEFI Secure Boot](/source/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.

The system startup stage on embedded Linux system starts by executing the firmware / program on the on-chip [boot ROM](/source/Boot_ROM), which then load bootloader / operating system from the storage device like eMMC, eUFS, NAND flash, etc.[5] The sequences of system startup varies by processors[5] but all include hardware initialization and system hardware testing steps.[7] 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 memory](/source/DDR_SDRAM) controller at first which allows the boot ROM's program to obtain the SoC configuration data from the external bootloader on the bootable device.[5] The on-chip boot ROM then loads the U-Boot into DRAM for the bootloader stage.[12]

## Bootloader stage

In [IBM PC compatibles](/source/IBM_PC_compatible) using a [BIOS](/source/BIOS), the first stage bootloader, which is a part of the [master boot record](/source/Master_boot_record) (MBR), is a 512-byte image containing the vendor-specific program code and a partition table.[6] As mentioned earlier in the introduction part, the first stage bootloader will find and load the second stage bootloader.[6] It does this by searching in the partition table for an active partition.[6] After finding an active partition, first stage bootloader will keep scanning the remaining partitions in the table to ensure that they're all inactive.[6] After this step, the active partition's boot record is read into RAM and executed as the second stage bootloader.[6] The job of the second stage bootloader is to load the Linux kernel image into memory, and optional initial RAM disk.[13] Kernel image isn't an executable kernel, but a ["compressed file" of the kernel](/source/Vmlinux) instead, compressed into either [zImage or bzImage](/source/Vmlinux) formats with [zlib](/source/Zlib).[14]

In those systems, the first- and second-stage bootloaders are usually provided by the [GRand Unified Bootloader](/source/GNU_GRUB) (GRUB), and formerly provided by the Linux Loader ([LILO](/source/LILO_(bootloader))).[13] [GRUB 2](/source/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 by the BIOS from the 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](/source/UEFI) systems, the stage1 and stage1.5 usually are the same UEFI application file (such as grubx64.efi for [x64](/source/X64) UEFI systems).

Beside GRUB, there are some more popular bootloaders:

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

- 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 USBs](/source/Live_USB), and other lightweight boot systems. ISOLINUX is generally used by Linux [live CDs](/source/Live_CD) and bootable install CDs.

- [rEFInd](/source/REFInd), a [boot manager](/source/Boot_manager) for [UEFI](/source/UEFI) systems.

- [coreboot](/source/Coreboot) is a free implementation of the [UEFI](/source/UEFI) or [BIOS](/source/BIOS) and usually deployed with the [system board](/source/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](/source/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:

- [LILO](/source/LILO_(boot_loader)) does not understand or parse filesystem layout. Instead, a configuration file (/etc/lilo.conf) 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 [partition](/source/Disk_partitioning) and [kernel](/source/Kernel_(computer_science)) 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-load](/source/Chain_loading) any other [boot-loader](/source/Booting#Boot-loader).

- GRUB 1 includes logic to read common file systems at run-time in order to access its configuration file.[15] 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](/source/Command-line_interface), which makes it easier to fix or modify GRUB if it is misconfigured or corrupt.[16]

- [Loadlin](/source/Loadlin) is a bootloader that can replace a running [DOS](/source/DOS) or [Windows 9x](/source/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 devices](/source/Mobile_device). 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

The kernel stage occurs after the bootloader stage. The [Linux kernel](/source/Linux_kernel) handles all operating system processes, such as [memory management](/source/Memory_management), task [scheduling](/source/Scheduling_(computing)), [I/O](/source/I%2FO), [interprocess communication](/source/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 are set up such as basic memory management, minimal amount of hardware setup.[14] The kernel image is self-decompressed, which is a part of the kernel image's routine.[14] For some platforms (like ARM 64-bit), kernel decompression has to be performed by the bootloader instead, like U-Boot.[17]

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

start_kernel()executes a wide range of initialization functions. It sets up [interrupt handling](/source/Interrupt_handling) ([IRQs](/source/Interrupt_request)), further configures memory, mounts the [initial RAM disk](/source/Initrd) ("initrd") that was loaded previously as the temporary root file system during the bootloader stage.[14] 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).[14] initrd usually contains the necessary modules needed to interface with storage peripherals,[14] e.g SATA driver, and support a large number of possible hardware configurations.[14] This split of some drivers statically compiled into the kernel and other drivers loaded from initrd allows for a smaller kernel.[14] [initramfs](/source/Initramfs), also known as early user space, has been available since version 2.5.46 of the Linux kernel,[18] 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 drivers](/source/Device_driver) are needed to load the main user space file system and load them from a [temporary filesystem](/source/Temporary_filesystem). Many distributions use [dracut](/source/Dracut_(software)) to generate and maintain the initramfs image.

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.[14] The memory used by the temporary root file system is then reclaimed.[*[clarification needed](https://en.wikipedia.org/wiki/Wikipedia:Please_clarify)*]

Finally, kernel_thread (in arch/i386/kernel/process.c) is called to start the Init process (the first user-space process), and then starts the idle task via cpu_idle().[14]

Thus, the kernel stage initializes devices, mounts the root filesystem specified by the bootloader as [read only](/source/File_system_permissions), and runs [Init](/source/Init_process) (/sbin/init) which is designated as the first process run by the system ([PID](/source/Process_identifier) = 1).[19] A message is printed by the kernel upon mounting the file system, and by Init upon starting the Init process.[19]

According to [Red Hat](/source/Red_Hat), the detailed kernel process at this stage is therefore summarized as follows:[15]

- "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](/source/Logical_Volume_Manager_(Linux)) or software [RAID](/source/RAID) before unmounting the initrd [disk image](/source/Disk_image) and freeing up all the memory the disk image once occupied. The kernel then creates a root device,[*[clarification needed](https://en.wikipedia.org/wiki/Wikipedia:Please_clarify)*] 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

Once the kernel has started, it starts the [init](/source/Init) process,[20] a [daemon](/source/Daemon_(computing)) which then [bootstraps](/source/Bootstrapping#Software_loading_and_execution) the [user space](/source/User_space), for example by checking and mounting [file systems](/source/File_system), and starts up other [processes](/source/Process_(computing)). The init system is the first daemon to start (during booting) and the last daemon to terminate (during [shutdown](/source/Shutdown_(computing))).

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

- SysV init (a.k.a. simply "init") is similar to the init process of [UNIX System V](/source/UNIX_System_V). In a standard Linux system, init is executed with a parameter, known as a [runlevel](/source/Runlevel), which takes a value from 0 to 6 and determines which subsystems are made operational. Each runlevel has its own [scripts](/source/Script_(computing)) 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.[21] During system boot, it checks whether a default runlevel is specified in /etc/inittab, and requests the runlevel to enter via the [system console](/source/System_console) if not. It then proceeds to run all the relevant boot scripts for the given runlevel, including loading [modules](/source/Loadable_kernel_module), 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](/source/Computer_network).[19] 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](https://en.wikipedia.org/wiki/Wikipedia:Please_clarify)*] or a request via /sbin/telinit to further change the runlevel.[22]

- systemd is a modern alternative to SysV init. Like init, systemd is a daemon that manages other daemons. All daemons, including systemd, are [background processes](/source/Background_process). [Lennart Poettering](/source/Lennart_Poettering) and [Kay Sievers](/source/Kay_Sievers), software engineers that initially developed systemd,[23] 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](/source/Parallel_computing) during system booting, and to reduce the [computational overhead](/source/Computational_overhead) of the [shell](/source/Shell_(computing)). Systemd's initialization instructions for each daemon are recorded in a declarative configuration file rather than a shell script. For [inter-process communication](/source/Inter-process_communication), systemd makes [Unix domain sockets](/source/Unix_domain_socket) and [D-Bus](/source/D-Bus) available to the running daemons. Systemd is also capable of aggressive parallelization.

## See also

- [Linux portal](https://en.wikipedia.org/wiki/Portal:Linux)

- [SYSLINUX](/source/SYSLINUX)

- [Booting process of Android devices](/source/Booting_process_of_Android_devices)

- [Booting process of macOS](/source/Booting_process_of_macOS)

- [Booting process of Windows](/source/Booting_process_of_Windows)

## References

1. **[^](#cite_ref-FOOTNOTEM._Tim_Jones2006"Introduction"_1-0)** [M. Tim Jones 2006](#CITEREFM._Tim_Jones2006), "Introduction", "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."

1. ^ [***a***](#cite_ref-FOOTNOTEM._Tim_Jones2006"Overview"_2-0) [***b***](#cite_ref-FOOTNOTEM._Tim_Jones2006"Overview"_2-1) [***c***](#cite_ref-FOOTNOTEM._Tim_Jones2006"Overview"_2-2) [***d***](#cite_ref-FOOTNOTEM._Tim_Jones2006"Overview"_2-3) [***e***](#cite_ref-FOOTNOTEM._Tim_Jones2006"Overview"_2-4) [***f***](#cite_ref-FOOTNOTEM._Tim_Jones2006"Overview"_2-5) [***g***](#cite_ref-FOOTNOTEM._Tim_Jones2006"Overview"_2-6) [M. Tim Jones 2006](#CITEREFM._Tim_Jones2006), "Overview", "Figure 1. The 20,000-foot view of the Linux boot process"

1. **[^](#cite_ref-FOOTNOTEM._Tim_Jones2006"Linux_booting_process_are_grouped_into_4_stages,_based_on_IBM_source"_3-0)** [M. Tim Jones 2006](#CITEREFM._Tim_Jones2006), "Linux booting process are grouped into 4 stages, based on IBM source"

1. **[^](#cite_ref-4)** Bin, Niu; Dejian, Li; Zhangjian, LU; Lixin, Yang; Zhihua, Bai; Longlong, He; Sheng, Liu (August 2020). *Research and design of Bootrom supporting secure boot mode*. 2020 International Symposium on Computer Engineering and Intelligent Communications (ISCEIC). pp. 5–8. [doi](/source/Doi_(identifier)):[10.1109/ISCEIC51027.2020.00009](https://doi.org/10.1109%2FISCEIC51027.2020.00009). [ISBN](/source/ISBN_(identifier)) [978-1-7281-8171-4](https://en.wikipedia.org/wiki/Special:BookSources/978-1-7281-8171-4). [S2CID](/source/S2CID_(identifier)) [231714880](https://api.semanticscholar.org/CorpusID:231714880).

1. ^ [***a***](#cite_ref-FOOTNOTEAlberto_Liberal_De_Los_Ríos201728"Linux_Boot_Process"_5-0) [***b***](#cite_ref-FOOTNOTEAlberto_Liberal_De_Los_Ríos201728"Linux_Boot_Process"_5-1) [***c***](#cite_ref-FOOTNOTEAlberto_Liberal_De_Los_Ríos201728"Linux_Boot_Process"_5-2) [***d***](#cite_ref-FOOTNOTEAlberto_Liberal_De_Los_Ríos201728"Linux_Boot_Process"_5-3) [Alberto Liberal De Los Ríos 2017](#CITEREFAlberto_Liberal_De_Los_Ríos2017), p. 28, "Linux Boot Process".

1. ^ [***a***](#cite_ref-FOOTNOTEM._Tim_Jones2006"Stage_1_boot_loader"_6-0) [***b***](#cite_ref-FOOTNOTEM._Tim_Jones2006"Stage_1_boot_loader"_6-1) [***c***](#cite_ref-FOOTNOTEM._Tim_Jones2006"Stage_1_boot_loader"_6-2) [***d***](#cite_ref-FOOTNOTEM._Tim_Jones2006"Stage_1_boot_loader"_6-3) [***e***](#cite_ref-FOOTNOTEM._Tim_Jones2006"Stage_1_boot_loader"_6-4) [***f***](#cite_ref-FOOTNOTEM._Tim_Jones2006"Stage_1_boot_loader"_6-5) [M. Tim Jones 2006](#CITEREFM._Tim_Jones2006), "Stage 1 boot loader".

1. ^ [***a***](#cite_ref-FOOTNOTEM._Tim_Jones2006"System_startup"_7-0) [***b***](#cite_ref-FOOTNOTEM._Tim_Jones2006"System_startup"_7-1) [***c***](#cite_ref-FOOTNOTEM._Tim_Jones2006"System_startup"_7-2) [***d***](#cite_ref-FOOTNOTEM._Tim_Jones2006"System_startup"_7-3) [***e***](#cite_ref-FOOTNOTEM._Tim_Jones2006"System_startup"_7-4) [M. Tim Jones 2006](#CITEREFM._Tim_Jones2006), "System startup".

1. **[^](#cite_ref-8)** ["EFI stub kernel - Gentoo Wiki"](https://wiki.gentoo.org/wiki/EFI_stub_kernel). *wiki.gentoo.org*. Retrieved 2020-11-02.

1. **[^](#cite_ref-Intel2000_9-0)** Kinney, Michael (1 September 2000). ["Solving BIOS Boot Issues with EFI"](https://web.archive.org/web/20070123141151/http://systems.cs.colorado.edu/Documentation/IntelDataSheets/xscalemagazine.pdf) (PDF). pp. 47–50. Archived from [the original](http://systems.cs.colorado.edu/Documentation/IntelDataSheets/xscalemagazine.pdf) (PDF) on 23 January 2007. Retrieved 14 September 2010.

1. **[^](#cite_ref-ElReg1_10-0)** ["MS denies secure boot will exclude Linux"](https://www.theregister.co.uk/2011/09/23/ms_denies_uefi_lock_in/). The Register. 23 September 2011. Retrieved 24 September 2011.

1. **[^](#cite_ref-11)** ["Using a Signed Bootloader - Arch Wiki"](https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot#Using_a_signed_boot_loader). *wiki.archlinux.org*. Retrieved 2024-12-05.

1. **[^](#cite_ref-FOOTNOTEAlberto_Liberal_De_Los_Ríos201729"Linux_Boot_Process"_12-0)** [Alberto Liberal De Los Ríos 2017](#CITEREFAlberto_Liberal_De_Los_Ríos2017), p. 29, "Linux Boot Process".

1. ^ [***a***](#cite_ref-FOOTNOTEM._Tim_Jones2006"Stage_2_boot_loader"_13-0) [***b***](#cite_ref-FOOTNOTEM._Tim_Jones2006"Stage_2_boot_loader"_13-1) [M. Tim Jones 2006](#CITEREFM._Tim_Jones2006), "Stage 2 boot loader".

1. ^ [***a***](#cite_ref-FOOTNOTEM._Tim_Jones2006"Kernel"_14-0) [***b***](#cite_ref-FOOTNOTEM._Tim_Jones2006"Kernel"_14-1) [***c***](#cite_ref-FOOTNOTEM._Tim_Jones2006"Kernel"_14-2) [***d***](#cite_ref-FOOTNOTEM._Tim_Jones2006"Kernel"_14-3) [***e***](#cite_ref-FOOTNOTEM._Tim_Jones2006"Kernel"_14-4) [***f***](#cite_ref-FOOTNOTEM._Tim_Jones2006"Kernel"_14-5) [***g***](#cite_ref-FOOTNOTEM._Tim_Jones2006"Kernel"_14-6) [***h***](#cite_ref-FOOTNOTEM._Tim_Jones2006"Kernel"_14-7) [***i***](#cite_ref-FOOTNOTEM._Tim_Jones2006"Kernel"_14-8) [***j***](#cite_ref-FOOTNOTEM._Tim_Jones2006"Kernel"_14-9) [***k***](#cite_ref-FOOTNOTEM._Tim_Jones2006"Kernel"_14-10) [***l***](#cite_ref-FOOTNOTEM._Tim_Jones2006"Kernel"_14-11) [***m***](#cite_ref-FOOTNOTEM._Tim_Jones2006"Kernel"_14-12) [***n***](#cite_ref-FOOTNOTEM._Tim_Jones2006"Kernel"_14-13) [M. Tim Jones 2006](#CITEREFM._Tim_Jones2006), "Kernel".

1. ^ [***a***](#cite_ref-redhat_startup_15-0) [***b***](#cite_ref-redhat_startup_15-1) ["Product Documentation"](https://web.archive.org/web/20080830065326/http://www.redhat.com/docs/manuals/linux/RHL-9-Manual/ref-guide/s1-boot-init-shutdown-process.html). Redhat.com. 2013-09-30. Archived from [the original](http://www.redhat.com/docs/manuals/linux/RHL-9-Manual/ref-guide/s1-boot-init-shutdown-process.html) on 2008-08-30. Retrieved 2014-01-22.

1. **[^](#cite_ref-redhat_lilo_16-0)** ["Product Documentation"](http://www.redhat.com/docs/manuals/linux/RHL-9-Manual/ref-guide/s1-grub-lilo.html). Redhat.com. 2013-09-30. Retrieved 2014-01-22.

1. **[^](#cite_ref-FOOTNOTEAlberto_Liberal_De_Los_Ríos201720"Bootloader"_17-0)** [Alberto Liberal De Los Ríos 2017](#CITEREFAlberto_Liberal_De_Los_Ríos2017), p. 20, "Bootloader".

1. **[^](#cite_ref-18)** Corbet, Jonathan (6 November 2002). ["Initramfs arrives"](https://lwn.net/Articles/14776/). Retrieved 14 November 2011.

1. ^ [***a***](#cite_ref-oldfield_19-0) [***b***](#cite_ref-oldfield_19-1) [***c***](#cite_ref-oldfield_19-2) [http://oldfield.wattle.id.au/luv/boot.html](http://oldfield.wattle.id.au/luv/boot.html) Linux Boot Process - by Kim Oldfield (2001)

1. **[^](#cite_ref-FOOTNOTEM._Tim_Jones2006"Init"_20-0)** [M. Tim Jones 2006](#CITEREFM._Tim_Jones2006), "Init".

1. **[^](#cite_ref-p2b_6_21-0)** ["From Power Up To Bash Prompt: Init"](http://users.cecs.anu.edu.au/~okeefe/p2b/power2bash/power2bash-6.html). *users.cecs.anu.edu.au*.

1. **[^](#cite_ref-man_init2_22-0)** ["init"](http://man.he.net/man8/init). *man.he.net*.

1. **[^](#cite_ref-23)** ["systemd README"](http://cgit.freedesktop.org/systemd/systemd/tree/README). *freedesktop.org*. Retrieved 2012-09-09.

### Works cited

- M. Tim Jones (31 May 2006). ["Inside the Linux boot process"](https://web.archive.org/web/20071011074709/http://www.ibm.com/developerworks/library/l-linuxboot/index.html). *IBM*. Archived from [the original](http://www.ibm.com/developerworks/library/l-linuxboot/index.html) on 2007-10-11. Retrieved 2024-01-14.

- Alberto Liberal De Los Ríos (2017). [*Linux Driver Development for Embedded Processors*](https://github.com/ALIBERA/linux_book_2nd_edition) (2nd ed.). Editorial Círculo Rojo; 1st edition (published March 3, 2017). [ISBN](/source/ISBN_(identifier)) [978-8491600190](https://en.wikipedia.org/wiki/Special:BookSources/978-8491600190).

## External links

- [Reading the Linux Kernel Sources](https://en.wikiversity.org/wiki/Linux/Reading_the_Linux_Kernel_Sources), Wikiversity

- [Greg O'Keefe - From Power Up To Bash Prompt](https://web.archive.org/web/20091023232400/http://axiom.anu.edu.au/~okeefe/p2b/power2bash/power2bash.html) at the [Wayback Machine](/source/Wayback_Machine) (archived October 23, 2009)

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

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

v t e Linux kernel Organization Kernel Linux Foundation Linux Mark Institute Linus's law Tanenbaum–Torvalds debate Tux SCO disputes Linaro GNU GPL v2 menuconfig Supported computer architectures Version history Criticism Support Developers The Linux Programming Interface kernel.org LKML Linux conferences Users Linux User Group (LUG) People Werner Almesberger H. Peter Anvin Jens Axboe Moshe Bar Suparna Bhattacharya Andries Brouwer Rémy Card Alan Cox Matthew Garrett Avi Kivity Con Kolivas Greg Kroah-Hartman Robert Love David S. Miller Ingo Molnár Andrew Morton Hans Reiser Rusty Russell Shuah Khan Linus Torvalds Theodore Ts'o Stephen Tweedie Harald Welte Chris Wright Technical Debugging CRIU ftrace kdump Linux kernel oops SystemTap BPF eBPF Startup vmlinux System.map dracut initrd initramfs ABIs Linux Standard Base x32 ABI APIs Kernel System Call Interface POSIX ioctl select open read close sync … Linux-only futex epoll splice dnotify inotify readahead … In-kernel ALSA Crypto API io_uring DRM kernfs Memory barrier New API RCU Video4Linux IIO Userspace Daemons, File systems bpffs configfs devfs devpts debugfs FUSE hugetlbfs pipefs procfs securityfs sockfs sysfs tmpfs systemd udev Kmscon binfmt_misc Wrapper libraries C standard library glibc uClibc Bionic libhybris dietlibc EGLIBC klibc musl Newlib libcgroup libdrm libalsa libevdev libusb liburing Components Kernel modules BlueZ cgroups Console bcache Device mapper dm-cache dm-crypt DRM EDAC evdev Kernel same-page merging (KSM) LIO Framebuffer LVM KMS driver Netfilter Netlink nftables Network scheduler perf SLUB zram zswap Process and I/O schedulers: Brain Fuck Scheduler Completely Fair Scheduler (CFS) Earliest eligible virtual deadline first (EEVDF) Noop scheduler O(n) scheduler O(1) scheduler SCHED_DEADLINE SCHED_FIFO SCHED_RR Security Modules: AppArmor Exec Shield seccomp SELinux Smack Tomoyo Linux Linux PAM Device drivers 802.11 graphics Raw device initramfs KernelCare kexec kGraft kpatch Ksplice Variants Mainline Linux kernel Linux-libre High-performance computing INK Compute Node Linux SLURM Real-time computing RTLinux RTAI Xenomai PREEMPT_RT MMU-less μClinux PSXLinux Virtualization Hypervisor KVM Xen OS-level virtualization Linux-VServer Lguest LXC OpenVZ Other L4Linux User-mode Linux MkLinux coLinux Adoption Range of use Desktop Embedded Gaming Thin client: LTSP Server: LAMP LYME-LYCE Devices Adopters List of Linux adopters Linux portal Free and open-source software portal Category

v t e Linux Linux kernel History Linus's law Linux-libre Booting process Kernel oops Tux more… Controversies Criticism of Linux Criticism of desktop Linux GNU/Linux naming controversy Tanenbaum–Torvalds debate SCO and Linux Distributions General comparison Distributions list Netbook-specific comparison Distributions that run from RAM Lightweight Security-focused operating system Package manager Package format List of software package managers Organizations LinuxChix Linux Counter Linux Documentation Project Linux Foundation Linux Mark Institute Linux User Group (LUG) Adoption Adopters Desktop Embedded Gaming Mobile Range of use State/government-sponsored Linux malware Media DistroWatch Free Software Magazine Full Circle Linux.com Linux Format Linux Gazette Linux Journal Linux Magazine LinuxUser Ubuntu User Linux Outlaws Linux Voice LugRadio LWN.net Phoronix Revolution OS The Code Security certifications CompTIA Linux+ Linux Foundation Red Hat Linux portal Free and open-source software portal Category

v t e Firmware and booting Processes Windows 9x NT Linux Android Booting firmware Types Proprietary firmware Open-source firmware Custom firmware Interfaces UEFI BIOS Video BIOS Open Firmware ACPI MultiProcessor Specification APM Legacy Plug and Play AlphaBIOS SRM SFI Implementations SeaBIOS Award BIOS American Megatrends AMIBIOS AMI Aptio InsydeH2O Phoenix SecureCore UEFI TianoCore EDK II OpenBIOS Coreboot Libreboot LinuxBoot Kickstart Run-Time Abstraction Services Hybrid firmware bootloader Common Firmware Environment Das U-Boot Bootloaders Bootloader unlocking Comparison of bootloaders Implementations Acronis OS Selector Barebox BootManager BootX (Apple) BootX (Linux) GNU GRUB iBoot LILO Limine loadlin MILO NTLDR OpeniBoot Plop Boot Manager RedBoot rEFInd rEFIt SYSLINUX systemd-boot Windows Boot Manager xOSL Yaboot Partition layouts GUID Partition Table Master boot record Apple Partition Map Partitions EFI system partition BIOS boot partition /boot/ Utilities Software flashrom fwupd UEFITool Odin Heimdall Hardware Bus Pirate Raspberry Pi ft2232 Network boot Preboot Execution Environment gPXE iPXE NetBoot Remote Initial Program Load Wake-on-LAN Wake-on-ring ROM variants ROM PROM EPROM EEPROM Related Boot ROM ROM hacking ROM image Execute in place Devicetree Fastboot Instant-on Power-on self-test EDL mode

---
Adapted from the Wikipedia article [Booting process of Linux](https://en.wikipedia.org/wiki/Booting_process_of_Linux) by Wikipedia contributors ([contributor history](https://en.wikipedia.org/wiki/Booting_process_of_Linux?action=history)). Available under [Creative Commons Attribution-ShareAlike 4.0 International](https://creativecommons.org/licenses/by-sa/4.0/). Changes may have been made.