Arch boot process (Français)

État de la traduction:
Cet article est la version francophone de
Arch boot process
. Date de la dernière traduction: 2022-01-19. Vous pouvez aider à synchroniser la traduction s'il y a eu des
changements
dans la version anglaise.
Related articles
Master Boot Record
GUID Partition Table
Unified Extensible Firmware Interface
mkinitcpio (Français)
init
systemd (Français)
fstab (Français)
Autostarting
Afin de démarrer Arch Linux, un
chargeur d'amorçage
qui prends en charge Linux doit être configuré. Le chargeur d'amorçage a pour responsabilité de charger le
noyau Linux
et l'
initramfs
(crée par
mkinitcpio
) avant de lancer le processus de démarrage.
Ce processus est assez différent selon que l'on considère une machine équipée d'un
BIOS
ou d'un
UEFI
. Une description détaillée pour chacun est donnée sur cette page ou les liens y figurant.
Les types de microprogrammes
Lorsque vous allumez matériellement votre ordinateur, c'est le premier programme à s’exécuter. En anglais on parle de
firmware
.
Astuce
On parle rarement de microprogramme (quel que soit son genre) : on dira souvent BIOS ou (U)EFI par abus de langage
BIOS
Un
BIOS
ou Basic Input-Output System (système élémentaire des entrées et sorties) est dans la plupart des cas stocké dans une mémoire flash située dans la carte mère elle-même indépendamment du stockage du système. Créé à l'origine pour l'
IBM PC
afin de prendre en charge l'initialisation du matériel et le processus de démarrage, il a été progressivement remplacé depuis 2010 par l'
UEFI
qui ne souffre pas des mêmes limitations techniques.
UEFI
L'
UEFI
(qui peut se traduire par
Interface Matérielle Extensible Unifiée
) prends en charge autant la lecture de la table de partition que que la lecture des partitions, mais il n’exécute pas le code contenu dans le
MBR
(que celui-ci soit présent ou non), à la place le démarrage repose sur la présence d'«entrées de démarrage» inscrites dans la
NVRAM
.
Les spécifications de l'UEFI imposent la prise en charge des formats de partitions
FAT12
,
FAT16
, et
FAT32
(voir
UEFI specification version 2.8, section 13.3.1.1
), mais les fabricants peuvent individuellement ajouter la prise en charge de n'importe quel système de fichier; par exemple, les ordinateurs Apple prennent en charge (et utilisent par défaut) leur propre format de partition, le
HFS+
. Certaines implémentations prennent  également en charge le format
ISO-9660
pour le démarrage depuis un cd-rom.
L'UEFI lance des applications EFI, tels des gestionnaires de démarrage, des shells UEFI, etc. Ces applications sont stockées comme de simples fichiers sur la partition
ESP
. Chaque constructeur peut ainsi stocker ses propres fichiers dans cette partition à l'intérieur du répertoire
/EFI/
vendor_name
. Ces applications peuvent être lancées en ajoutant une entrée de démarrage dans  la NVRAM, ou depuis un shell UEFI.
L'UEFI permet un démarrage en «mode de compatibilité» ou
legacy
BIOS
booting
au moyen du
Compatibility Support Module (CSM)
. Si le CSM est activé dans l'interface de réglage de l'UEFI, ce dernier générera des entrées de démarrage pour chacun des disques. Et, si une entrée de démarrage CSM est choisie, l'UEFI tentera de démarrer le code de démarrage du MBR de ce disque.
Note
Intel abandonne progressivement la prise en charge du CSM, il ne sera peut-être plus possible de s'appuyer sur cette fonctionnalité à l'avenir.
[1]
Initialisation du système
Avec un BIOS
Mise sous tension du système, le
power-on self-test (POST)
est exécuté.
Après le POST, le BIOS initialise le matériel nécessaire au démarrage (disque, contrôleurs de clavier, etc.).
Le BIOS lance les 440 premiers octets (
la zone de code d'amorçage du Master Boot Record
) du premier disque dans l'ordre des disques du BIOS.
La première étape du code d'amorçage du chargeur d'amorçage dans le MBR lance ensuite son code de deuxième étape (le cas échéant) à partir de l'un ou l'autre des éléments suivants :
les prochains secteurs du disque après le MBR, c'est-à-dire ce qu'on appelle l'espace post-MBR (uniquement sur une table de partition MBR).
d'une partition ou d'un disque sans partition
volume boot record (VBR) (en)
.
la
partition de démarrage du BIOS
. (
GRUB
sur BIOS/GPT uniquement).
Le véritable
chargeur d'amorçage (
boot loader
)
est lancé.
Le chargeur d'amorçage charge ensuite un système d'exploitation, soit par chargement en chaîne, soit par chargement direct du noyau du système d'exploitation.
Avec un UEFI
Le système est allumé, le
power-on self-test (POST)
est exécuté.
Après le POST, UEFI initialise le matériel nécessaire au démarrage (disque, contrôleurs de clavier, etc.).
Le microprogramme lit les entrées de démarrage dans la NVRAM pour déterminer quelle application EFI lancer et à partir de quel endroit (par exemple, à partir de quel disque et de quelle partition).
Une entrée de démarrage peut simplement être un disque. Dans ce cas, le microprogramme recherche une
partition système EFI
sur ce disque et tente de trouver une application EFI dans le chemin de démarrage de secours
\EFI\BOOT\BOOTx64.EFI
. (
BOOTIA32.EFI
sur les
systèmes avec un UEFI IA32 (32 bits) (en)
). Voici comment fonctionnent les supports amovibles amorçables UEFI.
Le microprogramme lance l'application EFI.
Cela peut être un
chargeur d'amorçage
ou le
noyau
Arch lui-même en utilisant
EFISTUB
.
Il peut s'agir d'une autre application EFI comme le [[
shell UEFI
ou un
gestionnaire de démarrage (
boot manager
)
comme
systemd-boot
ou
rEFInd
.
Si
Secure Boot
est activé, le processus de démarrage vérifiera l'authenticité du binaire EFI par signature.
Note
Certains systèmes UEFI ne peuvent démarrer qu'à partir du chemin d'amorçage de secours.
«Multi-boot» avec un UEFI
Puisque chaque système d'exploitation ou fournisseur peut maintenir ses propres fichiers dans la
partition système EFI
sans affecter l'autre, le démarrage multiple en utilisant UEFI est juste une question de lancement d'une application EFI différente correspondant au chargeur d'amorçage du système d'exploitation particulier. Cela supprime la nécessité de s'appuyer sur les mécanismes de
chain loading (en)
d'un
chargeur d'amorçage
pour charger un autre OS.
Consultez également
«Dual boot» avec Windows
.
Chargeur d'amorçage
Un chargeur d'amorçage est un logiciel lancé par le microprogramme (
BIOS
ou
UEFI
). Il est responsable du chargement du noyau avec les
paramètres du noyau (en)
souhaités et toute image initramfs externe. Dans le cas de l'UEFI, le noyau lui-même peut être lancé directement par l'UEFI à l'aide du
EFI boot stub
. Un chargeur d'amorçage ou un gestionnaire d'amorçage séparé peut toujours être utilisé pour modifier les paramètres du noyau avant le démarrage.
Attention
Un chargeur d'amorçage doit être capable d'accéder au noyau et aux images initramfs, sinon le système ne démarrera pas. Ainsi, dans une configuration typique, il doit pouvoir accéder à
/boot
. Cela signifie qu'il doit prendre en charge tout ce qui commence par les périphériques blocs, les périphériques blocs empilés (LVM, RAID, dm-crypt, LUKS, etc.) et se termine par le système de fichiers sur lequel résident le(s) noyau(x) et les images initramfs.
Note
Le chargement des mises à jour
Microcode
nécessite des ajustements dans la configuration du chargeur d'amorçage.
[2]
Comparaison des fonctionnalités
Note
Comme GPT fait partie de la spécification UEFI, tous les chargeurs d'amorçage UEFI prennent en charge les disques GPT. GPT sur les systèmes BIOS est possible, en utilisant soit le "démarrage hybride" avec
MBR Hybrid
, soit le nouveau protocole
GPT-seul
. Ce protocole peut cependant causer des problèmes avec certaines implémentations BIOS ; consultez
rodsbooks
pour plus de détails.
Le chiffrement mentionné dans la prise en charge du système de fichiers est
le chiffrement au niveau système de fichier (en)
, il n'a aucun rapport avec
chiffrement au niveau du disque
.
Nom
Microprogramme
Table des partitions (en)
Multi-boot
Systèmes de fichier (en)
Notes
BIOS
UEFI
MBR
GPT
Btrfs
ext4
ReiserFS
VFAT
XFS
EFISTUB
–
Oui
Oui
Oui
–
–
–
–
Hérité du microprogramme
1
–
Le noyau est un exécutable EFI valide qui peut être chargé directement à partir du microprogramme UEFI en utilisant
efibootmgr
ou un autre chargeur d'amorçage.
Unified kernel image
–
Oui
Oui
Oui
–
–
–
–
Hérité du microprogramme
1
–
systemd-stub(7)
, un noyau, initramfs et la ligne de commande du noyau emballés dans un exécutable EFI pour être chargés directement à partir du firmware UEFI ou d'un autre chargeur d'amorçage.
GRUB
Oui
Oui
Oui
Oui
Oui
Oui
Oui
Oui
Oui
Oui
La configuration BIOS/GPT nécessite une
partition de démarrage BIOS
.
Prise en charge de RAID, LUKS1 et LVM (mais pas les volumes
thin provisioned
).
Limine
Oui
Oui
Oui
Oui
Oui
Non
Sans chiffrement
Non
Oui
Non
rEFInd
Non
Oui
Oui
Oui
Oui
2
Sans chiffrement
Sans chiffrement
Sans la fonction
tail-packing
Hérité du microprogramme
1
Non
Prend en charge l'auto-détection des noyaux et des paramètres sans configuration explicite ainsi que
fastboot
.
[3]
.
Syslinux
Oui
Partielle
Oui
Oui
Partielle
Sans: volumes sur plusieurs périphériques, compression, chiffrement
Sans chiffrement
Non
Oui
MBR uniquement; sans
sparse inodes
Pas de prise en charge de certaines fonctionnalités de
systèmes de fichier
.
[4]
Ne possède pas de pilotes de systèmes de fichiers
[5]
, ne peut accéder qu'au système de fichiers sur lequel il a été installé.
systemd-boot
Non
Oui
Installation manuelle uniquement
Oui
Oui
2
Peut être «side-loadé»
3
Peut être «side-loadé»
3
Peut être «side-loadé»
3
Hérité du microprogramme
1
Peut être «side-loadé»
3
Impossible de lancer des binaires à partir de partitions autres que l'
ESP
ou la partition de chargeur d'amorçage étendu (partition XBOOTLDR).
Prise en charge la détection automatique des
images de noyau unifié
lorsqu'elles sont placées dans
esp
/EFI/Linux
.
GRUB Legacy
Oui
Non
Oui
Non
Oui
Non
Non
Oui
Oui
XFS v4 uniquement
Abandonné
en faveur de
GRUB
.
LILO
Oui
Non
Oui
Non
Oui
Non
Sans chiffrement
Oui
Oui
Oui
Abandonné
en raison de ses limitations (par exemple, avec Btrfs, GPT, RAID).
La prise en charge du système de fichiers est héritée du microprogramme. La spécification UEFI impose la prise en charge des systèmes de fichiers FAT12, FAT16 et FAT32
[6]
, mais les fournisseurs peuvent ajouter en option la prise en charge de systèmes de fichiers supplémentaires ; par exemple, le microprogramme des
Macs
d'Apple prend en charge le système de fichiers HFS+. Si le microprogramme fournit une interface pour le chargement de
drivers UEFI
au démarrage, la prise en charge de systèmes de fichiers supplémentaires peut être ajouté en chargeant des pilotes de systèmes de fichiers (acquis indépendamment).
Un
gestionnaire d'amorçage
. Il peut seulement lancer d'autres applications EFI, par exemple, des images de noyau Linux construites avec
CONFIG_EFI_STUB=y
et
bootmgfw.efi
Windows.
systemd-boot prend en charge le «side-loading» des pilotes de
système de fichiers UEFI
. Ils sont fournis par
efifs
et doivent être placés dans
esp
/EFI/systemd/drivers/
.
Consultez également
La comparaison des chargeurs d'amorçage (Wikipedia en)
.
Le Noyau
Le noyau
(ou kernel)
est l'élément central d'un système d'exploitation. Il repose sur des interactions de
bas-niveau
entre le matériel et les programmes qui en font usage. On parle de code exécuté à l’intérieur du
kernelspace
par opposition à du code exécuté depuis le
userspace
.
Pour faire un usage efficace du processeur, le noyau utilise un ordonnanceur
(scheduler)
pour prioriser chacune des tâches qu'il doit accomplir à n'importe quel instant, créant ainsi l'illusion que celles-ci sont exécutées simultanément.
Bien que l'on parle parfois de noyau «monolithique», celui-ci fait néanmoins usage de
«modules»
qui chargent
et éventuellement déchargent
certaines fonctionnalités.
Initramfs
Après que le chargeur d'amorçage a chargé le noyau et un éventuel
initramfs
, il exécute le  noyau Arch qui utilise un (éventuel second)
initramfs
(INITial RAM FileSystem). Il s'agit d'une image de système de fichiers compressée. Le noyau la décompresse et la monte comme système de fichiers racine, dit
rootfs
(initial root filesystem, typiquement un
ramfs
).
Le premier initramfs est celui embarqué dans le noyau lors de la compilation de ce dernier, ensuite différents fichiers d'initramfs sont extraits. Chaque fichier contenu dans ces initramfs extérieur vient écraser les fichiers de même nom déjà présents dans l'initramfs embarquée. Le noyau exécute ensuite
/init
(présent dans le rootfs) comme premier processus utilisateur. On parle à ce stade  de
early userspace
.
Arch Linux utilise une archive vide pour l'initramfs du noyau (ce qui est la valeur par défaut lors de la compilation de Linux). Voyez
mkinitcpio
pour plus de détails.
Le but de l'initramfs est d'amorcer le système jusqu'au point où il peut accéder au système de fichiers racine (consultez
FHS
pour plus de détails). Cela signifie que tous les modules requis pour les périphériques tels que IDE, SCSI, SATA, USB/FW (si l'on démarre à partir d'un disque externe) doivent pouvoir être chargés à partir de l'initramfs s'ils ne sont pas intégrés au noyau. Une fois les modules appropriés chargés (soit explicitement via un programme ou un script, soit implicitement via
udev
), le processus de démarrage se poursuit. Pour cette raison, l'initramfs ne doit contenir que les modules nécessaires pour accéder au système de fichiers racine ; il n'a pas besoin de contenir tous les modules que l'on pourrait vouloir utiliser. La majorité des modules seront chargés plus tard par udev, pendant le processus d'init.
Init
À la fin de l'
early userspace
, la partition racine définie par le paramètre
root=
de la «cmdline» (ligne des paramètres) du noyau est montée comme racine / en remplacement de l'
Initramfs
.
Le programme
/sbin/init
est alors lancé (remplaçant
/init
), sauf si un autre est spécifié dans la
cmdline
à l'aide du paramètre
init=
.
Archlinux utilise
systemd
comme système d'init.
agetty
agetty
est la version Arch Linux de la commande
getty
présente dans les systèmes Unix.
agetty
est exécuté une fois pour chaque console virtuelle (typiquement six). Un processus
agetty
a pour fonction de protéger la ligne de transmission vers un terminal vis-à-vis des intrusions: il initialise chacune des consoles et réclame à l'utilisateur de s’authentifier. Une fois le nom d'utilisateur et le mot de passe fournis, il les compare aux fichiers
/etc/passwd
et
/etc/shadow
. Si ceux-ci correspondent, il appelle alors
login
.
Alternativement,
agetty
peut lancer un gestionnaire de connexion.
Gestionnaire de connexions
Un
Gestionnaire de connexions
peut être configuré pour remplacer
agetty
lors de la connexion au système.
Afin de démarrer une interface graphique, il vous faudra activer le
service
correspondant à votre gestionnaire de connexion.
Login
Le programme
login
démarre une session utilisateur en définissant les variables d'environnements puis en lançant le shell par défaut de l'utilisateur (tel que défini dans
/etc/passwd
).
Si la connexion est acceptée,
login
affiche le contenu du fichier
/etc/motd
juste avant de lancer le shell (voir
motd(5)
).
Shell
Une fois le shell lancé, il va généralement charger un fichier de configuration (typiquement
~/.bashrc
ou
~/.zshrc
) avant de présenter la première invite de commande. On peut utiliser ces fichier pour lancer un compositeur
wayland
ou
startx
pour démarrer un environnement graphique.
GUI, xinit ou wayland
xinit
exécute le fichier de configuration d'exécution
xinitrc
de l'utilisateur, qui démarre normalement un
gestionnaire de fenêtres
. Lorsque l'utilisateur a terminé et quitte le gestionnaire de fenêtres,
xinit
,
startx
, l'interpréteur de commandes et la connexion se terminent dans cet ordre, retournant à
agetty
.
Voir aussi
Les débuts de l'espace utilisateur dans Arch Linux
(en anglais)
Inside the Linux boot process
(en anglais)
Wikipedia:Linux startup process
(en anglais)
Wikipedia:fr:initrd
Boot Linux Grub Into Single User Mode
(en anglais)
NeoSmart : Le processus de démarrage BIOS/MBR
(en anglais)
Le coin des néophytes du noyau : initrd et initramfs
(en anglais)
Rod Smith - Gérer les chargeurs d'amorçage EFI pour Linux
(en anglais)