Arch boot process (Français) - ArchWiki

# Arch boot process (Français)

From ArchWiki
Jump to navigation Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

Related articles

- Master Boot Record
- GUID Partition Table
- Unified Extensible Firmware Interface
- mkinitcpio (Français)
- init
- systemd (Français)
- fstab (Français)
- Autostarting

Cet article ou section a besoin d'être traduit(e).

Notes: Cet article ne respecte pas la structure de sa version anglophone, merci de le réécrire en conséquence. Vous pouvez aussi ajouter à la version anglophone les informations à-jour et dignes d’intérêt qui ne seraient portées que par la version francophone. Voir Archwiki:Translation_Team_(Français) (Discuss in Talk:Arch boot process (Français)#)

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 (quel que 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 Master Boot Record (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, et l'initramfs avec les paramètres désirés.

En fonction des fichiers de configuration, ce proramme vous proposera, choisir entre les différents systèmes d'exploitation présents sur la machine, ou différentes options de démarrage pour un même système.

Dans le cas de l'UEFI, le noyau peut être directement démarré par l'UEFI depuis la partition ESP. Cependant, l'usage le plus fréquent reste d'y installer un chargeur de démarrage. Cela permet d'éditer plus facilement les paramètres du démarrage, et autorise plus de flexibilité.

Si l'entrée Arch Linux est sélectionnée, le bootloader 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 ce paragraphe du wiki officiel.

Les pages traitant des différents bootloaders sont rangées dans cette catégorie.

Note: La mise à jour du microcode nécessite des ajustements dans la configuration du chargeur de démarrage. Voir: [1]
Astuce: Les bootloaders sont généralement configurés pour démarrer un système d'exploitation par défaut (souvent après un compte à rebours). Cependant, ils offrent tous la possibilité de bloquer le démarrage afin d'éditer les paramètres passés au noyau. Cette fonctionnalité peut être indispensable pour certains dépannages. Il est judicieux de ne pas attendre la panne pour se renseigner la dessus.

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

## 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 le programme `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éfinit 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.

Categories:

- Boot process (Français)
- About Arch (Français)

Hidden category:

- Pages or sections flagged with Template:Translateme