Introduction to the Linux kernel bootup and startup processes
Hello! So we opened the next, fourth account already, the flow of the course “Linux Administrator” , which confidently occupy its niche next to the devoperskim course. More teachers , more information and booths. Well, as always more interesting information, which was picked up by teachers.
Go.
Have you ever thought about what you need to make your system ready to launch applications?
')
Understanding the process of booting the kernel and running the Linux system is important for configuring Linux and solving startup problems. This article provides an overview of the kernel boot process using the GRUB2 boot loader and launch, performed by the systemd initialization system .
In fact, there are two series of events needed to bring a Linux computer to a working state: kernel boot (boot) and system startup (startup). The kernel boot process begins when the computer is turned on and ends with the initialization of the kernel and the launch of systemd. After this, the system startup process begins, and it is he who brings the Linux computer to a working state.
In general, the process of booting the kernel and running the Linux system is quite simple. It consists of the following steps, which will be described in more detail in the sections below:
Please note that this article deals specifically with GRUB2 and systemd, as they are the kernel loader and initialization program for most distributions. Previously used and other options, and sometimes they can still be found in some distributions.
Kernel boot process
The kernel boot process can be initiated in several ways. First, if the power is turned off, turning on the computer will start the boot process. Secondly, if a local user is already running on the computer, including the root and unprivileged user, the user can programmatically initiate the kernel boot process using the GUI or the command line to reboot. The reboot will first turn off the computer and then restart.
BIOS POST
The first step in the Linux kernel boot process has nothing to do with Linux. This is the hardware part of the process, the same for all operating systems. When power is supplied to the computer, a POST (Power On Self Test) is first launched, which is part of the BIOS (Basic I / O System, Basic Input / Output System).
When IBM released the first personal computer in 1981, the BIOS was designed to initialize hardware components. POST - part of the BIOS, whose task is to ensure the correct operation of computer equipment. If POST fails, the computer may be faulty and the boot process will not continue.
BIOS POST checks the basic performance of the hardware, and then causes an BIOS interrupt - INT 13H, which finds kernel boot sectors on all connected devices with the ability to boot. The first sector found that contains a valid boot record is loaded into RAM, after which control is transferred to the code from the boot sector.
The boot sector is only the first stage. Most Linux distributions use one of three boot loader options: GRUB, GRUB2 and LILO. GRUB2 is the newest and is now used much more often than older versions.
GRUB2
GRUB2 stands for “GRand Unified Bootloader, version 2”, and now it is the main boot loader for most modern Linux distributions. GRUB2 is a program that makes a computer “smart enough” so that it can find the kernel of the operating system and load it into memory. Since speaking and writing just GRUB is easier than GRUB2, in this article I will probably use the term GRUB, but mean GRUB2, unless otherwise specified.
GRUB is compatible with the multiboot specification , which allows it to load different versions of Linux and other operating systems; it can also run a boot record of proprietary operating systems on a chain.
GRUB also allows the user to choose from among several possible kernel loads for any provided Linux distribution. This makes it possible to download the previous version of the kernel if the updated one cannot boot correctly or is incompatible with some important part of the software. GRUB can be configured in the
GRUB1 is now considered obsolete and has been replaced by GRUB2 in most modern distributions, which is its rewritten version. Red Hat-based distributions have upgraded to GRUB2 around Fedora 15 and CentOS / RHEL 7. GRUB2 has the same boot functionality as GRUB1, but in addition provides mainframe-like, pre-OS command-based environments and more flexibility during the pre-boot phase. GRUB2 configuration occurs in / boot / grub2 / grub.cfg.
The primary goal of any GRUB is to load the Linux kernel into memory and run it. Both versions of GRUB work in a similar way in three stages, but in this article I will use GRUB2 to describe the work of GRUB. Configuring GRUB and GRUB2 and using GRUB2 commands is beyond the scope of this article.
Although officially GRUB2 does not use the numbering of stages, for the sake of convenience, I will use it in this article.
Stage 1
As mentioned in the BIOS POST section, at the end of the POST, the BIOS searches for boot records on the attached disks, usually located in the Master Boot Record (MBR), after which it loads the first found record in memory and proceeds to its execution. The bootstrap code, that is, the first stage of GRUB2, takes up very little space, because it must fit into the first 512-byte sector on the hard disk along with the partition table. The total amount of space allocated for the bootstrap code itself in the standard MBR is 446 bytes. The 446-byte file for stage 1 is called boot-img and does not contain a partition table — it is added to the boot entry separately.
Since the boot record should be so small, it is not very smart and does not understand the structure of the file system. Therefore, the sole purpose of stage 1 is to detect and load stage 1.5. To achieve this, stage 1.5 of the GRUB must be located in the space between the boot record itself and the first partition on the disk. After loading stage 1.5 of GRUB into RAM, stage 1 transfers control to stage 1.5.
Stage 1.5
As noted above, step 1.5 of GRUB should be between the boot record and the first partition on the disk. Historically, this space remains unused for technical reasons. The first partition on the hard disk begins in sector 63, and taking into account the MBR in sector 0, 62 512-byte sectors remain - 31744 bytes - in which you can store the core.img file - the 1.5 GRUB stage. The core.img file weighs 25389 bytes, which is enough space for its storage between the MBR and the first partition of the disk.
Since more code can be used for step 1.5, it may be sufficient to contain several common file system drivers, for example, standard EXT and other Linux file systems, FAT and NTFS. core.ing in GRUB2 is more complex and functional than in step 1.5 of GRUB1. This means that stage 2 of GRUB2 may be in the standard EXT file system, but not in a logical volume. Therefore, the standard location for files in phase 2 is the
Note that the / boot directory must be located in a file system that is supported by GRUB. Not all file systems have this support. The task of stage 1.5 is to start searching for the files of stage 2 in the / boot file system with the necessary file system drivers and load the necessary drivers.
Stage 2
All files of stage 2 GRUB are located in the
The objective of stage 2 of GRUB2 is to detect and load the Linux kernel into RAM and transfer control of computer control to the kernel. The kernel and related files are located in the
GRUB2, like GRUB1, supports booting one of several Linux kernels. The Red Hat package management system supports saving multiple kernel versions so that you can load the old kernel version in case of problems with the newest one. By default, GRUB provides a pre-loaded menu of installed kernels, including the rescue option, and after configuration, and the recovery option.
Stage 2 GRUB2 loads the selected kernel into memory and transfers control of computer control to the kernel.
Core
All kernels are in a self-extracting, compressed format to save space. The kernels are located in the
After the selected kernel is loaded into memory and starts to run, first of all, it must extract itself from the compressed version of the file before starting to perform useful work. Once the extraction has taken place, it loads systemd , which is a replacement for the old SysV init program, and passes control to it.
This is the end of the kernel boot process. At this point, the Linux kernel and systemd are running, but they cannot perform any useful tasks for the end user, since there is nothing else to be done.
System startup process
The system startup process follows the kernel boot process and puts the Linux computer into a working state.
systemd
systemd is the parent of all processes responsible for bringing a Linux host to a state of efficient operation. Some of its functions are more extensive than those presented in the old initialization program and need to manage many aspects of the running Linux host, including mounting the file system, running and managing the system services necessary for the productive work of the Linux host. All systemd tasks that are not related to the system startup process are beyond the discussion in this article.
First, systemd mounts filesystems as defined in
Please note that targets and services are systemd units.
Below is Table 1, which compares all systemd targets with old runlevels in SystemV. Systemd aliases are provided by systemd for backward compatibility. Target aliases allow scripts - and many sysadmins, including me - to use such SystemV commands as init3 to change execution levels. Of course, SystemV commands are sent by systemd for interpretation and execution.
Table 1: Comparison of SystemV management levels with systemd targets and some target aliases.
Each target has a set of dependencies described in the configuration file. systemd runs necessary. These dependencies are services required to run a Linux host with a certain level of operation. When all the dependencies listed in the configuration files of the target are loaded and running, the system works at this target level.
systemd also scans the outdated SystemV initialization directories for startup files. If they are, systemd uses them as configuration files to start the services described in the files. Outdated network service is a good example of one that still uses SystemV startup files in Fedora.
Figure 1 below is directly copied from the bootup homepage . It shows the overall sequence of events during systemd startup and the basic requirements for ensuring its success.
Targets sysinit.target and basic.target can be considered checkpoints during system startup. At least one of the goals of systemd is to simultaneously launch system services, there are some services and functional targets that should be launched before others. These control points cannot be passed until all services and targets necessary for them are completed.
Thus, sysinit.target is reached when all units on which it depends are completed. All the following units must be completed: mounting file systems, setting up swap files, starting udev, setting up the initial state of a random number generator, initializing low-level services, setting up cryptographic services if at least one file system is encrypted. In sysinit.target, they can run in parallel.
sysinit.target runs all low-level services and units necessary for minimal system functionality, and those needed to go to basic.target.
Figure 1. Systemd startup map
After executing sysinit.target, systemd launches basic.target, starting with all the units needed to complete it. Basic target provides additional functionality, launching units necessary for the next target, including setting up paths to various executable directories, communication sockets and timers.
Finally, you can start the initialization of user-level tags: multi-user.target or graphical.target. It should be noted that multi-user.target must be achieved before the dependencies of the graphic target are fulfilled.
The underlined targets in Figure 1 are the usual startup targets. The system start is completed upon reaching one of them. If multi-user.target is the default target, then in the console you will see the login in text mode. If graphical.target is set by default, you will see a graphical login; Login screen GUI depends on the screen manager you are using.
Problems
Recently, I had to change the default boot kernel on a Linux computer that used GRUB2. I found that some commands stopped working correctly, or I used them somehow incorrectly. I still do not know what the problem was, it will take more time to research it.
The grub2-set-default command incorrectly configured the default kernel index in the
findings
GRUB2 and the systemd initialization system are key components for the kernel boot phase and system startup of most modern Linux distributions. Despite the controversy, especially around systemd, these two components work well together for booting the kernel and running all the system services needed to create a functional Linux system.
Although I consider GRUB2 and systemd as a whole more complex than their predecessors, they are no more difficult to master and manage. The manuals contain a large amount of information about systemd, and on freedesktop.org the list of its pages is presented in full. For more information, refer to the links below:
That's all. We are waiting for questions and comments here or you can ask them directly in the open lesson .
Go.
Have you ever thought about what you need to make your system ready to launch applications?
')
Understanding the process of booting the kernel and running the Linux system is important for configuring Linux and solving startup problems. This article provides an overview of the kernel boot process using the GRUB2 boot loader and launch, performed by the systemd initialization system .
In fact, there are two series of events needed to bring a Linux computer to a working state: kernel boot (boot) and system startup (startup). The kernel boot process begins when the computer is turned on and ends with the initialization of the kernel and the launch of systemd. After this, the system startup process begins, and it is he who brings the Linux computer to a working state.
In general, the process of booting the kernel and running the Linux system is quite simple. It consists of the following steps, which will be described in more detail in the sections below:
- BIOS POST;
- Kernel load (GRUB2);
- Kernel initialization;
- Running systemd, the parent of all processes.
Please note that this article deals specifically with GRUB2 and systemd, as they are the kernel loader and initialization program for most distributions. Previously used and other options, and sometimes they can still be found in some distributions.
Kernel boot process
The kernel boot process can be initiated in several ways. First, if the power is turned off, turning on the computer will start the boot process. Secondly, if a local user is already running on the computer, including the root and unprivileged user, the user can programmatically initiate the kernel boot process using the GUI or the command line to reboot. The reboot will first turn off the computer and then restart.
BIOS POST
The first step in the Linux kernel boot process has nothing to do with Linux. This is the hardware part of the process, the same for all operating systems. When power is supplied to the computer, a POST (Power On Self Test) is first launched, which is part of the BIOS (Basic I / O System, Basic Input / Output System).
When IBM released the first personal computer in 1981, the BIOS was designed to initialize hardware components. POST - part of the BIOS, whose task is to ensure the correct operation of computer equipment. If POST fails, the computer may be faulty and the boot process will not continue.
BIOS POST checks the basic performance of the hardware, and then causes an BIOS interrupt - INT 13H, which finds kernel boot sectors on all connected devices with the ability to boot. The first sector found that contains a valid boot record is loaded into RAM, after which control is transferred to the code from the boot sector.
The boot sector is only the first stage. Most Linux distributions use one of three boot loader options: GRUB, GRUB2 and LILO. GRUB2 is the newest and is now used much more often than older versions.
GRUB2
GRUB2 stands for “GRand Unified Bootloader, version 2”, and now it is the main boot loader for most modern Linux distributions. GRUB2 is a program that makes a computer “smart enough” so that it can find the kernel of the operating system and load it into memory. Since speaking and writing just GRUB is easier than GRUB2, in this article I will probably use the term GRUB, but mean GRUB2, unless otherwise specified.
GRUB is compatible with the multiboot specification , which allows it to load different versions of Linux and other operating systems; it can also run a boot record of proprietary operating systems on a chain.
GRUB also allows the user to choose from among several possible kernel loads for any provided Linux distribution. This makes it possible to download the previous version of the kernel if the updated one cannot boot correctly or is incompatible with some important part of the software. GRUB can be configured in the
/boot/grub/grub.conf file.GRUB1 is now considered obsolete and has been replaced by GRUB2 in most modern distributions, which is its rewritten version. Red Hat-based distributions have upgraded to GRUB2 around Fedora 15 and CentOS / RHEL 7. GRUB2 has the same boot functionality as GRUB1, but in addition provides mainframe-like, pre-OS command-based environments and more flexibility during the pre-boot phase. GRUB2 configuration occurs in / boot / grub2 / grub.cfg.
The primary goal of any GRUB is to load the Linux kernel into memory and run it. Both versions of GRUB work in a similar way in three stages, but in this article I will use GRUB2 to describe the work of GRUB. Configuring GRUB and GRUB2 and using GRUB2 commands is beyond the scope of this article.
Although officially GRUB2 does not use the numbering of stages, for the sake of convenience, I will use it in this article.
Stage 1
As mentioned in the BIOS POST section, at the end of the POST, the BIOS searches for boot records on the attached disks, usually located in the Master Boot Record (MBR), after which it loads the first found record in memory and proceeds to its execution. The bootstrap code, that is, the first stage of GRUB2, takes up very little space, because it must fit into the first 512-byte sector on the hard disk along with the partition table. The total amount of space allocated for the bootstrap code itself in the standard MBR is 446 bytes. The 446-byte file for stage 1 is called boot-img and does not contain a partition table — it is added to the boot entry separately.
Since the boot record should be so small, it is not very smart and does not understand the structure of the file system. Therefore, the sole purpose of stage 1 is to detect and load stage 1.5. To achieve this, stage 1.5 of the GRUB must be located in the space between the boot record itself and the first partition on the disk. After loading stage 1.5 of GRUB into RAM, stage 1 transfers control to stage 1.5.
Stage 1.5
As noted above, step 1.5 of GRUB should be between the boot record and the first partition on the disk. Historically, this space remains unused for technical reasons. The first partition on the hard disk begins in sector 63, and taking into account the MBR in sector 0, 62 512-byte sectors remain - 31744 bytes - in which you can store the core.img file - the 1.5 GRUB stage. The core.img file weighs 25389 bytes, which is enough space for its storage between the MBR and the first partition of the disk.
Since more code can be used for step 1.5, it may be sufficient to contain several common file system drivers, for example, standard EXT and other Linux file systems, FAT and NTFS. core.ing in GRUB2 is more complex and functional than in step 1.5 of GRUB1. This means that stage 2 of GRUB2 may be in the standard EXT file system, but not in a logical volume. Therefore, the standard location for files in phase 2 is the
/boot file system, or rather /boot/grub2 .Note that the / boot directory must be located in a file system that is supported by GRUB. Not all file systems have this support. The task of stage 1.5 is to start searching for the files of stage 2 in the / boot file system with the necessary file system drivers and load the necessary drivers.
Stage 2
All files of stage 2 GRUB are located in the
/boot/grub2 and several subdirectories. GRUB2 does not have an image file as in steps 1 and 2. Instead, it mostly consists of runtime kernel modules, which are loaded as needed from the /boot/grub2/i386-pc directory.The objective of stage 2 of GRUB2 is to detect and load the Linux kernel into RAM and transfer control of computer control to the kernel. The kernel and related files are located in the
/boot directory. Kernel files are easy to recognize, since their names begin with vmlinuz. You can list the contents of the /boot directory to see the currently installed kernels on your system.GRUB2, like GRUB1, supports booting one of several Linux kernels. The Red Hat package management system supports saving multiple kernel versions so that you can load the old kernel version in case of problems with the newest one. By default, GRUB provides a pre-loaded menu of installed kernels, including the rescue option, and after configuration, and the recovery option.
Stage 2 GRUB2 loads the selected kernel into memory and transfers control of computer control to the kernel.
Core
All kernels are in a self-extracting, compressed format to save space. The kernels are located in the
/boot directory, along with the original RAM disk image and the list of hard disk partitions.After the selected kernel is loaded into memory and starts to run, first of all, it must extract itself from the compressed version of the file before starting to perform useful work. Once the extraction has taken place, it loads systemd , which is a replacement for the old SysV init program, and passes control to it.
This is the end of the kernel boot process. At this point, the Linux kernel and systemd are running, but they cannot perform any useful tasks for the end user, since there is nothing else to be done.
System startup process
The system startup process follows the kernel boot process and puts the Linux computer into a working state.
systemd
systemd is the parent of all processes responsible for bringing a Linux host to a state of efficient operation. Some of its functions are more extensive than those presented in the old initialization program and need to manage many aspects of the running Linux host, including mounting the file system, running and managing the system services necessary for the productive work of the Linux host. All systemd tasks that are not related to the system startup process are beyond the discussion in this article.
First, systemd mounts filesystems as defined in
/etc/fstab , including any swap files and partitions. At this point, it can access configuration files located in /etc , including its own. It uses its own /etc/systemd/system/default.target configuration file to determine the target (target) for which the host should be loaded. The default.target file is just a symlink to the real target file. For a desktop workstation, this is usually graphical.target, equivalent to runlevel 5 in the old SystemV initializer. For the server, the default is likely to be multi-user.target, similar to runlevel 3 in SystemV. emergency.target is similar to single user mode.Please note that targets and services are systemd units.
Below is Table 1, which compares all systemd targets with old runlevels in SystemV. Systemd aliases are provided by systemd for backward compatibility. Target aliases allow scripts - and many sysadmins, including me - to use such SystemV commands as init3 to change execution levels. Of course, SystemV commands are sent by systemd for interpretation and execution.
| Systemv runlevel | Description | ||
|---|---|---|---|
| halt.target | Suspends the system without powering down. | ||
| 0 | poweroff.target | runlevel0.target | Suspends the system and turns off the power |
| S | emergency.target | Single player mode. Services not running; file systems are not mounted. This is the most basic level of operation. For user interaction with the system, only the emergency shell is running in the main console. | |
| one | rescue.target | runlevel1.target | The base system, which includes mounting the file system with the most basic set of services and the rescue shell in the main console. |
| 2 | runlevel2.target | Multi-user mode, without NFS, but all non-GUI services are running. | |
| 3 | multi-user.target | runlevel3.target | All services are running, but only through the command line interface (CLI). |
| four | runlevel4.target | Not used. | |
| five | graphical.target | runlevel5.target | Multiuser mode with GUI. |
| 6 | reboot.target | runlevel6.target | Reboot. |
| default.target | This target always has a symlink with multi-user.target or graphical.target. systemd always uses default.target to start the system. default.target should never be associated with halt.target, poweroff.target or reboot.target. |
Table 1: Comparison of SystemV management levels with systemd targets and some target aliases.
Each target has a set of dependencies described in the configuration file. systemd runs necessary. These dependencies are services required to run a Linux host with a certain level of operation. When all the dependencies listed in the configuration files of the target are loaded and running, the system works at this target level.
systemd also scans the outdated SystemV initialization directories for startup files. If they are, systemd uses them as configuration files to start the services described in the files. Outdated network service is a good example of one that still uses SystemV startup files in Fedora.
Figure 1 below is directly copied from the bootup homepage . It shows the overall sequence of events during systemd startup and the basic requirements for ensuring its success.
Targets sysinit.target and basic.target can be considered checkpoints during system startup. At least one of the goals of systemd is to simultaneously launch system services, there are some services and functional targets that should be launched before others. These control points cannot be passed until all services and targets necessary for them are completed.
Thus, sysinit.target is reached when all units on which it depends are completed. All the following units must be completed: mounting file systems, setting up swap files, starting udev, setting up the initial state of a random number generator, initializing low-level services, setting up cryptographic services if at least one file system is encrypted. In sysinit.target, they can run in parallel.
sysinit.target runs all low-level services and units necessary for minimal system functionality, and those needed to go to basic.target.
Figure 1. Systemd startup map
After executing sysinit.target, systemd launches basic.target, starting with all the units needed to complete it. Basic target provides additional functionality, launching units necessary for the next target, including setting up paths to various executable directories, communication sockets and timers.
Finally, you can start the initialization of user-level tags: multi-user.target or graphical.target. It should be noted that multi-user.target must be achieved before the dependencies of the graphic target are fulfilled.
The underlined targets in Figure 1 are the usual startup targets. The system start is completed upon reaching one of them. If multi-user.target is the default target, then in the console you will see the login in text mode. If graphical.target is set by default, you will see a graphical login; Login screen GUI depends on the screen manager you are using.
Problems
Recently, I had to change the default boot kernel on a Linux computer that used GRUB2. I found that some commands stopped working correctly, or I used them somehow incorrectly. I still do not know what the problem was, it will take more time to research it.
The grub2-set-default command incorrectly configured the default kernel index in the
/etc/default/grub file, so the desired alternative kernel was not loaded. I manually changed /etc/default/grub GRUB_DEFAULT=saved to GRUB_DEFAULT=2 , where 2 is the index of the installed kernel that I wanted to run. Then, I ran the grub2-mkconfig > /boot/grub2/grub.cfg command to create a new grub configuration file. This trick worked, and the alternative core was launched.findings
GRUB2 and the systemd initialization system are key components for the kernel boot phase and system startup of most modern Linux distributions. Despite the controversy, especially around systemd, these two components work well together for booting the kernel and running all the system services needed to create a functional Linux system.
Although I consider GRUB2 and systemd as a whole more complex than their predecessors, they are no more difficult to master and manage. The manuals contain a large amount of information about systemd, and on freedesktop.org the list of its pages is presented in full. For more information, refer to the links below:
- GNU GRUB (Wikipedia)
- GNU GRUB Manua l (GNU.org)
- Master Boot Record (Wikipedia)
- Multiboot specification (Wikipedia)
- systemd (Wikipedia)
- systemd bootup process (Freedesktop.org)
- systemd index of man pages (Freedesktop.org)
That's all. We are waiting for questions and comments here or you can ask them directly in the open lesson .
Source: https://habr.com/ru/post/424761/
All Articles