Chapitre 3. Initialisation du système

Table des matières

3.1. Aperçu du processus d’amorçage du système
3.1.1. Stage 1: the UEFI
3.1.2. Étage 2 : le chargeur initial
3.1.3. Étage 3 : le système mini-Debian
3.1.4. Étage 4 : le système Debian normal
3.2. Systemd init
3.2.1. Nom de machine (« hostname »)
3.2.2. Le système de fichiers
3.2.3. Initialisation de l’interface réseau
3.3. Messages du noyau
3.4. Messages du système
3.5. System management
3.6. Other system monitors
3.7. Customizing systemd
3.7.1. Socket activation
3.8. Le système udev
3.8.1. Initialisation des modules du noyau

En tant tant qu’administrateur du système, il est sage que vous sachiez en gros comment le système Debian est démarré et configuré. Bien que les détails exacts figurent dans les fichiers sources des paquets installés et dans leurs documentations, c’est un peu pénible pour la plupart d’entre-nous.

Here is a rough overview of the key points of the Debian system initialization. Since the Debian system is a moving target, you should refer to the latest documentation.

Le système informatique subit plusieurs phases de processus d’amorçage (« boot strap process ») depuis l’événement de mise sous tension jusqu’à ce qu’il offre à l’utilisateur un système d’exploitation (OS) pleinement fonctionnel.

Pour des raison de simplicité, je limiterai la discussion à une plateforme PC typique avec l’installation par défaut.

Le processus d’amorçage typique est comme une fusée à quatre étages. Chaque étage de la fusée passe le contrôle du système à l’étage suivant.

Bien entendu, elles peuvent être configurées de manière différente. Par exemple, si vous avez compilé votre propre noyau, vous pouvez sautez l’étape avec le système mini-Debian. Ne supposez donc pas que c’est le cas sur votre système avant de l’avoir vérifié vous-même.

The Unified Extensible Firmware Interface (UEFI) defines a boot manager as part of the UEFI specification. When a computer is powered on, the boot manager is the 1st stage of the boot process which checks the boot configuration and based on its settings, then executes the specified OS boot loader or operating system kernel (usually boot loader). The boot configuration is defined by variables stored in NVRAM, including variables that indicate the file system paths to OS loaders or OS kernels. An EFI system partition (ESP) is a data storage device partition that is used in computers adhering to the UEFI specification. Accessed by the UEFI firmware when a computer is powered up, it stores UEFI applications and the files these applications need to run, including operating system boot loaders. (On the legacy PC system, BIOS stored in the MBR may be used instead.)

The boot loader is the 2nd stage of the boot process which is started by the UEFI. It loads the system kernel image and the initrd image to the memory and hands control over to them. This initrd image is the root filesystem image and its support depends on the bootloader used.

The Debian system normally uses the Linux kernel as the default system kernel. The initrd image for the current 5.x Linux kernel is technically the initramfs (initial RAM filesystem) image.

There are many boot loaders and configuration options available.


[Avertissement] Avertissement

Do not play with boot loaders without having bootable rescue media (USB memory stick, CD or floppy) created from images in the grub-rescue-pc package. It makes you boot your system even without functioning bootloader on the hard disk.

For UEFI system, GRUB2 first reads the ESP partition and uses UUID specified for search.fs_uuid in "/boot/efi/EFI/debian/grub.cfg" to determine the partition of the GRUB2 menu configuration file "/boot/grub/grub.cfg".

The key part of the GRUB2 menu configuration file looks like:

menuentry 'Debian GNU/Linux' ... {
        load_video
        insmod gzio
        insmod part_gpt
        insmod ext2
        search --no-floppy --fs-uuid --set=root fe3e1db5-6454-46d6-a14c-071208ebe4b1
        echo    'Loading Linux 5.10.0-6-amd64 ...'
        linux   /boot/vmlinuz-5.10.0-6-amd64 root=UUID=fe3e1db5-6454-46d6-a14c-071208ebe4b1 ro quiet
        echo    'Loading initial ramdisk ...'
        initrd  /boot/initrd.img-5.10.0-6-amd64
}

For this part of /boot/grub/grub.cfg, this menu entry means the following.


[Astuce] Astuce

You can enable to see kerrnel boot log messages by removing quiet in "/boot/grub/grub.cfg". For the persistent change, please edit "GRUB_CMDLINE_LINUX_DEFAULT="quiet"" line in "/etc/default/grub".

[Astuce] Astuce

You can customize GRUB splash image by setting GRUB_BACKGROUND variable in "/etc/default/grub" pointing to the image file or placing the image file itself in "/boot/grub/".

Consultez « info grub » et grub-install(8).

