Booting process of Linux

Source: Wikipedia, the free encyclopedia.

The Linux

startup scripts and daemons.[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 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.[2] In personal computer (PC), not only limited to Linux-distro PC, this firmware/program is called BIOS, which is stored in the mainboard.[2] In embedded Linux system, this firmware/program is called boot ROM.[4][5] After being loaded into RAM, 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 then pass control to this kernel image.[2] Second-stage bootloader also performs several operation on the system such as system hardware check, mounting the root device, loading the necessary kernel modules, etc.[2] Finally, the very 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,

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
.

System startup

System startup has different steps based on the hardware that Linux is being booted on, especially between embedded Linux and Linux PC.

systemd-boot as a bootloader.[9][10]

The system startup stage on embedded Linux system starts by executing the firmware/program on the on-chip boot ROM, which is stored on the storage device of the system like USB flash drive, SD card, eMMC, NAND flash, NOR flash, etc.[5] The sequences of system startup in on-chip boot ROM 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, an external bootloader), the on-chip boot ROM sets up the 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.[5] The on-chip boot ROM then loads the U-Boot into RAM for the bootloader stage.[11]

Bootloader stage

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.[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, this active partition 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.[12] Kernel image isn't an executable kernel, but a "compressed file" of the kernel instead, compressed into either zImage or bzImage formats with zlib.[13]

In x86 PC, first- and second-stage bootloaders are combined into the

x64
UEFI systems).

Beside GRUB, there are some more popular bootloaders:

Historical bootloaders, no longer in common use, include:

  • 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-load any other boot-loader
    .
  • GRUB 1 includes logic to read common file systems at run-time in order to access its configuration file.[14] 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.[15]
  • 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 devices. 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

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.[13] It's worth noting that kernel image is self-decompressed, which is a part of the kernel image's routine.[13] For some platforms (like ARM 64-bit), kernel decompression has to be performed by the bootloader instead, like U-Boot.[16]

For details of those steps, take an example with

floating point capabilities, and then switches to non-architecture specific Linux kernel functionality via a call to start_kernel() located in ./init/main.c.[13]

start_kernel()executes a wide range of initialization functions. It sets up

temporary filesystem. Many distributions use dracut
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.[13] The memory used by the temporary root file system is then reclaimed.[clarification needed]

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().[13]

Thus, the kernel stage initializes devices, mounts the root filesystem specified by the bootloader as

Init (/sbin/init) which is designated as the first process run by the system (PID = 1).[18] A message is printed by the kernel upon mounting the file system, and by Init upon starting the Init process.[18]

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

"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

Once the kernel has started, it starts the

user space, for example by checking and mounting file systems, and starting up other processes. The init system is the first daemon to start (during booting) and the last daemon to terminate (during 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:

  • 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.[20] 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.[18] 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.[21]

See also

References

  1. ^ M. Tim Jones 2006, "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."
  2. ^ a b c d e f g M. Tim Jones 2006, "Overview", "Figure 1. The 20,000-foot view of the Linux boot process"
  3. ^ M. Tim Jones 2006, "Linux booting process are grouped into 4 stages, based on IBM source"
  4. S2CID 231714880
    .
  5. ^ a b c d Alberto Liberal De Los Ríos 2017, p. 28, , "Linux Boot Process".
  6. ^ a b c d e f M. Tim Jones 2006, , "Stage 1 boot loader".
  7. ^ a b c d e M. Tim Jones 2006, , "System startup".
  8. ^ "EFI stub kernel - Gentoo Wiki". wiki.gentoo.org. Retrieved 2020-11-02.
  9. ^ Kinney, Michael (1 September 2000). "Solving BIOS Boot Issues with EFI" (PDF). pp. 47–50. Archived from the original (PDF) on 23 January 2007. Retrieved 14 September 2010.
  10. ^ "MS denies secure boot will exclude Linux". The Register. 23 September 2011. Retrieved 24 September 2011.
  11. ^ Alberto Liberal De Los Ríos 2017, p. 29, , "Linux Boot Process".
  12. ^ a b M. Tim Jones 2006, , "Stage 2 boot loader".
  13. ^ a b c d e f g h i j k l m n M. Tim Jones 2006, , "Kernel".
  14. ^ a b "Product Documentation". Redhat.com. 2013-09-30. Retrieved 2014-01-22.
  15. ^ "Product Documentation". Redhat.com. 2013-09-30. Retrieved 2014-01-22.
  16. ^ Alberto Liberal De Los Ríos 2017, p. 20, , "Bootloader".
  17. ^ "Initramfs arrives". Retrieved 14 November 2011.
  18. ^ a b c http://oldfield.wattle.id.au/luv/boot.html Linux Boot Process - by Kim Oldfield (2001)
  19. ^ M. Tim Jones 2006, , "Init".
  20. ^ "From Power Up To Bash Prompt: Init". users.cecs.anu.edu.au.
  21. ^ "init". man.he.net.
  22. ^ "systemd README". freedesktop.org. Retrieved 2012-09-09.

Works cited

External links
Retrieved from "https://en.wikipedia.org/w/index.php?title=Booting_process_of_Linux&oldid=1220042611"