Deepin system startup process and introduction of key components [2]

System components are divided into system-level components and user-level components according to the user at startup. System-level components have nothing to do with users and are generally started before the user logs in, while user-level components must be started after the user logs in.

image.png

Debugging

By adding systemd.log_level=debug to the kernel parameters to enable debug mode, adding systemd.debug-shell=1 to the parameters can open a root shell in tty9, which is convenient for debugging.

NetworkManager

Introduction

NetworkManager is the system’s default network manager and is the default choice for most linux distributions. It provides functions such as network device management, network connection management, and VPN management, and provides a wealth of configuration items.

In addition, the dbus interface org.freedesktop.NetworkManager is provided for use by other programs.

Tool

NetworkManager provides the nm-applet program to configure the network in a graphical form. Install the network-manager-applet package to use this command; it also provides nmtui to easily configure the network in the character interface.

NetworkManager also provides a command line tool nmcli to manage and configure the network, see man nmcli for usage.

Configuration files and debugging

Its configuration file is in the /etc/NetworkManager/ directory, and debug mode can be turned on by adding the following to the /etc/NetworkManager/NetworkManager.conf file:

[logging]
level=debug

After the modification is completed, you need to restart the service to make it take effect, command: systemctl restart NetworkManager

Log

journalctl -b 0 -u
``` NetworkManager

## Bluetooth
**Introduction**

The bluetooth service comes from the bluez project, which provides the management and connection functions of bluetooth devices, and interacts with other processes through the dbus interface org.bluez.

**Tool**

The bluetoothctl command is provided for interactive management functions from the command line.

In addition, after installing bluez-utils, you can use more bluetooth tools, such as btmon, which can be used to monitor bluetooth communication packets.

**Configuration files and debugging**

Its configuration file is /etc/bluetooth/main.conf . You can enable debugging mode by modifying the /lib/systemd/system/bluetooth.service file. The modifications are as follows:

ExecStart=/usr/lib/bluetooth/bluetoothd  --> ExecStart=/usr/lib/bluetooth/bluetoothd -d
After the modification is complete, execute the following command to make it take effect:

systemctl daemon-reload systemctl restart bluetooth

**Log**

journalctl -b 0 -u


## PolicyKit
**Introduction**

Polkit is a tool set for application permission control on linux. The application can specify the permission authentication when accessing the application interface according to the rule file provided by polkit, which is often used together with dbus. For example, in the accounts service in dde-system-daemon, the interface for creating users needs to verify the user’s identity. This verification action is implemented through polkit.

**configure**

The path to its configuration file is as follows:

/etc/polkit-1/ /usr/share/polkit-1/

**tool**

It provides a pkexec command that can be added before the executed command to escalate privileges, similar to sudo

**log**

journalctl -b 0 -u polkit

## UPower
**Introduction**

upower is a service that listens and displays powered devices such as power adapters and batteries. Provides the dbus service org.freedesktop.UPower for use by other processes

**tool**

The upower command is provided for use on the command line

**log**

journalctl -b 0 -u


## UDisks2
**Introduction**

udisks2 is an interface for storage device management, which provides functions such as device list, information acquisition, mounting, and unmounting. Serve org.freedesktop.UDisks2 via dbus for use by other processes

**tool**

Provides the udisksctl command line tool to manage and monitor hard disk devices

**Configuration files and debugging**

The configuration file is: /etc/udisks2/udisks2.conf

The debugging method is to add the — debug parameter at startup by modifying /lib/systemd/system/udisks2.service as follows:

ExecStart=/usr/lib/udisks2/udisksd --> ExecStart=/usr/lib/udisks2/udisksd --debug
After the modification is complete, execute the following command to make it take effect:

systemctl daemon-reload systemctl restart udisks2

**log**

journalctl -b 0 -u udisks2


## libinput
**Introduction**

From libinput wiki :

libinput is a library for receiving device input on Wayland and providing input device drivers on X.Org. It provides detection and reception of device events. Process the input device signal. It provides a series of functions for users to use.

On Display Server, libinput provides drivers for input and output devices, so that devices can be used normally, such as mouse, keyboard, touchpad, tablet, etc. However, the corresponding driver package xserver-xorg-input-libinput needs to be installed on xorg, not on wayland.

**tool**

After installing libinput-tools, you can use libinput to monitor and record input and output device events, which can be used for debugging

In addition, after installing xinput on xorg, you can use this command to display and configure the properties of the device on xorg. Currently, the settings of the device in the control center are realized through this principle

**Configuration files and debugging**

On xorg, the configuration files are stored in the /etc/X11/xorg.conf.d/ directory. You can add configuration files to adjust the device according to the rules, such as specifying drivers for the device, setting device properties, etc.

Debugging is mainly done through the previous tools, or viewing the logs of xorg

## lightdm
**Introduction**

lightdm is a lightweight desktop environment display manager that supports multiple display services (xorg and wayland), multi-session (ie desktop environment, such as: dde, gnome, kde, etc.), remote login (XDMCP, VNC, XDMCP) etc, see LightDM Design for more info

**Concept introduction**

greeter : the interface used to display the user’s password, that is, the login interface. On uos, it is lightdm-deepin-greeter , and the available greeter is stored in the /usr/share/xgreeters directory

session : desktop session, that is, the desktop environment, the interface component that should be displayed after the user logs in, dde is on uos, and the available session is stored in the /usr/share/xsessions/ directory

**Configuration files and debugging**

The configuration file is: /etc/lightdm/lightdm.conf , which can configure default greeter , default session , default user , automatic login, startup and exit scripts, session startup and exit scripts, etc.

The debugging method is to add the — debug parameter at startup and modify /lib/systemd/system/lightdm.service to enable it. The changes are as follows:

ExecStart=/usr/sbin/lightdm  -->  ExecStart=/usr/sbin/lightdm --debug
After the modification is complete, execute the following command to make it take effect:

systemctl daemon-reload systemctl restart lightdm

**log**

journalctl -b 0 -u lightdm


/var/log/lightdm/ need root


## xorg/wayland
**Introduction**

xorg is an open source implementation of the X Window System and is a common display service on linux. Most graphics services use xorg to display the interface. wayland is also a display service that aims to replace xorg with a simpler modern windowing system. The reference implementation of the Wayland protocol is called Weston and is developed in C by the Wayland project team.

The biggest difference between Wayland and the X Window System is that it stipulates that the client is responsible for the drawing of window borders and decorations, and the client can draw its own buffer directly in display memory through EGL and some Wayland-specific EGL extensions. The window manager is reduced to the display management service, which is responsible for the calculation and drawing of the programs on the screen. This is simpler and more efficient than the window manager in the X Window System. However, wayland only provides protocols, and the specific implementation requires a mixer to implement.

**Configuration files and debugging**

The /etc/X11/xinit/ directory contains the scripts that should be executed when xorg starts

The /etc/X11/Xsession.d/ directory contains scripts that should be executed when the xorg session starts

Configuration files are stored in the /etc/X11/xorg.conf.d/ directory

The debugging method is to add -logverbose 7 when xorg starts, and modify /etc/lightdm/lightdm.conf in lightmd. The modification content is this line under the [Seat:*] group:

#xserver-command=X  --> xserver-command=X -logverbose 7
**tool**

xrandr ``` Display settings tool