Le système mini-Debian est la troisième étape du processus d’amorçage lancée par le chargeur d’amorçage. Elle lance le noyau du système avec son système de fichiers racine en mémoire. C’est une étape préparatoire facultative du processus de démarrage.

[Note] Note

Le terme « système mini-Debian » est utilisé par l’auteur pour décrire dans ce document cette 3ème étape du processus de démarrage. On désigne souvent ce système par système initrd. Un système semblable en mémoire est utilisé par l’installateur Debian.

The "/init" program is executed as the first program in this root filesystem on the memory. It is a program which initializes the kernel in user space and hands control over to the next stage. This mini-Debian system offers flexibility to the boot process such as adding kernel modules before the main boot process or mounting the root filesystem as an encrypted one.

  • The "/init" program is a shell script program if initramfs was created by initramfs-tools.

    • Vous pouvez interrompre cette partie du processus d’amorçage afin d’obtenir l’invite de l’interpréteur de l’administrateur en indiquant « break=init » etc. comme paramètre de démarrage du noyau. Consultez le script « /init » pour d’autres conditions d’interruption. Cet environnement d’interpréteur de commandes est suffisamment sophistiqué pour effectuer une bonne inspection du matériel de votre machine.

    • Les commandes disponibles avec ce système mini-Debian sont des commandes réduites et sont principalement fournies par un outil GNU appelé busybox(1).

  • The "/init" program is a binary systemd program if initramfs was created by dracut.

    • Commands available in this mini-Debian system are stripped down systemd(1) environment.

[Attention] Attention

Vous devrez utiliser l’option « -n » de la commande mount lorsque vous êtes sur le système de fichiers en lecture seule.

Le système Debian normal est le quatrième étage du processus d’amorçage, il est lancé par le système mini-Debian. Le noyau du système mini-Debian continue de tourner dans cet environnement. Le système de fichiers racine passe de celui en mémoire à celui, réel, lu sur le disque dur.

Le programme init est le premier à être exécuté, assorti du PID=1, afin qu’il accomplisse son rôle de processus principal du démarrage, qui consiste à commander l’exécution de plusieurs programmes. Le chemin par défaut du programme init est « /sbin/init » mais il peut être modifié en passant un paramètre de démarrage au noyau, comme suit : « init=/chemin/vers/programme_init ».

"/sbin/init" is symlinked to "/lib/systemd/systemd" after Debian 8 Jessie (released in 2015).

[Astuce] Astuce

Il est possible de vérifier le niveau d’exécution courant de la commande init du système avec la commande « ps --pid 1 -f ».


[Astuce] Astuce

Vous trouverez des conseils actualisés pour accélérer le processus de démarrage sur Debian wiki:BootProcessSpeedup.

This section describes how system is started by the systemd(1) program with PID=1 (i.e., init process).

The systemd init process spawns processes in parallel based on the unit configuration files (see systemd.unit(5)) which are written in declarative style instead of SysV-like procedural style.

The spawned processes are placed in individual Linux control groups named after the unit which they belong to in the private systemd hierarchy (see cgroups and Section 4.7.4, « Linux security features »).

The unit configuration files are loaded from a set of paths (see systemd-system.conf(5)) as follows:

  • "/lib/systemd/system": OS default configuration files

  • "/etc/systemd/system": system administrator configuration files which override the OS default configuration files

  • "/run/systemd/system": run-time generated configuration files which override the installed configuration files

Their inter-dependencies are specified by the directives "Wants=", "Requires=", "Before=", "After=", … (see "MAPPING OF UNIT PROPERTIES TO THEIR INVERSES" in systemd.unit(5)). The resource controls are also defined (see systemd.resource-control(5)).

The suffix of the unit configuration file encodes their types as:

  • *.service describes the process controlled and supervised by systemd. See systemd.service(5).

  • *.device describes the device exposed in the sysfs(5) as udev(7) device tree. See systemd.device(5).

  • *.mount describes the file system mount point controlled and supervised by systemd. See systemd.mount(5).

  • *.automount describes the file system auto mount point controlled and supervised by systemd. See systemd.automount(5).

  • *.swap describes the swap device or file controlled and supervised by systemd. See systemd.swap(5).

  • *.path describes the path monitored by systemd for path-based activation. See systemd.path(5).

  • *.socket describes the socket controlled and supervised by systemd for socket-based activation. See systemd.socket(5).

  • *.timer describes the timer controlled and supervised by systemd for timer-based activation. See systemd.timer(5).

  • *.slice manages resources with the cgroups(7). See systemd.slice(5).

  • *.scope is created programmatically using the bus interfaces of systemd to manages a set of system processes. See systemd.scope(5).

  • *.target groups other unit configuration files to create the synchronization point during start-up. See systemd.target(5).

