Shulou(Shulou.com)06/02 Report--

What exactly is the startup process of the deepin operating system?

I have been pestered by colleagues to ask similar questions before. Faced with such a grand and irrelevant problem, my reply is often "you are too young, now I tell you will still forget, wait for you to work for two years, you do not need me to know." While tapping the keyboard, I admired my ingenuity.

Two years later...

The young man grew up and firmly asked the same question. As soon as I was stunned, a voice kept popping up in my mind, "come out and mix, sooner or later."

Come to think of it, it's time to take out the goods at the bottom of the box. after all, the self-styled title (although I still have a lot of self-styled title: customer service, product manager, R & D project manager, etc.), it seems impossible not to show you two hands.

Overview

On the whole, deepin system startup is mainly divided into several stages, such as hardware power-up, kernel boot, kernel startup, system initialization, graphical interface and so on.

If these stages are divided into two parts, then the first part of the hardware power up, kernel boot, kernel boot is mainly "boot", more inclined to let the kernel can be started. In the second part, the main task of the two stages of system initialization and graphical interface is "initialization (initialize)", because it is not possible for a system to run only with a kernel, and there are a variety of services to manage the system's software and hardware, which is one of the reasons why people usually say that the distribution is not the same concept as the pure GNU/Linux kernel.

Now I would like to talk about my understanding of each stage and some debugging methods from a software developer's point of view.

Power up the hardware

Now that it's the software developer's point of view, this part is basically a black box for me. But in general, we still know that this part is mainly:

Power up the hardware

BIOS/UEFI

Bootloader

The moment you press the power supply, the current will flow to the motherboard and start the BIOS (Basic Input Output System) system.

BIOS system, as its name implies, is the system that most directly deals with hardware. Because there are standards, the basic functions of input and output devices can be used, and some hardware switch configurations can also be operated in BIOS.

In addition, BIOS has two important functions, one is hardware self-test, and the other is load boot. Hardware self-test has nothing to do with being a "half-ass system engineer", so I don't say much about it. The process of loading the boot is actually the familiar MBR and tadpole looking for their mother. Oh, no... I found bootloader in MBR.

For UEFI corresponding to BIOS, there is a difference between them, except for the way you load the boot. For me, it may be that the interface can click with the mouse, um... Ha ha ha.

Here is a joke. When the startup time was optimized in 15.7, the students tested the optimization of the startup time of the system, always saying that the effect was not satisfactory. Let me take a look. It turns out that the startup of their test system starts from hardware startup. I said you started from the kernel boot, and he asked me why. Which is bigger or smaller, optimization time / (BIOS time + GRUB time + kernel time + graphics time) or optimization time / (kernel time + graphics time)? All I can say is that the students in this test are not very good at math.

Kernel boot

After BIOS finds bootloader in MBR (or UEFI in a proprietary storage device on the motherboard) and loads it, bootloader starts loading the Linux kernel and booting.

GRUB boot

The default bootloader for deepin systems is GRUB (GRand Unified Bootloader). In fact, I have always thought that the name is very disgusting, the gods are really heavy taste. GRUB does not need to follow any rules to find the system on the hard disk, but loads the kernel and starts the system according to the startup item in / boot/grub/grub.cfg, and this configuration file is generated and updated when the system installs or manually executes the update-grub command.

The update-grub command is actually a wrapper for grub-mkconfig, which is not available in non-Debian distributions. The main actions that grub-mkconfig will perform are:

1. Load some configuration items in / etc/default/grub. For example, the GRUB_CMDLINE_LINUX_DEFAULT configuration item controls the boot param of Linux.

two。 Execute the scripts in the / etc/grub.d/ directory one by one to generate the final grub.cfg file. For example, we usually see which startup items are output when the update-grub command is executed, which are actually generated by executing os-prober in the / etc/grub.d/03_os-prober script.

Select the startup item in the GRUB interface and press e to edit the startup item. In addition to the normal up and down keys to move the cursor around, you can also use basic Emacs shortcuts:

