A quoi sert vraiment la partition / boot?

Je lis un texte relativement ancien sur les partitions et les systèmes de fichiers Linux (la Bible de certification LPIC 1 ). Ça dit:

Certaines versions des chargeurs de démarrage Linux ne peuvent pas accéder à un noyau situé en dehors des 1024 premiers cylindres sur un disque. En plaçant la partition / boot au début du lecteur, vous êtes assuré de ne pas avoir de problème pour accéder au noyau au démarrage. Ce problème se manifeste le plus souvent dans les cas de double amorçage de Linux avec un autre système d'exploitation se trouvant sur la première partition.

Pourquoi un chargeur de démarrage n’aurait-il « pas accès au noyau en dehors des 1024 premiers cylindres sur un disque »?

De plus, que signifie " placer la partition / boot au début du lecteur "?

C'est une limitation imposée par un très vieux BIOS et un chargeur de démarrage plutôt que par Linux lui-même. Le BIOS ne pourra accéder qu’aux 1024 premiers cylindres du disque ( pour plus d’informations sur ce que sont les cylindres / têtes / secteurs), cliquez ici . Cette limitation s'étendrait aux chargeurs de démarrage qui, en raison de leur nature simple, n'auraient pas leurs propres pilotes de disque et utiliseraient les services du BIOS pour accéder au disque.

Cela signifiait que le chargeur de démarrage et le noyau (puisque c'est le travail du chargeur de démarrage de le charger) devraient se trouver dans les 1024 premiers cylindres sur les systèmes avec cette limitation. Un moyen simple de le faire était de créer une /bootpartition séparée contenant le noyau et de la placer au début du lecteur (généralement en la plaçant simplement comme première partition). Cela signifie qu'il résiderait physiquement dans les 1024 premiers cylindres, à condition bien sûr que la partition ne soit pas trop grande.

La limitation n'est plus un problème car elle ne s'applique qu'aux anciens BIOS. En outre, de nombreux chargeurs de démarrage modernes (par exemple GRUB) ont leurs propres pilotes de disque et n'ont donc pas besoin de recourir aux services du BIOS. Les chargeurs de démarrage modernes peuvent être utilisés /bootà d'autres fins, mais il n'est plus nécessaire de se trouver à la fois sur une partition séparée et dans les 1024 premiers cylindres (bien qu'il existe de nombreux cas où il est nécessaire d'avoir /bootune partition séparée).

L'histoire

/bootcontient des fichiers qui ne sont pas utilisés par le système d'exploitation, mais par son chargeur de démarrage . Vous trouverez à la fois les fichiers du chargeur de démarrage lui-même (comme /boot/grub/*pour Grub) et le noyau Linux ( /boot/vmlinuz*) et souvent un initrd ou initramfs associé .

Sur un PC doté d'un BIOS hérité (contrairement à l' UEFI le plus récent disponible sur les ordinateurs les plus récents), le logiciel en ROM charge les 512 premiers octets du disque d'amorçage en mémoire (le secteur d'amorçage ). Avec seulement 512 octets (qui ne contiennent même pas tous du code: certains contiennent des données telles que la table de partition), le code ne peut pas faire grand chose - il ne peut y avoir de pilote de disque réel. Tout ce qui peut être fait dans un espace aussi limité est d'utiliser une interface BIOS pour charger plus de code. Cette interface fournit une commande permettant de charger le Nième secteur sur le disque. La taille de N étant limitée, seul le début du disque peut être atteint de cette façon.

L’interface du BIOS a un peu évolué depuis une trentaine d’années, mais ses limitations de taille ont du mal à suivre la taille des disques, ce qui a amené les anciens BIOS et chargeurs de démarrage à 32 Mo, 512 Mo, 2 Go, 8 Go (et éventuellement autres seuils dont je ne me souviens pas). Le chargeur de démarrage doit pouvoir utiliser l'interface du BIOS pour charger tous les éléments nécessaires pour accéder directement au lecteur de disque. Les chargeurs de démarrage ne contiennent généralement pas de pilotes pour tous les contrôleurs de disque existants, de sorte que tout, jusqu'au chargement du noyau Linux (et initrd / initramfs), doit utiliser l'interface du BIOS et doit donc tenir au début du disque.

Notez qu'il s'agit d'une limitation du BIOS ou du chargeur de démarrage, et non de Linux lui-même ou d'une distribution.

Séparé /boot aujourd'hui

Sur un système avec un BIOS récent et un chargeur de démarrage récent, ou avec UEFI, les limitations de taille ne sont plus pertinentes: les tailles de disque ont maintenant beaucoup de temps pour se rattraper. Cependant, il existe d'autres cas d'utilisation qui rendent /bootutile une partition séparée . Il permet au système principal d’être sur un périphérique RAID que le chargeur de démarrage ne prend pas en charge, ou sur un type de système de fichiers que le chargeur de démarrage ne prend pas en charge. Il permet au système principal d’être sur un périphérique chiffré, que Linux peut déchiffrer mais pas le chargeur de démarrage.

