Introduction to the Linux kernel bootup and startup processes
- Transfer
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 that, the system starts up, and it is he who brings the Linux computer to a working state.
In general, the process of loading 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
Booting Process The kernel booting 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. 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 for basic iron performance and then causes an interrupt.BIOS - INT 13H, which finds the 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 the 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 to 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. Setting up GRUB2 occurs in
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 looks 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, step 1.5 of 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 - 1.5 GRUB stage. The core.img file weighs 25389 bytes, which is enough space to store it 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 phase 2 files is the file system
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 a directory
The objective of stage 2 of GRUB2 is to detect and load the Linux kernel into RAM and transfer control of the computer control to the kernel. The kernel and related files are located in the directory
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.
Step 2 GRUB2 loads the selected kernel into memory and transfers control of the computer control to the kernel.
Kernel
All kernels are in a self-extracting, compressed format to save space. The kernels are located in a directory
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 replaces the old SysV init program , and transfers 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.
The system startup process The system startup
process follows the kernel boot process and brings the Linux computer to 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 should 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 scope of the discussion in this article.
First, systemd mounts file systems, 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 SystemV commands like init3 to change execution levels. Of course, SystemV commands are sent by systemd for interpretation and execution.
Table 1: Comparison of SystemV control 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. The legacy 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 the low-level services and units necessary for the minimum functionality of the system, and those that are needed to go to the basic.target.
Figure 1. Systemd startup map
After running 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 is worth noting 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 a 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 file
Conclusions
GRUB2 and the systemd initialization system are key components for the kernel bootup and system startup phases 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 necessary 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, see 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 that, the system starts up, and it is he who brings the Linux computer to a working state.
In general, the process of loading 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
Booting Process The kernel booting 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. 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 for basic iron performance and then causes an interrupt.BIOS - INT 13H, which finds the 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 the 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 to file
/boot/grub/grub.conf. 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. Setting up GRUB2 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 looks 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, step 1.5 of 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 - 1.5 GRUB stage. The core.img file weighs 25389 bytes, which is enough space to store it 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 phase 2 files is the file system
/boot, 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 a directory
/boot/grub2and several subdirectories. In GRUB2, there is no image file as in steps 1 and 2. Instead, it mostly consists of runtime kernel modules, which are loaded from directory as needed /boot/grub2/i386-pc. The objective of stage 2 of GRUB2 is to detect and load the Linux kernel into RAM and transfer control of the computer control to the kernel. The kernel and related files are located in the directory
/boot. Kernel files are easy to recognize, since their names begin with vmlinuz. You can list the contents of a directory /bootto see the current 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.
Step 2 GRUB2 loads the selected kernel into memory and transfers control of the computer control to the kernel.
Kernel
All kernels are in a self-extracting, compressed format to save space. The kernels are located in a directory
/boot, along with the original RAM disk image and a 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 replaces the old SysV init program , and transfers 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.
The system startup process The system startup
process follows the kernel boot process and brings the Linux computer to 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 should 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 scope of the discussion in this article.
First, systemd mounts file systems, as defined in
/etc/fstab, including any swap files and partitions. At this point, he can access configuration files located in /etc, including his own. It uses its own configuration file./etc/systemd/system/default.target, to determine the target (target) for which you want to load the host. 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 SystemV commands like init3 to change execution levels. Of course, SystemV commands are sent by systemd for interpretation and execution.
| 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 control 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. The legacy 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 the low-level services and units necessary for the minimum functionality of the system, and those that are needed to go to the basic.target.
Figure 1. Systemd startup map
After running 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 is worth noting 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 a 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 file
/etc/default/grub, therefore, the desired alternative kernel was not loaded. I manually changed /etc/default/grub GRUB_DEFAULT=savedto GRUB_DEFAULT=2, where 2 is the index of the installed kernel that I wanted to run. Then, I ran the command grub2-mkconfig > /boot/grub2/grub.cfgto create a new grub configuration file. This trick worked, and the alternate kernel was launched. Conclusions
GRUB2 and the systemd initialization system are key components for the kernel bootup and system startup phases 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 necessary 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, see 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 .