xev
``` x event listener

xset ```x Preference Tool

xprop Window Property Viewer

setxkbmap Keyboard Properties Configuration Tool

drive

The use of hardware devices in xorg also requires drivers, usually graphics card drivers and input and output devices. The common ones are as follows:

intel --> xserver-xorg-video-intel nvidia --> xserver-xorg-video-nouveau/xserver-xorg-video-nvidia ati --> xserver-xorg-video-ati radeon --> xserver-xorg-video-radeon/xserver-xorg-video-amdgpu mouse --> xserver-xorg-input-libinput/xserver-xorg-input-mouse touchpad --> xserver-xorg-input-libinput/xserver-xorg-input-synaptics keyboard --> xserver-xorg-input-libinput/xserver-xorg-input-kbd wacom --> xserver-xorg-input-libinput-wacom Log

/var/log/Xorg.0.log xorg $HOME/.xsession-errors At the same time, the log of the desktop session launcher is recorded, which can usually be used to debug desktop crashes. The above tools and drivers are not available in wayland, nor are the logs. These tools in wayland depend on the interface of the compositor, so usually these tools depend on the compositor and cannot be used alone.

pulseaudio

introduce

pulseaudio=is the default audio management service used in the desktop environment, it is in the kernel audio component(example =ALSA and OSS )It acts as a proxy between the application and the application. It is usually used in conjunction with ALSA and is a user-level component. pulseaudio Provides sound card configuration and information acquisition functions, and supports plug-in functions, such as Bluetooth audio services through plug-ins pulseaudio-bluetooth realized. dde The audio service of the control center is implemented based on the interface of pulseaudio conception

cardSound card device, you can view sound card information through pacmd list-cards profileSound card configuration mode, the available sink、source、port which can be queried in the sound card information sinkAvailable output channels in sound card configuration mode, which can be viewed through pacmd list-sinks sourceInput channels available in sound card configuration mode, which can be viewed pacmd list-sources portport information,about profile andsink/source It is related to the choice of , which can be found in the sound card information. sink-inputThe application in use in the output channel can be viewed through pacmd list-sink-inputs source-outputThe application in use in the input channel, which can be viewed through pacmd list-source-outputs tool

pavucontrol Graphical audio configuration tool, need to install pavucontrol pactl Audio Service Control Tool pacmd Audio Service Configuration Tool Configuration files and debugging

/etc/pulse/ and$HOME/.config/pulse/ In the directory is the location of the configuration file To enable debug mode, you need to modify the daemon.conf ,Modify the following: ; log-level = notice --> log-level = debug Problem debugging Debugging a problem requires bold guesswork, careful verification, and is usually handled in the following order:

Turn on the debug mode of the log Analyze the log to find the guessed suspicious points Perform recurring verification based on suspicious points, or find key log information on the Internet to verify whether any netizens have encountered and solved it When the log and search cannot be found, analyze the code for verification CD-ROM mount failed Mounting using file management fails, but using mount can be successful. The reason is the problem of parameters in udisks2 ( iocharset=utf8 ), which is not supported by the kernel. The kernel needs to enable these supports to take effect.

Through the udisksctl monitor, you can monitor the parameters of the file management when the CD is mounted. Through the wrapper mount command, you can see that the file management is not implemented using this command. After comparison, you can find the difference between the parameters of manual mount and file management. Then manually add the parameters of the failure to test, and find that it will also fail, and then start to remove the parameters one by one for testing, and finally found that it is caused by iocharset, which is related to the kernel through network search.

Final summary

So far, our introduction to the system startup process and key components has been completed. I hope it can bring you knowledge, and he may be able to help you open a new window.

Twitter: twitter.com/linux_deepin Reddit: reddit.com/r/deepin Discord:discord.gg/xjjkcp6H2P