Arch boot process (Français)

From ArchWiki
(Redirected from Chargeur d'amorçage)
É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

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

  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 :
  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 \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.
  4. Le microprogramme lance l'application EFI.

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 microprogramme1 – 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 microprogramme1 – 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 Oui2 Sans chiffrement Sans chiffrement Sans la fonction tail-packing Hérité du microprogramme1 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 Oui2 Peut être «side-loadé»3 Peut être «side-loadé»3 Peut être «side-loadé»3 Hérité du microprogramme1 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 [dead link 2024-03-03 ⓘ] Oui 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 [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).
  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 bootmgfw.efi Windows.
  3. 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

Retrieved from "https://wiki.archlinux.org/index.php?title=Arch_boot_process_(Français)&oldid=802013#Chargeur_d'amorçage"