Upon system start up (i.e., init), the systemd process tries to start the "/lib/systemd/system/default.target (normally symlinked to "graphical.target"). First, some special target units (see systemd.special(7)) such as "local-fs.target", "swap.target" and "cryptsetup.target" are pulled in to mount the filesystems. Then, other target units are also pulled in by the target unit dependencies. For details, read bootup(7).

systemd offers backward compatibility features. SysV-style boot scripts in "/etc/init.d/rc[0123456S].d/[KS]name" are still parsed and telinit(8) is translated into systemd unit activation requests.

[Attention] Attention

Emulated runlevel 2 to 4 are all symlinked to the same "multi-user.target".

The mount options of normal disk and network filesystems are set in "/etc/fstab". See fstab(5) and Section 9.6.7, « Optimisation du système de fichiers à l’aide des options de montage ».

The configuration of the encrypted filesystem is set in "/etc/crypttab". See crypttab(5)

The configuration of software RAID with mdadm(8) is set in "/etc/mdadm/mdadm.conf". See mdadm.conf(5).

[Avertissement] Avertissement

Une fois tous les systèmes de fichiers montés, les fichiers temporaires se trouvant dans « /tmp », « /var/lock » et « /var/run » sont effacés lors de chaque démarrage du système.

The kernel error message displayed to the console can be configured by setting its threshold level.

# dmesg -n3

Under systemd, both kernel and system messages are logged by the journal service systemd-journald.service (a.k.a journald) either into a persistent binary data below "/var/log/journal" or into a volatile binary data below "/run/log/journal/". These binary log data are accessed by the journalctl(1) command. For example, you can display log from the last boot as:

$ journalctl -b

Under systemd, the system logging utility rsyslogd(8) may be uninstalled. If it is installed, it changes its behavior to read the volatile binary log data (instead of pre-systemd default "/dev/log") and to create traditional permanent ASCII system log data. This can be customized by "/etc/default/rsyslog" and "/etc/rsyslog.conf" for both the log file and on-screen display. See rsyslogd(8) and rsyslog.conf(5). See also Section 9.3.2, « Analyseur de journaux ».

The systemd offers not only init system but also generic system management operations with the systemctl(1) command.

Tableau 3.6. List of typical systemctl command snippets

Operation Command snippets
List all target unit configuration "systemctl list-units --type=target"
List all service unit configuration "systemctl list-units --type=service"
List all unit configuration types "systemctl list-units --type=help"
List all socket units in memory "systemctl list-sockets"
List all timer units in memory "systemctl list-timers"
Start "$unit" "systemctl start $unit"
Stop "$unit" "systemctl stop $unit"
Reload service-specific configuration "systemctl reload $unit"
Stop and start all "$unit" "systemctl restart $unit"
Start "$unit" and stop all others "systemctl isolate $unit"
Switch to "graphical" (GUI system) "systemctl isolate graphical"
Switch to "multi-user" (CLI system) "systemctl isolate multi-user"
Switch to "rescue" (single user CLI system) "systemctl isolate rescue"
Send kill signal to "$unit" "systemctl kill $unit"
Check if "$unit" service is active "systemctl is-active $unit"
Check if "$unit" service is failed "systemctl is-failed $unit"
Check status of "$unit|$PID|device" "systemctl status $unit|$PID|$device"
Show properties of "$unit|$job" "systemctl show $unit|$job"
Reset failed "$unit" "systemctl reset-failed $unit"
List dependency of all unit services "systemctl list-dependencies --all"
List unit files installed on the system "systemctl list-unit-files"
Enable "$unit" (add symlink) "systemctl enable $unit"
Disable "$unit" (remove symlink) "systemctl disable $unit"
Unmask "$unit" (remove symlink to "/dev/null") "systemctl unmask $unit"
Mask "$unit" (add symlink to "/dev/null") "systemctl mask $unit"
Get default-target setting "systemctl get-default"
Set default-target to "graphical" (GUI system) "systemctl set-default graphical"
Set default-target to "multi-user" (CLI system) "systemctl set-default multi-user"
Show job environment "systemctl show-environment"
Set job environment "variable" to "value" "systemctl set-environment variable=value"
Unset job environment "variable" "systemctl unset-environment variable"
Reload all unit files and daemons "systemctl daemon-reload"
Shut down the system "systemctl poweroff"
Shut down and reboot the system "systemctl reboot"
Suspend the system "systemctl suspend"
Hibernate the system "systemctl hibernate"

Here, "$unit" in the above examples may be a single unit name (suffix such as .service and .target are optional) or, in many cases, multiple unit specifications (shell-style globs "*", "?", "[]" using fnmatch(3) which will be matched against the primary names of all units currently in memory).

