The Linux boot process is the process of initializing the system. It includes everything that happens from the first time the computer is powered on to when the user interface is fully operational.

A full understanding of the steps in the boot process may help you solve the problem and adjust the performance of your computer to your needs.

On the other hand, the boot process can be quite technical, and you can get started using Linux without knowing all the details.

Step 1: BIOS

Starting an x86-based Linux system involves many steps. When the computer is turned on, the basic input/output system (BIOS) initializes the hardware, including the screen and keyboard, and tests main memory. This process is also known as POST (Boot Self Check).

The BIOS software is stored on a ROM chip on the motherboard. Thereafter, the operating system (OS) controls the rest of the boot process.

Master Boot Record (MBR) and Boot Loader

Once the POST is complete, system control is passed from the BIOS to the boot loader. The boot loader is typically stored on one of the hard disks in the system, either in the boot sector (for traditional BIOS/MBR systems) or in the EFI partition (for newer (unified) Extensible Firmware Interface or EFI/UEFI systems). Up to this stage, the machine does not access any bulk storage media. Thereafter, information about the date, time, and most important peripherals is loaded from the CMOS values (which, with battery-powered memory storage technology, can be tracked even when the system is powered down).

There are many boot loaders for Linux; The most common are GRUB (for Grand Unified Boot Loading), Isolinux (for booting from removable media), and DAS U-Boot (for booting on embedded devices/devices). Most Linux boot loaders can provide a user interface for selecting alternatives to boot Linux and even other operating systems that might be installed. When you boot Linux, the boot loader is responsible for loading the kernel image and the initial RAM disk or file system (which contains some of the key files and device drivers needed to boot the system) into memory.

Boot Loader in Action

The boot loader has two different phases:

For systems using the BIOS/MBR approach, the boot loader is located in the first sector of the hard disk, also known as the Master Boot Record (MBR). The size of the MBR is only 512 bytes. At this stage, the boot loader examines the partition table and finds bootable partitions. Once it finds a bootable partition, it searches for a second-stage boot loader, such as GRUB, and loads it into RAM (random access memory). For systems that use the EFI/UEFI method, the UEFI firmware reads its boot manager data to determine which UEFI application to start and from where (that is, from which disk and partition the EFI partition can be found). The firmware then starts the UEFI application, such as GRUB, as defined in the boot entry of the firmware boot manager. This process is more complex, but more general than the old MBR approach.

The second stage boot loader is located under /boot. A boot screen is displayed, allowing us to select the operating system (OS) to boot. After selecting an operating system, the boot loader loads the kernel of the selected operating system into RAM and gives it control. The kernel is almost always compressed, so its first task is to decompress itself. After that, it checks and analyzes the system hardware and initializes any hardware device drivers built into the kernel.

Initial RAM Disk

Initramfs file system image contains all necessary for the execution of mount the root file system correct operating procedures and binary files, such as the file system and large capacity storage controller device driver provide the kernel function, use udev (for user equipment) tools, it is responsible for what are used to determine the device, Locating them requires device drivers that are running correctly, and loading them. Once the root file system is found, check for errors and install.

A mount program indicates that the operating system file system is ready for use and associates it with a specific point (mount point) in the entire hierarchy of the file system. If successful, initramfs will purge from RAM and execute the init program on the root file system (/sbin/init).

Init handles mounting and steering to the final real root file system. If special hardware drivers are required before mass storage can be accessed, they must be in the initramfs image.

Text mode logins

Near the end of the boot process, init initiates some text-mode login prompts. These enable you to type in your user name, then your password, and finally get a command shell. However, if you’re running a system with a graphical login interface, you won’t see this at first.

Generally, the default command shell is bash (GNU Bourne Again Shell), but many other high-level command shells are available. The shell prints a text prompt to indicate that it is ready to accept the command; After the user enters the command and presses Enter, the command is executed and another prompt is displayed when the command is completed.