Si aucune de ces limitations et cas d'utilisation ne vous concerne, conserver /bootune partition séparée n'est pas utile. Mais ils touchent suffisamment de gens que la plupart des distributeurs le soutiennent.

Une autre raison à côté du problème de BIOS mentionné est qu’une /bootpartition séparée permet l’utilisation d’un système de fichiers pour le /volume que le chargeur d’amorçage ne comprend pas (sans se limiter au chargement de la liste de blocage comme avec lilo).

BOOTING C'EST DUR

Amorcer ... eh bien ... c'est vraiment la partie la plus difficile. Chaque fois qu'un ordinateur démarre, il se retrouve fondamentalement de nouveau. Il se familiarise avec ses différentes parties et acquiert des capacités pour chacune d'elles. Mais il doit se débrouiller seul, pour ainsi dire, de zéro à chaque fois.

Lors de la conception d'un processus de démarrage, l'astuce consiste à mettre la machine en service par étapes. Votre démarrage doit être rapide et fiable, et il doit être à la fois des choses dans un environnement totalement inconnu à chaque fois . Je ne vais même pas m'engager dans une conversation en mode réel / protégé (ce qui ne veut pas dire que je pourrais même) , mais il se passe beaucoup de choses au démarrage. Comme l'ordinateur assimile ses différents composants à chaque fois, il le fait par étapes. Le plus crucial de ces problèmes est probablement le passage de l’exécution du code intégré à l’exécution du code sur disque, ou, en d’autres termes, de l’exécution du noyau. C'est à ce moment que le micrologiciel se rend (apparemment) au système d'exploitation.

Il y a de nombreuses années, ce n'était pas vraiment le cas. Auparavant, le BIOS était en réalité le Basic In / Out - les programmes habituels appelaient le micrologiciel pour dessiner l'écran et accéder au disque. Celles-ci étaient appelées des interruptions - les vieux chapeaux se souviendraient peut-être mieux des joies de la joie qu’ils éprouvaient souvent à assigner des IRQ à leur nouvelle matrice de points ou USR.

INT13H