System state changing commands in the above examples are typically preceded by the "sudo" to attain the required administrative privilege.

The output of the "systemctl status $unit|$PID|$device" uses color of the dot ("●") to summarize the unit state at a glance.

  • White "●" indicates an "inactive" or "deactivating" state.

  • Red "●" indicates a "failed" or "error" state.

  • Green "●" indicates an "active", "reloading" or "activating" state.

Here are a list of other monitoring command snippets under systemd. Please read the pertinent manpages including cgroups(7).


With default installation, many network services (see Chapitre 6, Applications réseau) are started as daemon processes after network.target at boot time by systemd. The "sshd" is no exception. Let's change this to on-demand start of "sshd" as a customization example.

First, disable system installed service unit.

 $ sudo systemctl stop sshd.service
 $ sudo systemctl mask sshd.service

The on-demand socket activation system of the classic Unix services was through the inetd (or xinetd) superserver. Under systemd, the equivalent can be enabled by adding *.socket and *.service unit configuration files.

sshd.socket for specifying a socket to listen on

[Unit]
Description=SSH Socket for Per-Connection Servers

[Socket]
ListenStream=22
Accept=yes

[Install]
WantedBy=sockets.target

sshd@.service as the matching service file of sshd.socket

[Unit]
Description=SSH Per-Connection Server

[Service]
ExecStart=-/usr/sbin/sshd -i
StandardInput=socket

Then reload.

 $ sudo systemctl daemon-reload

The udev system provides mechanism for the automatic hardware discovery and initialization (see udev(7)) since Linux kernel 2.6. Upon discovery of each device by the kernel, the udev system starts a user process which uses information from the sysfs filesystem (see Section 1.2.12, « procfs et sysfs »), loads required kernel modules supporting it using the modprobe(8) program (see Section 3.8.1, « Initialisation des modules du noyau »), and creates corresponding device nodes.

[Astuce] Astuce

Si « /lib/modules/kernel-version/modules.dep » n’a pas été proprement créé par depmod(8) pour quelque raison, les modules peuvent ne pas être chargés par le système udev comme on le souhaiterait. Lancez « depmod -a » pour corriger ce problème.

Les nœuds de périphériques n’ont pas besoin d’être statiques pour les règles de montage se trouvant dans « /etc/fstab ». Vous pouvez utiliser UUID à la place de leur nom de périphérique tel que« /dev/sda » pour monter les périphériques. Consultez Section 9.6.3, « Accès à une partition en utilisant l’UUID ».

Comme le système udev est une cible quelque peu mouvante, je laisse les détails pour d’autres documentations et je ne donnerai ici qu’un minimum d’informations.

Le programme modprobe(8) nous permet de configurer, depuis un processus utilisateur, un noyau Linux en cours d’exécution en ajoutant ou en supprimant des modules du noyau. Le système udev (consultez Section 3.8, « Le système udev ») en automatise l’appel afin d’aider à l’initialisation du module du noyau.

Il existe des modules non liés au matériel et des modules qui pilotent des éléments matériels particuliers comme les suivants qui demandent à être préchargés en les déclarant dans le fichier « /etc/modules » (consultez modules(5)).

Les fichiers de configuration du programme modprobe(8) se trouvent dans le répertoire « /etc/modprobes.d/ » comme c’est expliqué dans modprobe.conf(5). (Si vous souhaitez que certains modules du noyau ne soient pas chargés automatiquement, vous pouvez les mettre en liste noire dans le fichier« /etc/modprobes.d/blacklist »).

Le fichier « /lib/modules/version/modules.dep » généré par le programme depmod(8) décrit les dépendances des modules utilisés par le programme modprobe(8).

[Note] Note

Si vous rencontrez des problèmes de chargement de modules lors du chargement des modules au démarrage ou avec modprobe(8), « depmod -a » peut résoudre ces problèmes en reconstruisant « modules.dep ».

Le programme modinfo(8) affiche des informations concernant les modules du noyau.

Le programme lsmod(8) formate de manière agréable le contenu de « /proc/modules », affichant quels sont les modules du noyau actuellement chargés.

[Astuce] Astuce

Vous pouvez identifier le matériel exact installé sur votre système. Consultez Section 9.5.3, « Identification du matériel ».

Vous pouvez configurer le matériel au moment du démarrage pour activer les fonctionnalités désirées de ce matériel. Consultez Section 9.5.4, « Configuration matérielle ».

Vous pouvez probablement ajouter la prise en charge d’un périphérique particulier en recompilant le noyau. Consultez Section 9.10, « Le noyau ».