As you’ll learn in Chapter 7, Command-line operations, you can use the ALT key and a function key to access the terminal on which the command shell runs. Most distributions start with F1 or F2 and have six text terminals and one graphics terminal. In a graphical environment, switching to the text console requires pressing Ctrl-Alt + the appropriate function key (use F7 or F1 to access GUI).

Linux Kernel

The boot loader loads the kernel and RAM-based initial file system (initramfs) into memory, so the kernel can use it directly.

When the kernel is loaded into RAM, it immediately initializes and configures the computer’s memory and configures all hardware connected to the system. This includes all processors, I/O subsystems, storage devices, and so on. The kernel also loads some necessary user-space applications.

/sbin/init and Services

Once the kernel sets up all the hardware and mounts the root file system, the kernel runs /sbin/init. This then becomes the initial process, which then starts other processes to get the system running. Most other processes on the system eventually trace back to init; Exceptions include so-called kernel processes. They are started directly by the kernel and their job is to manage the details of the internal operating system.

In addition to starting the system, init is also responsible for keeping the system running and shutting down the system cleanly. One of its responsibilities is to act as the manager of all non-kernel processes if necessary; It cleans up after completion and restarts the user login service as needed when the user logs in and logs out, as do other back-end system services.

Traditionally, this process startup is done using conventions dating back to the 1980s and System V UNIX versions. This serial process takes the system through a series of runlevels that contain a set of scripts to start and stop the service. Each run level supports a different system run mode. Within each run level, individual services can be set to run or shut down at run time.

However, all recent major distributions no longer adopt this sequential runlevel approach to System initialization, although they generally support the System V convention for compatibility purposes. Next, we’ll discuss the newer methods systemd and Upstart.

Startup Alternatives

Sysvinit sees things as a continuous process, divided into a series of successive stages. Each phase needs to be completed before proceeding to the next. As a result, booting does not easily take advantage of parallel processing that can be done on multiple processors or cores.

In addition, shutdowns and restarts are considered a relatively rare event; It doesn’t matter how long it took. This is no longer true, especially for mobile devices and embedded Linux systems. Some modern methods, such as using containers, may require almost instantaneous startup times. As a result, systems now require faster and enhanced methods. Finally, the old approach required fairly complex startup scripts that were difficult to keep common across distributions, kernel versions, architectures, and system types. The two main alternatives developed are:

Updtart

  • Developed by Ubuntu and first recorded in 2006
  • Used in Fedora 9 (2008) and RHEL 6 and its clones.

systemd

  • Fedora was first adopted (2011)
  • It was adopted by RHEL 7 and SUSE
  • Upstart has been replaced in Ubuntu 16.04

While moving to Systemd is controversial, it has been adopted by major distributions, so we won’t discuss the old System V approach or Upstart, which has become a dead end. Regardless of what one might say about Systemd’s controversies or technical approach, near-universal adoption makes learning how to work on a Linux system easier because there are fewer differences between distributions. Let’s list the features of systemd next.

systemd Features

Systems that use systemd start up faster than those that use the earlier init methods. This is mainly because it replaces a set of serialized steps with a radical parallelization technique that allows multiple services to be started simultaneously.

The complex startup shell scripts were replaced with simpler configuration files that enumerated what must be done before the service was started, how to perform the service startup, and what conditions the service should indicate when the startup is complete. One thing to note is that /sbin/init now only points to /lib/systemd/systemd; Systemd takes over the init process.

A systemd command (systemctl) is used for most basic tasks. While we haven’t discussed working on the command line yet, here’s a brief list of its uses:

  • Start, stop, and restart the service on the current running system (in the case of NFS) :

$ sudo systemctl start|stop|restart nfs.service

  • Enable or disable the system services in the system to start at boot time: $sudo systemctl enable | disable NFS. Service

In most cases, you can omit.service. There are many technical differences with old methods that are beyond the scope of our discussion.

More of Jerry’s original articles can be found on “Wang Zixi “: