Arch boot process (Français)

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.

É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.

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.

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.

Initialisation du système

Avec un BIOS

1. Mise sous tension du système, le power-on self-test (POST) est exécuté.
2. Après le POST, le BIOS initialise le matériel nécessaire au démarrage (disque, contrôleurs de clavier, etc.).
3. 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.
4. 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).
5. Le véritable chargeur d'amorçage (boot loader) est lancé.
6. 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

1. Le système est allumé, le power-on self-test (POST) est exécuté.
2. Après le POST, UEFI initialise le matériel nécessaire au démarrage (disque, contrôleurs de clavier, etc.).
3. 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 . (BOOTIA32.EFI sur les systèmes avec un UEFI IA32 (32 bits) (en)). Voici comment fonctionnent les supports amovibles amorçables UEFI.
4. 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.

«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.

Comparaison des fonctionnalités

Nom	Microprogramme		Table des partitions (en)		Multi-boot	Systèmes de fichier (en)					Notes
	BIOS	UEFI	MBR	GPT		Btrfs	ext4	ReiserFS	VFAT	XFS
EFISTUB									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									Hérité du microprogramme^1		, 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											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							Sans chiffrement
rEFInd					^2	Sans chiffrement	Sans chiffrement		Hérité du microprogramme^1		Prend en charge l'auto-détection des noyaux et des paramètres sans configuration explicite ainsi que fastboot. .
Syslinux							Sans chiffrement				Pas de prise en charge de certaines fonctionnalités de systèmes de fichier. Ne possède pas de pilotes de systèmes de fichiers , ne peut accéder qu'au système de fichiers sur lequel il a été installé.
systemd-boot					^2				Hérité du microprogramme^1		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 .
GRUB Legacy											Abandonné en faveur de GRUB.
							Sans chiffrement				Abandonné en raison de ses limitations (par exemple, avec Btrfs, GPT, RAID).

1. 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 , 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).
2. 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 Windows.
3. systemd-boot prend en charge le «side-loading» des pilotes de système de fichiers UEFI. Ils sont fournis par et doivent être placés dans .

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 (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 ), 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

est la version Arch Linux de la commande getty présente dans les systèmes Unix.  est exécuté une fois pour chaque console virtuelle (typiquement six). Un processus  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  et . Si ceux-ci correspondent, il appelle alors login.

Alternativement, peut lancer un gestionnaire de connexion.

Gestionnaire de connexions

Un Gestionnaire de connexions peut être configuré pour remplacer 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 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 ).

Si la connexion est acceptée, affiche le contenu du fichier /etc/motd juste avant de lancer le shell (voir ).

Shell

Une fois le shell lancé, il va généralement charger un fichier de configuration (typiquement ou ) 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)