Bonjour à tous! Nous avons donc ouvert le suivant, quatrième consécutif, du cours
Administrateur Linux , qui occupe en toute confiance sa niche à côté du cours devopersky. Plus d'
enseignants , plus d'informations et de stands. Eh bien, comme toujours, des informations plus intéressantes que les enseignants ont recueillies.
Allons-y.
Vous êtes-vous déjà demandé ce qui est nécessaire pour que votre système soit prêt à exécuter des applications?
Comprendre les processus de chargement du noyau et de démarrage du système Linux est important pour configurer Linux et résoudre les problèmes de démarrage. Cet article fournit une vue d'ensemble du processus de démarrage du noyau à l'aide du
chargeur de démarrage GRUB2 et du démarrage
exécuté par le système d'initialisation systemd .
En fait, deux séries d'événements sont nécessaires pour mettre un ordinateur Linux en état de marche: démarrage du noyau (démarrage) et démarrage du système (démarrage). Le processus de démarrage du noyau démarre lorsque vous allumez l'ordinateur et se termine par l'initialisation et le démarrage du système par le noyau. Après cela, le processus de démarrage du système commence, et c'est lui qui met l'ordinateur Linux en état de marche.
En général, le processus de chargement du noyau et de démarrage du système Linux est assez simple. Il comprend les étapes suivantes, qui seront décrites plus en détail dans les sections ci-dessous:
- BIOS POST;
- Chargement du noyau (GRUB2);
- Initialisation du noyau;
- Exécution de systemd, le parent de tous les processus.
Veuillez noter que cet article concerne GRUB2 et systemd, car ils sont le programme de chargement et d'initialisation du noyau pour la plupart des distributions. D'autres options étaient précédemment utilisées, et parfois elles peuvent encore être trouvées dans certaines distributions.
Processus de démarrage du noyauLe processus de démarrage du noyau peut être lancé de plusieurs manières. Tout d'abord, si l'alimentation est coupée, la mise sous tension de l'ordinateur démarre le processus de démarrage. Deuxièmement, si un utilisateur local est déjà en cours d'exécution sur l'ordinateur, y compris la racine et l'utilisateur non privilégié, l'utilisateur peut lancer par programme le processus de démarrage du noyau à l'aide de l'interface graphique ou de la ligne de commande pour redémarrer. Le redémarrage éteindra d'abord l'ordinateur, puis le redémarrera.
POST DU BIOS
La première étape du processus de démarrage du noyau Linux n'a rien à voir avec Linux. Il s'agit de la partie matérielle du processus, la même pour tous les systèmes d'exploitation. Lorsque l'ordinateur est alimenté, la première chose qui démarre est le POST (Power On Self Test), qui fait partie du BIOS (Basic I / O System, Basic Input / Output System).
Quand IBM a lancé son premier ordinateur personnel en 1981, le BIOS a été conçu pour initialiser les composants matériels. POST fait partie du BIOS, dont la tâche est d'assurer le bon fonctionnement des équipements informatiques. Si le POST échoue, l'ordinateur peut ne pas fonctionner correctement et le processus de démarrage ne se poursuivra pas.
BIOS POST vérifie les performances de base du matériel, puis provoque une
interruption du BIOS - INT 13H, qui trouve les secteurs de démarrage du noyau sur tous les périphériques connectés avec la possibilité de démarrer. Le premier secteur trouvé, qui contient un enregistrement de démarrage valide, est chargé dans la RAM, après quoi le contrôle est transféré au code à partir du secteur de démarrage.
Le secteur de démarrage n'est que la première étape. La plupart des distributions Linux utilisent l'une des trois options de chargeur de démarrage: GRUB, GRUB2 et LILO. GRUB2 est le plus récent et est maintenant utilisé beaucoup plus souvent que les anciennes versions.
GRUB2GRUB2 est l'abréviation de «GRand Unified Bootloader, version 2» et est désormais le chargeur de démarrage principal pour la plupart des distributions Linux modernes. GRUB2 est un programme qui rend un ordinateur suffisamment intelligent pour qu'il puisse trouver le noyau du système d'exploitation et le charger en mémoire. Étant donné que parler et écrire simplement GRUB est plus facile que GRUB2, dans cet article, j'utiliserai probablement le terme GRUB, mais j'implique GRUB2, sauf indication contraire.
GRUB est compatible avec
la spécification multiboot , ce qui lui permet de charger différentes versions de Linux et d'autres systèmes d'exploitation; il peut également démarrer l'enregistrement de démarrage des systèmes d'exploitation propriétaires dans une chaîne.
GRUB permet également à l'utilisateur de choisir parmi plusieurs téléchargements de noyau possibles pour toute distribution Linux fournie. Cela permet de télécharger la version précédente du noyau si la mise à jour ne peut pas démarrer correctement ou est incompatible avec une partie importante du logiciel. GRUB peut être configuré dans le fichier
/boot/grub/grub.conf .
GRUB1 est maintenant considéré comme obsolète et dans la plupart des distributions modernes remplacé par GRUB2, qui est sa version réécrite. Les distributions basées sur Red Hat ont été mises à niveau vers GRUB2 autour de Fedora 15 et CentOS / RHEL 7. GRUB2 a la même fonctionnalité de démarrage que GRUB1, mais en plus il fournit des environnements basés sur des commandes de type mainframe et pré-OS et plus de flexibilité au stade du pré-démarrage. GRUB2 est configuré dans
/boot/grub2/grub.cfg .
La tâche principale de tout GRUB est de charger le noyau Linux en mémoire et de l'exécuter. Les deux versions de GRUB fonctionnent de manière similaire en trois étapes, mais dans cet article, j'utiliserai GRUB2 pour décrire le fonctionnement de GRUB. La configuration de GRUB et GRUB2 et l'utilisation des commandes GRUB2 dépassent le cadre de cet article.
Bien que officiellement GRUB2 n'utilise pas de numérotation par étapes, pour des raisons de commodité, je vais l'utiliser dans cet article.
Étape 1Comme déjà mentionné dans la section BIOS POST, à la fin du POST, le BIOS recherche les enregistrements de démarrage sur les disques connectés, généralement situés dans le Master Boot Record (MBR), après quoi il charge le premier enregistrement trouvé en mémoire et commence à l'exécuter. Le code d'amorçage, c'est-à -dire la première étape de GRUB2, prend très peu d'espace, car il doit tenir dans le premier secteur de 512 octets du disque dur avec la table de partition. La quantité totale d'espace allouée au code d'amorçage lui-même dans le
MBR standard est de 446 octets. Le fichier de 446 octets pour l'étape 1 est appelé boot-img et ne contient pas de table de partition - il est ajouté à l'enregistrement de démarrage séparément.
Étant donné que l'enregistrement de démarrage doit être si petit, il n'est pas très «intelligent» et ne comprend pas la structure du système de fichiers. Par conséquent, le seul but de l'étape 1 est de détecter et de charger l'étape 1.5. Pour ce faire, l'étape 1.5 de GRUB doit être située dans l'espace entre l'enregistrement de démarrage lui-même et la première partition sur le disque. Après avoir chargé l'étape 1.5 GRUB dans la RAM, l'étape 1 transfère le contrôle à l'étape 1.5.
Étape 1.5Comme indiqué ci-dessus, l'étape 1.5 de GRUB doit se situer entre l'enregistrement de démarrage et la première partition sur le disque. Historiquement, cet espace reste inutilisé pour des raisons techniques. La première partition sur le disque dur commence dans le secteur 63, et en tenant compte du MBR dans le secteur 0, il y a 62 secteurs de 512 octets - 31744 octets - dans lesquels vous pouvez stocker le fichier core.img - étape 1.5 GRUB. Le fichier core.img pèse 25389 octets, ce qui est suffisamment d'espace pour le stocker entre le MBR et la première partition de disque.
Étant donné que davantage de code peut être utilisé pour l'étape 1.5, il peut suffire de contenir plusieurs pilotes de système de fichiers courants, tels que EXT standard et d'autres systèmes de fichiers Linux, FAT et NTFS. core.img dans GRUB2 est plus complexe et fonctionnel qu'à l'étape 1.5 de GRUB1. Cela signifie que l'étape 2 de GRUB2 peut résider dans un système de fichiers EXT standard, mais pas dans un volume logique. Par conséquent, l'emplacement standard des fichiers de l'étape 2 est le système de fichiers
/boot , ou plutĂ´t
/boot/grub2 .
Notez que le répertoire / boot doit se trouver dans le système de fichiers pris en charge par GRUB. Tous les systèmes de fichiers n'ont pas cette prise en charge. La tâche de l'étape 1.5 consiste à démarrer avec les pilotes de système de fichiers nécessaires pour rechercher les fichiers de l'étape 2 dans le système de fichiers / boot et charger les pilotes nécessaires.
Étape 2Tous les fichiers GRUB Stage 2 se trouvent dans le répertoire
/boot/grub2 et plusieurs sous-répertoires. GRUB2 n'a pas de fichier image comme dans les étapes 1 et 2. Au lieu de cela, il se compose principalement de modules de noyau d'exécution, qui sont chargés à partir du
/boot/grub2/i386-pc selon les besoins.
La tâche de l'étape 2 de GRUB2 est de détecter et de charger le noyau Linux dans la RAM et de transférer le contrôle du contrôle informatique au noyau. Le noyau et ses fichiers associés se trouvent dans le répertoire
/boot . Les fichiers du noyau sont faciles à reconnaître, car leurs noms commencent par vmlinuz. Vous pouvez lister le contenu du répertoire
/boot pour voir les noyaux actuellement installés sur votre système.
GRUB2, comme GRUB1, prend en charge le chargement de plusieurs noyaux Linux. Le système de gestion de paquets Red Hat prend en charge le stockage de plusieurs versions du noyau afin que vous puissiez charger l'ancienne version du noyau en cas de problème avec la plus récente. Par défaut, GRUB fournit un menu préchargé des noyaux installés, y compris l'option de secours, et après la configuration, l'option de récupération.
Stage 2 GRUB2 charge le noyau sélectionné en mémoire et transfère le contrôle du contrôle informatique au noyau.
Le noyauTous les cœurs sont dans un format compressé auto-extractible pour économiser de l'espace. Les noyaux sont situés dans le répertoire
/boot , avec l'image de disque RAM d'origine et une liste de partitions sur les disques durs.
Une fois que le noyau sélectionné est chargé en mémoire et commence à s'exécuter, il doit tout d'abord s'extraire de la version compressée du fichier avant de commencer à faire un travail utile. Une fois l'extraction effectuée, il charge
systemd , qui remplace l'ancien programme d'
initialisation SysV , et lui transfère le contrôle.
C'est la fin du processus de démarrage du noyau. À ce stade, le noyau Linux et systemd sont en cours d'exécution, mais ne peuvent effectuer aucune tâche utile pour l'utilisateur final, car il n'y a rien d'autre à faire.
Processus de démarrage du systèmeLe processus de démarrage du système suit le processus de démarrage du noyau et met l'ordinateur Linux en marche.
systemdsystemd est le parent de tous les processus chargés d'amener l'hôte Linux à un état efficace. Certaines de ses fonctions, plus étendues que celles présentées dans l'ancien programme d'initialisation, devraient gérer de nombreux aspects de l'hôte Linux en cours d'exécution, notamment le montage du système de fichiers, le démarrage et la gestion des services système nécessaires au bon fonctionnement de l'hôte Linux. Toutes les tâches systemd qui ne sont pas liées au processus de démarrage du système dépassent le cadre de la discussion dans cet article.
Tout d'abord, systemd monte les systèmes de fichiers tels que définis dans
/etc/fstab , y compris les fichiers d'échange et les partitions. À ce stade, il peut accéder aux fichiers de configuration situés dans
/etc , y compris le sien. Il utilise son propre fichier de configuration
/etc/systemd/system/default.target pour déterminer la cible pour laquelle charger l'hôte. Le fichier default.target n'est qu'un lien symbolique vers le fichier cible réel. Pour un poste de travail de bureau, il s'agit généralement de graphical.target, équivalent au niveau d'exécution 5 dans l'ancien initialiseur SystemV. Pour le serveur, la valeur par défaut est probablement multi-user.target, similaire au niveau d'exécution 3 dans SystemV. emergency.target est similaire au mode mono-utilisateur.
Notez que les cibles et les services sont des unités systemd.
Le tableau 1 ci-dessous est une comparaison de toutes les cibles systemd avec les anciens niveaux d'exécution de SystemV. Les alias cibles Systemd sont fournis par systemd pour une compatibilité descendante. Les alias cibles permettent aux scripts - et à de nombreux administrateurs système, dont moi - d'utiliser des commandes SystemV telles que init3 pour modifier les niveaux d'exécution. Bien sûr, les commandes SystemV sont dirigées par systemd pour l'interprétation et l'exécution.
Tableau 1: Comparaison des niveaux de contrôle SystemV avec les cibles systemd et certains alias cibles.Chaque cible possède un ensemble de dépendances décrites dans le fichier de configuration. systemd exécute les fichiers nécessaires. Ces dépendances sont les services requis pour exécuter un hôte Linux avec un certain niveau de fonctionnalité. Lorsque toutes les dépendances répertoriées dans les fichiers de configuration cible sont chargées et démarrées, le système fonctionne à ce niveau cible.
systemd analyse également les répertoires d'initialisation SystemV obsolètes pour les fichiers de démarrage. Si tel est le cas, systemd les utilise comme fichiers de configuration pour exécuter les services décrits dans les fichiers. Un service réseau obsolète est un bon exemple de celui qui utilise toujours les fichiers de démarrage SystemV dans Fedora.
La figure 1 ci-dessous est directement copiée à partir de la
page principale de démarrage. Il montre la séquence générale des événements lors du démarrage de systemd et les exigences de base pour garantir son succès.
Les cibles sysinit.target et basic.target peuvent être considérées comme des points de contrôle lors du démarrage du système. Bien que l'un des objectifs de systemd soit d'exécuter des services système en parallèle, certains services et cibles fonctionnelles doivent être lancés avant d'autres. Ces points de contrôle ne peuvent être franchis tant que tous les services et objectifs dont ils ont besoin ne sont pas terminés.
Ainsi, sysinit.target est atteint lorsque toutes les unités dont il dépend sont terminées. Toutes les unités suivantes doivent être complétées: montage de systèmes de fichiers, configuration de fichiers d'échange, démarrage d'udev, définition de l'état initial du générateur de nombres aléatoires, initialisation de services de bas niveau, configuration de services cryptographiques si au moins un système de fichiers est crypté. Dans sysinit.target, ils peuvent être exécutés en parallèle.
sysinit.target exécute tous les services et unités de bas niveau nécessaires pour la fonctionnalité minimale du système, et ceux qui sont nécessaires pour accéder à basic.target.
Figure 1. Carte de démarrage de SystemdAprès avoir exécuté sysinit.target, systemd lance basic.target, en commençant par toutes les unités nécessaires à son exécution. La cible de base fournit des fonctionnalités supplémentaires en lançant les unités nécessaires pour la prochaine cible, y compris la définition de chemins vers divers répertoires exécutables, des sockets de communication et des minuteurs.
Enfin, vous pouvez commencer à initialiser les cibles de niveau utilisateur: multi-user.target ou graphical.target. Il convient de noter que multi-user.target doit être atteint avant l'exécution des dépendances de la cible graphique.
Les cibles soulignées dans la figure 1 sont des cibles de démarrage typiques. Le démarrage du système se termine lorsque l'un d'eux est atteint. Si multi-user.target est la cible par défaut, alors dans la console, vous verrez la connexion en mode texte. Si graphical.target est spécifié par défaut, vous verrez une connexion graphique; L'interface graphique de l'écran de connexion dépend du gestionnaire d'écran que vous utilisez.
Les problèmesJ'ai récemment dû changer le noyau de démarrage par défaut sur un ordinateur Linux qui utilisait GRUB2. J'ai constaté que certaines commandes ne fonctionnaient plus correctement ou je les ai utilisées de manière incorrecte. Je ne sais toujours pas quel était le problème, il faudra plus de temps pour le rechercher.
La commande grub2-set-default a incorrectement configuré l'index du noyau par défaut dans le fichier
/etc/default/grub , donc le noyau alternatif souhaité ne s'est pas chargé. J'ai modifié manuellement
/etc/default/grub GRUB_DEFAULT=saved en
GRUB_DEFAULT=2 , où 2 est l'index du noyau installé que je voulais exécuter. Ensuite, j'ai exécuté la commande
grub2-mkconfig > /boot/grub2/grub.cfg pour créer un nouveau fichier de configuration grub. Cette astuce a fonctionné et un noyau alternatif a été lancé.
ConclusionsGRUB2 et le système d'initialisation systemd sont des composants clés pour les phases de démarrage du noyau et de démarrage du système de la plupart des distributions Linux modernes. Malgré les contradictions, en particulier autour de systemd, ces deux composants fonctionnent bien ensemble pour charger le noyau et exécuter tous les services système nécessaires pour créer un système Linux fonctionnel.
Bien que je considère GRUB2 et systemd dans leur ensemble plus complexes que leurs prédécesseurs, ils ne sont pas plus difficiles à maîtriser et à gérer. Les manuels contiennent de nombreuses informations sur systemd, et sur freedesktop.org la liste de ses pages est présentée dans son intégralité. Pour plus d'informations, consultez les liens ci-dessous:
C’est tout. Nous attendons ici les questions et commentaires ou ils peuvent être posés directement dans
une leçon ouverte .