Table des matières
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.
J’ai fait de mon mieux pour fournir un aperçu rapide des points-clés du système Debian et de sa configuration pour vous servir de référence en me basant sur mes propres connaissances actuelles et antérieures et celles des autres. Comme le système Debian est une cible changeante, la situation sur le système peut avoir changé. Avant de faire une quelconque modification au système, vous devrez vous référer à la dernière documentation de chacun des paquets.
![]() |
Astuce |
---|---|
bootup(7)
describes the system bootup process based on |
![]() |
Astuce |
---|---|
boot(7) describes the system bootup process based on UNIX System V Release 4. (Older Debian) |
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.
![]() |
Note |
---|---|
Pour les plateformes autres que les PC traditionnels tels que les systèmes SUN ou Macintosh, le BIOS sur la ROM et la partition sur le disque peuvent être assez différents (Section 9.5.2, « Configuration de la partition du disque »). Veuillez dans ce cas rechercher ailleurs une documentation spécifique à votre plateforme. |
Le BIOS est la première étape du processus d’amorçage, il est est démarré par l’événement de mise sous tension. Le BIOS, qui est implanté sur une mémoire à lecture seule (ROM), est exécuté depuis l’adresse mémoire particulière à laquelle le pointeur de programme du processeur est initialisé par l’événement de mise sous tension.
Ce BIOS effectue l’initialisation de base du matériel (POST : autotest à la mise sous tension) (« power on self test ») et passe le contrôle du système à l’étape suivante que vous lui indiquez. Le BIOS est habituellement fourni avec le matériel.
L’écran de démarrage du BIOS indique en général quelle(s) touche(s) presser pour entrer dans l’écran de configuration du BIOS afin de paramétrer son comportement. Des touches courantes sont F1, F2, F10, Échap, Ins et Suppr. Si l’écran de démarrage de votre BIOS est caché par un bel écran graphique, vous pouvez essayer de presser différentes touches comme Échap pour désactiver cet écran. Ces touches dépendent beaucoup du matériel.
L’emplacement du matériel et la priorité du code lancé par le BIOS peuvent être définis depuis l’écran de configuration du BIOS. Typiquement, quelques secteurs de début du premier périphérique sélectionné qui est trouvé (disque dur, disquette, CD-ROM, …) sont chargés en mémoire et le code initial est exécuté. Ce code peut être l’un des suivants :
code du chargeur initial ;
code du noyau d’un OS de transition comme FreeDOS ;
code du système d’exploitation cible s’il peut tenir dans cet espace réduit.
Typiquement, le système est amorcé depuis la partition spécifiée du disque dur primaire. Les deux premiers secteurs du disque dur d’un PC traditionnel contiennent l’enregistrement maître d’amorçage (MBR). (« master boot record »). Les informations de partition du disque, y compris la sélection de l’amorçage, sont enregistrées à la fin de ce MBR. Le code initial du chargeur d’amorçage exécuté depuis le BIOS occupe le reste de ce MBR.
Le chargeur initial (« boot loader ») est le deuxième étage du processus d’amorçage, il est lancé depuis le BIOS. Il charge en mémoire l’image du noyau du système et l’image initrd et leur passe le contrôle. Cette image mémoire initiale (« initrd image ») est l’image du système de fichiers racine et sa prise en compte dépend du chargeur initial utilisé.
Le système Debian utilise normalement le noyau de Linux comme noyau de système par défaut. L’image mémoire initiale de l’actuel noyau de Linux 2.6/3.x est techniquement l’image initramfs (initial RAM filesystem : système de fichiers initial en mémoire). L’image initramfs est une archive cpio, compressée à l’aide de gzip, des fichiers du système de fichiers racine.
![]() |
Avertissement |
---|---|
Ce qui précède n'est plus vrai avec les nouveaux multi-segments initramfs. Voir Bug #790100. |
L’installation par défaut du système Debian place, pour la plateforme PC, le premier étage du code du chargeur initial GRUB sur le MBR. Il existe de nombreux chargeurs d’amorçage et d’options de configuration possibles.
Tableau 3.1. Liste des chargeurs initiaux
paquet | popcon | taille | initrd | chargeur initial | description |
---|---|---|---|---|---|
grub-legacy | V:0, I:2 | 710 | Pris en charge | GRUB Legacy | assez intelligent pour comprendre le partitionnement du disque et des systèmes de fichiers tels que vfat, ext3, …. |
grub-pc | V:29, I:849 | 584 | Pris en charge | GRUB 2 | assez intelligent pour comprendre le partitionnement du disque et des systèmes de fichiers tels que vfat, ext4… (défaut). |
grub-rescue-pc | V:0, I:1 | 6294 | Pris en charge | GRUB 2 | images de secours amorçables de GRUB 2 (CD et disquettes) (versions PC/BIOS) |
lilo | V:0, I:3 | 693 | Pris en charge | Lilo | réside sur les emplacements des secteurs de données du disque dur (Ancien). |
syslinux | V:5, I:59 | 299 | Pris en charge | Isolinux | il comprend le système de fichiers ISO9660. C’est utilisé pour le CD d’amorçage. |
syslinux | V:5, I:59 | 299 | Pris en charge | Syslinux | il comprend le système de fichiers MSDOS (FAT). Il est utilisé par la disquette d’amorçage. |
loadlin | V:0, I:1 | 84 | Pris en charge | Loadlin | un nouveau système est démarré depuis le système FreeDOS/MSDOS. |
mbr | V:0, I:10 | 50 | Non pris en charge | MBR par Neil Turton | c’est un logiciel libre qui se substitue au MBR de MSDOS. Il ne comprend que les partitions sur disques. |
![]() |
Avertissement |
---|---|
Do not play with boot loaders without having bootable rescue media (USB
memory stick, CD or floppy) created from images in the
|
Le menu de configuration de GRUB Legacy est situé en
« /boot/grub/menu.lst
». Il peut, par exemple,
avoir les entrées suivantes :
title Debian GNU/Linux root (hd0,2) kernel /vmlinuz root=/dev/hda3 ro initrd /initrd.img
Le fichier de menu de configuration de GRUB 2 est situé en
/boot/grub/grub.cfg
». Il est automatiquement
créé par « /usr/sbin/update-grub
» depuis les
modèles situés dans « /etc/grub.d/*
» et les
paramètres situés en « /etc/default/grub
». Il
peut, par exemple, avoir les entrées suivantes :
menuentry "Debian GNU/Linux" { set root=(hd0,3) linux /vmlinuz root=/dev/hda3 initrd /initrd.img }
Les paramètres de GRUB pour ces exemples ont la signification suivante :
Tableau 3.2. Signification des paramètres de GRUB
Paramètres de GRUB | signification |
---|---|
root
|
utiliser la 3ème partition du premier disque en la désignant par
« (hd0,2) » avec GRUB legacy ou par
« (hd0,3) » dans GRUB 2
|
kernel
|
utiliser le noyau se trouvant en « /vmlinuz »
avec le paramètre du noyau : « root=/dev/hda3
ro »
|
initrd
|
utiliser l’image initrd/initramfs
située en « /initrd.img »
|
![]() |
Note |
---|---|
La valeur du numéro de partition utilisé par le programme « GRUB legacy » est inférieure d’un unité à celle normalement utilisée par le noyau de Linux et les outils utilitaires. Le programme GRUB 2 corrige ce problème. |
![]() |
Astuce |
---|---|
Un UUID (consultez Section 9.5.3, « Accès à une partition en utilisant l’UUID ») peut être utilisé pour
identifier un périphérique spécial par bloc plutôt que son nom de fichier
comme « |
![]() |
Astuce |
---|---|
Si GRUB est le chargeur en usage, le paramètre
de démarrage du noyau est spécifié dans
|
![]() |
Astuce |
---|---|
Vous pouvez démarrer un chargeur d’amorçage depuis un autre chargeur d’amorçage en utilisant une technique appelée chargement en chaîne (« chain loading »). |
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 |
---|---|
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
. You can interrupt this part of the boot process to gain root
shell by providing "break=init
" etc. to the kernel boot
parameter. See the "/init
" script for more break
conditions. This shell environment is sophisticated enough to make a good
inspection of your machine's hardware. Commands available in
this mini-Debian system are stripped down ones and mainly provided by a GNU
tool called
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 |
---|---|
Vous devrez utiliser l’option « |
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
».
Le programme d’initialisation par défaut a subi des changements :
Les versions de Debian antérieures à squeeze
utilisent
une simple initialisation façon SysV.
Debian Wheezy
améliore le système d'init de style SysV en ordonnançant la séquence de démarrage avec les
en-têtes LSB et en lançant l’exécution parallèle de scripts de démarrage.
Debian jessie
change de système d'initialisation par
défaut au profit de systemd pour une
initialisation parallélisée et pilotée par événements.
![]() |
Astuce |
---|---|
Il est possible de vérifier le niveau d’exécution courant de la commande
|
![]() |
Astuce |
---|---|
" |
Tableau 3.3. Liste d’utilitaires d’amorçage initial pour le système Debian :
paquet | popcon | taille | description |
---|---|---|---|
systemd
|
V:703, I:805 | 11933 |
démon
init(8)
basé sur des événements pour la concurrence (remplacement de
sysvinit )
|
systemd-sysv
|
V:684, I:798 | 112 |
the manual pages and links needed for systemd to replace
sysvinit
|
systemd-cron
|
V:0, I:1 | 133 | systemd units to provide cron daemon
and anacron functionality
|
init-system-helpers
|
V:704, I:826 | 129 |
helper tools for switching between sysvinit and
systemd
|
initscripts
|
V:284, I:667 | 205 | scripts pour initialiser et arrêter le système |
sysvinit-core
|
V:13, I:17 | 225 | Utilitaires init(8) de type System-V |
sysv-rc
|
V:477, I:673 | 123 | Mécanisme de changement de niveau de fonctionnement de type System-V |
sysvinit-utils
|
V:791, I:999 | 110 | Utilitaires de type System-V (startpar(8), bootlogd(8), …) |
lsb-base
|
V:877, I:999 | 49 | Linux Standard Base 3.2 fonctionnalité de script d’initialisation |
insserv
|
V:539, I:660 | 140 | outil pour organiser la séquence de démarrage en utilisant les dépendances du script LSB de init.d |
uswsusp
|
V:4, I:11 | 699 | outil permettant d’utiliser le programme de l’espace utilisateur de mise en veille fourni par Linux |
kexec-tools
|
V:1, I:8 | 270 | outil kexec pour le redémarrage par kexec(8) (redémarrage à chaud) |
systemd-bootchart
|
V:0, I:0 | 122 | analyseur des performances du processus de démarrage |
bootchart2
|
V:0, I:1 | 94 | analyseur des performances du processus de démarrage |
pybootchartgui
|
V:0, I:1 | 177 | analyseur des performances du processus de démarrage (virtualisation) |
mingetty
|
V:0, I:3 | 35 | getty(8) en mode console uniquement |
mgetty
|
V:0, I:1 | 301 | modem intelligent (« smart modem ») remplaçant de getty(8) |
![]() |
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. These 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 |
---|---|
Emulated runlevel 2 to 4 are all symlinked to the same
" |
The kernel maintains the system hostname. The system unit started by
systemd-hostnamed.service
sets the system hostname at
boot time to the name stored in "/etc/hostname
". This
file should contain only the system
hostname, not a fully qualified domain name.
Pour afficher le nom de la machine utilisée, lancez la commande hostname (1) sans paramètre.
The mount options of normal disk and network filesystems are set in
"/etc/fstab
". See
fstab(5)
and Section 9.5.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 |
---|---|
Une fois tous les systèmes de fichiers montés, les fichiers temporaires se
trouvant dans « |
Network interfaces are typically initialized in
"networking.service
" for the lo
interface and "NetworkManager.service
" for other
interfaces on modern Debian desktop system under systemd
.
See Chapitre 5, Configuration du réseau for how to configure them.
The kernel error message displayed to the console can be configured by setting its threshold level.
# dmesg -n3
Tableau 3.4. Liste des niveaux d’erreur du noyau
valeur du niveau d’erreur | nom du niveau d’erreur | signification |
---|---|---|
0 | KERN_EMERG | le système est inutilisable |
1 | KERN_ALERT | une action doit être entreprise immédiatement |
2 | KERN_CRIT | conditions critiques |
3 | KERN_ERR | conditions d’erreur |
4 | KERN_WARNING | conditions d’avertissement |
5 | KERN_NOTICE | condition normale mais significative |
6 | KERN_INFO | information |
7 | KERN_DEBUG | messages du niveau de débogage |
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.
Under systemd
, the system logging utility
rsyslogd(8)
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.
Les messages du système peuvent être personnalisés au moyen de
« /etc/default/rsyslog
» et
« /etc/rsyslog.conf
» à la fois pour le fichier journal
et pour l’affichage à l’écran. Consultez
rsyslogd(8)
et
rsyslog.conf(5).
Consultez aussi Section 9.2.2, « Analyseur de journaux ».
The systemd
offers not only init system but also generic
system management functionalities such as journal logging, login management,
time management, network management. etc..
The systemd(1) is managed by several commands:
the
systemctl(1)
command controls the systemd
system and service manager
(CLI),
the
systemsdm(1)
command controls the systemd
system and service manager
(GUI),
the
journalctl(1)
command queries the systemd
journal,
the
loginctl(1)
command controls the systemd
login manager, and
the systemd-analyze(1) analyzes system boot-up performance.
Here are a list of typical systemd
management command
snippets. For the exact meanings, please read the pertinent manpages.
Tableau 3.5. List of typical systemd
management command snippets
Operation | Type | Command snippets |
---|---|---|
GUI for service manager | GUI |
"systemadm " (systemd-ui package)
|
List all target unit configuration | Unit |
"systemctl list-units --type=target "
|
List all service unit configuration | Unit |
"systemctl list-units --type=service "
|
List all unit configuration types | Unit |
"systemctl list-units --type=help "
|
List all socket units in memory | Unit |
"systemctl list-sockets "
|
List all timer units in memory | Unit |
"systemctl list-timers "
|
Start "$unit "
|
Unit |
"systemctl start $unit "
|
Stop "$unit "
|
Unit |
"systemctl stop $unit "
|
Reload service-specific configuration | Unit |
"systemctl reload $unit "
|
Stop and start all "$unit "
|
Unit |
"systemctl restart $unit "
|
Start "$unit " and stop all others
|
Unit |
"systemctl isolate $unit "
|
Switch to "graphical " (GUI system)
|
Unit |
"systemctl isolate graphical "
|
Switch to "multi-user " (CLI system)
|
Unit |
"systemctl isolate multi-user "
|
Switch to "rescue " (single user CLI system)
|
Unit |
"systemctl isolate rescue "
|
Send kill signal to "$unit "
|
Unit |
"systemctl kill $unit "
|
Send kill signal to "$unit "
|
Unit |
"systemctl kill $unit "
|
Check if "$unit " service is active
|
Unit |
"systemctl is-active $unit "
|
Check if "$unit " service is failed
|
Unit |
"systemctl is-failed $unit "
|
Check status of "$unit|$PID|device "
|
Unit |
"systemctl status $unit|$PID|$device "
|
Show properties of "$unit|$job "
|
Unit |
"systemctl show $unit|$job "
|
Reset failed "$unit "
|
Unit |
"systemctl reset-failed $unit"
|
List dependency of all unit services | Unit |
"systemctl list-dependencies --all "
|
List unit files installed on the system | Unit file |
"systemctl list-unit-files "
|
Enable "$unit " (add symlink)
|
Unit file |
"systemctl enable $unit "
|
Disable "$unit " (remove symlink)
|
Unit file |
"systemctl disable $unit "
|
Unmask "$unit " (remove symlink to
"/dev/null ")
|
Unit file |
"systemctl unmask $unit "
|
Mask "$unit " (add symlink to
"/dev/null ")
|
Unit file |
"systemctl mask $unit "
|
Get default-target setting | Unit file |
"systemctl get-default "
|
Set default-target to "graphical " (GUI system)
|
Unit file |
"systemctl set-default graphical "
|
Set default-target to "multi-user " (CLI system)
|
Unit file |
"systemctl set-default multi-user "
|
Show job environment | Environment |
"systemctl show-environment "
|
Set job environment "variable " to
"value "
|
Environment |
"systemctl set-environment variable=value "
|
Unset job environment "variable "
|
Environment |
"systemctl unset-environment variable "
|
Reload all unit files and daemons | Lifecycle |
"systemctl daemon-reload "
|
Shut down the system | System |
"systemctl poweroff "
|
Shut down and reboot the system | System |
"systemctl reboot "
|
Suspend the system | System |
"systemctl suspend "
|
Hibernate the system | System |
"systemctl hibernate "
|
View job log of "$unit "
|
Journal |
"journalctl -u $unit "
|
View job log of "$unit " ("tail -f "
style)
|
Journal |
"journalctl -u $unit -f "
|
Show time spent for each initialization steps | Analyze |
"systemd-analyze time "
|
List of all units by the time to initialize | Analyze |
"systemd-analyze blame "
|
Load and detect errors in "$unit " file
|
Analyze |
"systemd-analyze verify $unit "
|
Track boot process by the cgroups(7) | Cgroup |
"systemd-cgls "
|
Track boot process by the cgroups(7) | Cgroup |
"ps xawf -eo pid,user,cgroup,args "
|
Track boot process by the cgroups(7) | Cgroup |
Read sysfs under
"/sys/fs/cgroup/systemd/ "
|
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.
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 indetd
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
À partir de la version 2.6 du noyau Linux, le système udev fournit un mécanisme de découverte et d’initialisation automatique du matériel (consultez udev(7)). Lors de la découverte de chaque périphérique par le noyau, le système udev lance un processus utilisateur qui utilise les informations provenant du système de fichiers sysfs (consultez Section 1.2.12, « procfs et sysfs »), charge les modules du noyau nécessaires pour sa prise en charge en utilisant le programme modprobe(8) (consultez Section 3.3.1, « Initialisation des modules du noyau ») et crée les nœuds de périphériques en conséquence.
![]() |
Astuce |
---|---|
Si
« |
Le nom des nœuds de périphériques peut être configuré par les fichiers de
règle de udev se trouvant dans
« /etc/udev/rules.d/
». Les règles actuelles
par défaut tendent à créer des noms générés dynamiquement ce qui donne des
noms de périphériques non statiques excepté pour les périphériques cd et
réseau. En ajoutant vos règles personnalisées semblables à celles existantes
pour les périphériques cd et réseau, vous pouvez aussi créer des noms de
périphériques statiques pour les autres périphériques comme les clés
USB. Consultez « Écrire des règles
udev » ou
« /usr/share/doc/udev/writing_udev_rules/index.html
».
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.
![]() |
Astuce |
---|---|
Les nœuds de périphériques n’ont pas besoin d’être statiques pour les règles
de montage se trouvant dans
« |
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.3, « 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 modules TUN/TAP fournissent un périphérique de réseau virtuel point-à-point (TUN) et un périphérique de réseau virtuel Ethernet (TAP) ;
les modules netfilter fournissent les fonctions de pare-feu netfilter (iptables(8), Section 5.10, « Infrastructure de netfilter ») ;
le module du pilote du temporisateur de chien de garde.
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 |
---|---|
Si vous rencontrez des problèmes de chargement de modules lors du chargement
des modules au démarrage ou avec
modprobe(8),
« |
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 |
---|---|
Vous pouvez identifier le matériel exact installé sur votre système. Consultez Section 9.4.3, « Identification du matériel ». |
![]() |
Astuce |
---|---|
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.4.4, « Configuration matérielle ». |
![]() |
Astuce |
---|---|
Vous pouvez probablement ajouter la prise en charge d’un périphérique particulier en recompilant le noyau. Consultez Section 9.9, « Le noyau ». |