C'est la série de fonctions 13H d' interruption ( ou INTd'assemblage ) qui est proposée par le BIOS en tant que services d'accès au disque. Celles-ci sont encore utilisées aujourd'hui par les systèmes BIOS dans le processus de démarrage pour passer du firmware au disque.

Un système BIOS vérifiera les premiers octets de chaque disque trouvé et recherchera un modèle qu’il reconnaît en tant qu’enregistrement maître de démarrage ( ouMBR ) . Il s'agit d'un standard de facto datant de plusieurs décennies et qui comprend un peu de binaire brut exécutable qui est écrit sur la tête du disque. Le MBR marque un disque BIOS comme amorçable. Il arrêtera de vérifier quand il en trouvera un, et vous en obtiendrez pratiquement tout ce que vous obtiendrez sans une astuce astucieuse. Lorsqu'il en trouve un, il le mappe dans la mémoire et l'exécute (en mode réel, mais je n'y vais toujours pas) .

Le MBR exécuté n'est presque certainement pas votre noyau système - 512 octets (à donner ou à prendre) seraient plutôt inutiles dans ce département. Il s’agit probablement d’un programme d’ amorçage - un programme spécialement conçu pour surmonter l’ une des nombreuses limitations en matière d’adressage du BIOS - plus précisément, il ne comprend aucun type de système de fichiers.

Lorsque le bootloader lit dans le noyau réelle et exécute ce en mémoire (comme nous prions tous ce sera à chaque fois) , il sera probablement le faire en demandant au BIOS via un INT13Happel d' interruption. Et si ce n’est pas le cas - de nombreux chargeurs de démarrage plus sophistiqués montent les systèmes de fichiers de manière conventionnelle et exécutent le code d’une autre manière -, alors il est très peu probable que le chargeur de démarrage soit aussi sophistiqué sans un INT13Hou deux. Les chargeurs de démarrage doivent souvent charger eux-mêmes la chaîne - ou leurs différentes étapes - car les 512 octets attribués en premier ne répondent même pas à leurs besoins.

POULET ET OEUFS

Je sais que tout cela est une façon détournée de discuter du disque, mais à ce stade, il devrait être parfaitement clair que le principal problème - on pourrait appeler cela un type poule-œuf - est d'accéder au disque contenant les instructions du programme. sur la façon d'accéder aux disques . La clé de ce problème réside dans les microprogrammes - et continue de prendre des formes très différentes, même sur les systèmes EFI - et, qu’elle soit faible ou non, le microprogramme est le lien le plus important de la chaîne de démarrage.

Vous voyez, une fois que le noyau s'exécute et que toutes ses nombreuses routines d'accès et de contrôle du matériel sont initiées, tous ces problèmes disparaissent en quelque sorte (ou, à tout le moins, changent quelque peu) , car les systèmes d'exploitation modernes prennent le contrôle total du système, mais tant qu'ils ne le font pas, les limites du système ne s'étendent que dans la mesure où le microprogramme le permet. Cela en dit long - le BIOS n'a pas beaucoup changé depuis le 8086. L' INT13Happel est un original 8086. Oui, il y a eu des myriades d' extensions et des bidouilles bien sûr, mais des innovations ...?

DE MIEUX EN MIEUX

La plupart des modifications apportées au BIOS ont été au mieux de simples bandages. Auparavant, le disque dur devait être physiquement cartographié - divers aspects spécifiques de sa géométrie étaient évoqués lorsque des données étaient stockées ou extraites. Finalement, le disque dur conventionnel a atteint une taille qui l’interdit. Même la carte abstraite contenait trop d’ informations à gérer par un BIOS. Comme il ne peut fonctionner qu'en mode réel, le BIOS est limité à 1 Mo par registre de mémoire. Augmentez la taille de la carte des cylindres à une valeur supérieure à celle indiquée, ou faites en sorte que l’une de ses propriétés soit plus grande que ce qui peut être traité en bits, et le BIOS est littéralement perdu - hors limite.

Cet obstacle a été rencontré et brisé à plusieurs reprises. Chaque fois que la carte a été extraite et encodée de manière plus récente, plus intelligente et moins précise. Et ces jours-ci, il est littéralement impossible pour un BIOS de mapper avec précision un lecteur. L'adressage de bloc logique est désormais la norme de facto, bien que certaines traductions Cylinder / Head / Sector (ou CHS) restent nécessaires. Ce que le microprogramme de la carte mère a perdu en précision / responsabilité, de telles extensions ont été résumées et ajoutées aux responsabilités du microprogramme de disque pour combler les lacunes.

C'est ce jeu de chat et souris qui est référencé dans votre question. Lorsque le BIOS ne parvient pas à comprendre un disque au-delà d'un certain point en raison de sa taille, toutes les données que vous souhaitez récupérer à votre démarrage, telles qu'un chargeur de démarrage ou un noyau, devraient probablement ne pas être situées au-delà de ce point. C'est d'où /bootvenait.

Peut-être réellement mieux

Heureusement, ces jours-ci, la disparition de BIOS a rendu ces choses inutiles. C'était 30 ans à venir, mais il a été largement remplacé ces dernières années par le standard UEFI (ou EFI 2.0) . UEFI fournit un montage depuis la dernière minute, il s'initialise en mode protégé, il intègre son propre chargeur de démarrage, il fournit un stockage variable de mémoire flash persistante de redémarrage, il est conçu pour gérer quelques zetaoctets ou autre par disque ... et plus encore. autre. C'est loin d'être parfait, mais c'est une amélioration considérable par rapport à son prédécesseur.

Même les arguments pour des chargeurs de démarrage spécialisés impliquant un chiffrement de disque ou des systèmes de fichiers en couches tombent à l'eau compte tenu du fait que tous ces éléments doivent être gérés par le noyau du système d'exploitation. Néanmoins, si vous disposez d'un montage au démarrage, vous avez toujours son exécution (en particulier si on considère que le noyau Linux, dans sa configuration par défaut, est un exécutable EFI à lui tout seul) .

Par conséquent, une /bootpartition séparée ne devrait probablement pas vous préoccuper excessivement. Si vous utilisez un système EFI, vous avez probablement déjà un analogue dans la partition système EFI, car il s’agit là d’une condition préalable au démarrage du mode EFI.

Il existe un /bootrépertoire qui est historiquement déterminé et à partir de là "corrigé" dans la norme de hiérarchie du système de fichiers . Avoir une telle norme permet aux programmes (et aux administrateurs systèmes) d’attendre certains fichiers à certains emplacements. Dans ce cas, les fichiers associés au processus de démarrage.

Le fait de disposer d'une /bootpartition au début d'un disque était logique pour les BIOS plus anciens qui n'étaient pas en mesure d'indexer des blocs / secteurs dans toute la gamme des lecteurs disponibles. Pour cette raison, les informations à charger devraient se trouver sur un secteur pouvant être indexé, d'où une partition séparée (avec de faibles numéros de secteur) à /bootpartir de laquelle le BIOS pourrait charger des données / programmes supplémentaires (pouvant à leur tour traiter tous les problèmes). gamme de disques sans utiliser le BIOS).

Il peut également être très ordonné d’avoir une partition / boot séparée. Sur ma machine, j'ai plusieurs distributions et sauvegardes, chacune dans leurs propres partitions, mais elles partagent toutes la même partition / boot, qui contient tous les noyaux de tous les systèmes d'exploitation. De plus, toutes les distributions pointent vers ma seule et unique copie de lilo.conf qui se trouve également dans / boot, je n'ai donc jamais à deviner ce qui se passe lorsque j'ajoute des noyaux, ajoute des distributions, peu importe. Voici un extrait de mon lilo.conf:

image  = /boot/vmlinuz-3.16.0-4-686-pae
initrd = /boot/initrd.img-3.16.0-4-686-pae
root   = "LABEL=y5--5-Debian1"
label  = y5:D1:16.0-4

image  = /boot/vmlinuz-3.16.0-4-686-pae
initrd = /boot/initrd.img-3.16.0-4-686-pae
root   = "LABEL=y8--5-Debian2"
label  = y8:D2:16.0-4

image  = /boot/vmlinuz-3.16.0-4-686-pae
initrd = /boot/initrd.img-3.16.0-4-686-pae
root   = "LABEL=y11-5-Debian3"
label  = y11:D3:16.0-4

image  = /boot/vmlinuz-3.16.0-4-686-pae
initrd = /boot/initrd.img-3.16.0-4-686-pae
root   = "LABEL=w5--5-Debian1"
label  = w5:D1:16.0-4

... ce ne sont que mes sauvegardes Debian sur deux disques. Vous voyez comme il est facile de garder une trace des noyaux? (pour le moment, toutes les sauvegardes utilisant le même noyau).

Bien que sur les systèmes modernes, les secteurs d’un fichier puissent être consultés n’importe où sur un disque, il est toujours judicieux de limiter les matériaux de démarrage à leur propre partition d’amorçage, simplement en appliquant le principe suivant: "ne mettez pas tous les œufs dans le même panier".

Supposons que le système de fichiers principal soit corrompu de telle sorte qu'un chargeur de démarrage de niveau inférieur ne puisse pas lire correctement l'étape suivante. Si, à la place, les matériaux du chargeur de démarrage sont dans leur propre partition, le noyau peut alors apparaître et traiter correctement la partition racine corrompue via fsck. Cela même peut être dans sa propre partition.

La partition de démarrage peut vous donner des options de "secours", comme le montage d'une partition racine alternative. De plus, que se passe-t-il si vous amorcez plusieurs systèmes d'exploitation dans différentes partitions? Ensuite, le matériel de démarrage n'appartient à aucun de ces systèmes. Il est raisonnable qu’il ait sa propre partition. Vous pouvez remplacer n'importe quelle partition du système d'exploitation par un système d'exploitation différent, tout en pouvant démarrer les systèmes d'exploitation restants.

De plus, si vous souhaitez utiliser un système de fichiers pour votre partition principale que le chargeur de démarrage ne comprend pas du tout? Ou, disons, pour lequel le support côté chargeur est simplement expérimental? Dans de telles situations, un fichier de démarrage peut toujours être utilisé s'il existe une mappe de secteur (et le chargeur de démarrage prend en charge une telle chose: le bon vieux chargeur de démarrage Linux, LILO utilisait des mappes de secteur, et n'avait donc pas à comprendre le système de fichiers. structure du tout). Mais les cartes de secteurs sont intrinsèquement floconneuses. Si le système de fichiers est réorganisé, les secteurs sont déplacés. Par conséquent, les cartes de secteurs deviennent incorrectes et doivent être régénérées, sinon le système ne peut pas redémarrer.

Enfin, il existe un principe d’organisation qui veut que même si vous n’avez pas de partition, c’est toujours une bonne idée que tout le matériel de démarrage soit au moins situé au-dessous /bootet qu’il ne soit dispersé nulle part ailleurs.

Ce n'était pas une limitation de la distribution Linux, mais c'était une limitation des BIOS plus anciens. À cette époque, pour que Linux puisse démarrer, tous les fichiers liés au démarrage étaient placés dans leur propre partition, ce qui en faisait la première partition du disque dur pour que le chargeur de démarrage tombe dans les 1024 premiers cylindres. Créez une partition plus petite que la taille indiquée dans 1024 cylindres (varie d'un disque dur à l'autre). Mais si vous créez une première partition plus grande que cette limite, il est possible que les fichiers du chargeur de démarrage se trouvent en dehors de 1024 cylindres et que le BIOS ne puisse pas les charger.

Vous pouvez également obtenir le même effet en créant deux petites partitions, qui se trouvent toutes deux dans les 1024 premiers cylindres, et en plaçant tous les fichiers du chargeur de démarrage sur le second.

Une autre raison pour bootpartition ces jours sont:

• démarrage à partir de NFS ou NBD
• partition racine chiffrée
• / boot partagé entre différentes distributions