Processus de boot

De ArchwikiFR
Révision datée du 23 mars 2020 à 10:05 par Nophke (discussion | contributions) (Le Noyau : Ajout d'un référence au système de modules, et ajout d'un lien interne vers page [[Kernel module)
(diff) ← Version précédente | Voir la version actuelle (diff) | Version suivante → (diff)


Afin de démarrer Arch Linux, un chargeur de démarrage qui supporte Linux doit être configuré. Le chargeur de démarrage 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.

Le Micrologiciel

Lorsque matériellement vous allumez votre ordinateur, c'est le premier programme à s’exécuter. En anglais on parle de firmware.

Astuce : On parle rarement de micro-logiciel, (et quelque soit son genre), on dira souvent BIOS par abus de langage

BIOS

( → Basic Input Output System / Le système élémentaire des entrées et sorties )

Les instructions de démarrage sont inscrites à l'intérieur du micro-logiciel qui est lui même inscrit sur une mémoire flash intégrée à la carte mère. Le BIOS va rechercher sur le disque que l'on lui indiquera les instructions nécessaires à la finalisation du démarrage toujours au même endroit du disque que l'on appelle le MBR (le bios ne sait pas lire la table des partitions).

UEFI

( → Unified Extensible Firmware Interface / Interface Matérielle Extensible Unifiée).

L'UEFI supporte 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 le support 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 le support de n'importe quel type de format; par exemple, les ordinateurs Apple supportent (et utilisent par défaut) leur propre format de partition, le HFS+. Certaines implémentations supportent également 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 dossier /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 supporte 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.

Chargeur de Démarrage

Le chargeur de démarrage (ou bootloader) est un programme démarré par le micro-logiciel. Ce dernier aura la responsabilité de charger le noyau Linux avec les paramètres désirés et l'initramfs en fonction des fichiers de configuration.

Dans le cas de l'UEFI, le noyau peut être directement démarré par l'UEFI depuis la partition ESP. Un chargeur de démarrage peut toutefois être installé à coté pour éditer plus facilement les paramètres du noyau.

Note : La mise à jour du microcode nécessite des ajustements dans la configuration du chargeur de démarrage. Voir: [1]

Si l'entrée Arch Linux est sélectionnée, il va donc copier en mémoire l'image du noyau (/boot/vmlinuz-linux), ainsi que l'initramfs (/boot/initramfs-linux.img). Le noyau est ensuite exécuté.

Pour une comparaison des fonctionnalités de chacun des différents chargeurs de démarrage , voir paragraphe du wiki officiel.

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 l'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 de démarrage 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 uniquement d'emmenner le système au point il pourra monter la partition racine du système de fichier. En effet, le noyau Arch officiel ne contient pas tous les pilotes (pour éviter d'être exagérément gros). L'initramfs contient un shell et une série de scripts qui permettent de charger les modules nécessaires pour reconnaître le périphérique contenant la partition racine, puis son système de fichiers. Il y a en général les pilotes SATA ou IDE, ext4

Ainsi vous n'avez besoin de rajouter de module à l'initramfs que ci celui-ci n'est pas inclus en dur dans le noyau ou absent de l'initramfs de base car l'initramfs n'a pas besoin de contenir tous les modules qui pourraient être utiles à un moment ou un autre sur une machine. La majorité des modules seront chargés plus tard lors du démarrage d'init.

Pour cette raison, cette image est générée sous Arch à chaque mise à jour du noyau par mkinitcpio. Aussi, si vous compilez votre propre noyau, vous pouvez vous en passer et compiler ces divers modules en dur (c'est-à-dire dans l'image du noyau, vmlinuz-linux).

Ensuite, une fois les bons modules chargés (soit explicitement via un programme ou un script, ou implicitement via udev), la partition racine définie par le paramètre root= de la cmdline du noyau est montée comme racine /, généralement en lecture seule (si le paramètre ro a été passé sur la cmdline par le chargeur de démarrage).

Init

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. La dernière action (par défaut) de systemd sera de lancer le programme agetty. (par le biais de /etc/systemd/system/getty.target.wants/getty@tty1.service qui permet d'attacher une console virtuelle.

agetty lance alors login, qui propose une invite de login et mot de passe, pour ouvrir un shell pour l'utilisateur de votre choix.

getty

getty est éxécuté une fois pour chaque console virtuelle (typiquement six). Getty initialise chacune de ces console et réclame à l'utilisateur de s’authentifier. Une fois le nom d'utilisateur et le mot de passe fournit, il les compare aux fichiers /etc/passwd et /etc/shadow. Si ceux-ci correspondent, il appelle alors le programme login.

Alternativement, getty peur lancer un gestionnaire de connexion.