Next line of Ctrl+N

Previous line of Ctrl+P

Ctrl+B moves one character to the left

Ctrl+F moves one character to the right

Ctrl+A moves the cursor to the beginning of the line

Ctrl+E moves the cursor to the end of the line

After editing, press Ctrl+X to start the system according to the edited results, but the edited results will not be saved, that is, if you need to permanently modify a startup item, you have to modify the grub.cfg file or affect the / etc/default/grub and / etc/grub.d/ script files generated by grub.cfg.

That's all we generally need to know about GRUB. For other uses and knowledge of GRUB, please refer to this article on GRUB and system Boot (https://blog.nanpuyue.com/2017/037.html).

UEFI direct boot

In UEFI mode, in addition to using GRUB to boot the kernel, you can also boot the kernel directly through UEFI (which requires the kernel to enable EFI Stub support). For more information, please see Debian Wiki EFI Stub (https://wiki.debian.org/EFIStub). It is important to note that when creating a startup item using efibootmgr, the-d parameter may be required to specify the device, otherwise it may cause the creation of the startup item to fail.

Kernel boot

In fact, the kernel boot part mainly wants to say initrd. Initrd is a small rootfs that ensures the kernel modules and user-mode tools needed during kernel startup. At the same time, it also needs to prepare for the next phase of "system initialization", that is, preparing the real file system for the init program and starting the init program. The process of starting the kernel with initrd is as follows:

1. Execute the init script (this is not the init program mentioned above, but the file / init in the generated initramfs. The following steps actually take place during the execution of this script)

two。 Parse kernel startup parameters and identify key ones such as debug, boot, break, etc.

3. Execute the script in / scripts/init-top/

4. Load kernel module

5. Execute the script in / scripts/init-premount/

6. Execute the mountroot function in the / scripts/$BOOT script, where the $BOOT parameter is specified by the boot parameter identified in step 2. The options included are local (local startup, default) and nfs (such as PXE startup).

7. Execute the script in / scripts/init-bottom/

8. Execute the init program.

Live system

Step 6 above mentioned that the initramfs-tools package comes with two boot types: local and nfs. When we use the live system, the boot type is actually live. This boot type is mainly supported by the package live-boot.

When starting the live system, the mountroot in / scripts/live invokes the script in the / lib/live/boot/ directory to set up the root file system, including hanging from ISO and setting up overlay, and so on.

Debug

The initrd startup phase supports several special startup parameters to assist debugging:

1.debug will turn on debug mode in the initrd startup script

2.break can say that startup stops at a certain stage, for example, break=premount stops the startup process before the real root file system is mounted, and gives you a busybox environment; the optional break phase can be seen in the / scripts/init script, which are the lines that use maybe_break.

System initialization

From this stage, even if the startup process enters our real system, the init program will start a variety of services to configure the system to ensure that the software and hardware environment can be used normally.

The default init program under the deepin system is systemd, this behemoth is too complex, perhaps in the future to open a hole to write a series to say good. Here is only a brief description of the content related to the system startup process. One is a graph in man bootup:

It basically covers a dependency and basic sequence between the services managed by systemd after systemd takes over the system.

The other is the systemd-analyze command, which gives you a more intuitive view of the startup time and existence time of each systemd service during startup through systemd-analyze plog > bootup.svg.

Graphical interface

The graphical interface stage is the process after the system reaches the graphical environment, which mainly includes:

Display-manager.service starts lightdm

Lightdm starts lightdm-deepin-greeter

The user enters the graphics session after entering the password

Lightdm execution / usr/sbin/deepin-session

/ usr/sbin/deepin-session

Execute the script in / etc/X11/Xsession.d and finally start / usr/bin/startdde

Startdde starts the components of the desktop environment, and the system starts up.

End

Oh, by the way, the story at the beginning of the article is pure fiction, please don't take the right seat.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.