Comment Linux gère-t-il une partition séparée / de démarrage?

Je souhaite en savoir plus sur la manière dont Linux gère les partitions de démarrage distinctes. Je ne suis pas vraiment intéressé à faire cela, mais j'aimerais savoir comment cela fonctionne sous le capot.

Considérez un disque dur sda, qui a deux partitions sda1et sda2. Disons que sda2c'est la rootpartition /qui contient le système d'exploitation Linux.

Ma compréhension est que le chargeur de démarrage GRUB2est monté sur /boot. Cependant, lorsque le répertoire se /boottrouve sur une partition distincte sda2, comment cela peut-il se produire avant qu'il ne /soit réellement monté?

Comment l'interaction entre le BIOS, l'enregistrement de démarrage principal et GRUB (ou les fichiers /boot) se produit-elle dans ce cas? Est-ce que les données /bootne sont pas réellement montées sur le /système de fichiers à ce stade précoce?

Remarque: cette question concerne le montage de la partition racine, mais ne traite pas d'une partition de démarrage distincte.

Voici le problème dans votre compréhension:

Ma compréhension est que le chargeur de démarrage GRUB2 est monté sur / boot.

GRUB n'est pas "monté" au démarrage. GRUB est installé sur /boot, et est chargé à partir du code dans le Master Boot Record. Voici un aperçu simplifié du processus de démarrage moderne, en supposant une distribution GNU / Linux avec un MBR / BIOS (pas GPT / UEFI):

1. Le BIOS se charge.
2. Le BIOS charge le petit morceau de code qui se trouve dans le Master Boot Record.
3. GRUB ne tient pas dans 440 octets, la taille du Master Boot Record. Par conséquent, le code qui est chargé analyse simplement la table de partition, trouve la /bootpartition (qui, je crois, est déterminée lorsque vous installez GRUB sur le Master Boot Record) et analyse les informations sur le système de fichiers. Il charge ensuite GRUB Stage 2. (C'est là qu'intervient la simplification.)
4. Stage 2 GRUB charge tout ce dont il a besoin, y compris la configuration GRUB, puis présente un menu (ou non, selon la configuration de l'utilisateur).
5. Une séquence de démarrage est choisie. Cela peut être dû à un délai d'expiration, à la sélection d'une entrée de menu par l'utilisateur ou au démarrage d'une liste de commandes.
6. La séquence de démarrage commence à s'exécuter. Cela peut faire un certain nombre de choses - par exemple, charger un noyau, charger en chaîne vers un autre chargeur de démarrage - mais supposons que la séquence de démarrage soit GNU / Linux standard.
7. GRUB charge le noyau Linux.
8. GRUB charge le disque virtuel initial .
9. Le disque virtuel initial se monte /sous /new_root(éventuellement le déverrouillage cryptographique), démarre udev, démarre la reprise à partir de l'échange, etc.
10. Le disque virtuel initial utilise l' pivot_rootutilitaire pour définir /new_rootcomme réel /.
11. initdéparts. Les partitions sont montées, les démons démarrent et le système démarre.

Notez que le noyau n'est chargé qu'à l'étape 7. Pour cette raison, il n'y a pas de concept de montage avant l'étape 7 . C'est pourquoi /bootdoit être à nouveau monté à l'étape 9, même si GRUB l'a déjà utilisé.

Il peut également être utile de consulter la section GRUB 2 de la page Wikipedia sur GRUB.

Question 1

Ma compréhension est que le chargeur de démarrage GRUB2 est monté sur / boot. Cependant, lorsque le répertoire / boot se trouve sur une partition sda2 distincte, comment cela peut-il se produire avant que / ne soit réellement monté?

Je ne pense pas que vous compreniez bien ici. Depuis la page Wikipedia de GNU GRUB :

extrait

Lorsqu'un ordinateur est allumé, le BIOS de l'ordinateur trouve le périphérique de démarrage principal configuré (généralement le disque dur de l'ordinateur) et charge et exécute le programme de démarrage initial à partir de l' enregistrement de démarrage principal (MBR). Le MBR est le premier secteur du disque dur et porte le numéro 0 (le comptage des secteurs commence à 0). Pendant longtemps, la taille d'un secteur a été de 512 octets, mais depuis 2009, il existe des disques durs d'une taille de secteur de 4096 octets, appelés disques au format avancé . Depuis octobre 2013, ces disques durs sont toujours accessibles dans des secteurs de 512 octets, en utilisant l' émulation 512e .

Dans GRUB version 2, les opérations suivantes ont lieu:

extrait

Démarrage de l'ordinateur

À la mise sous tension, les événements suivants se produisent:

• Le matériel s'initialise, met le CPU en mode réel (pas de mémoire virtuelle) et passe à l'emplacement fixe 0xFFFF0 (câblé dans les circuits du CPU)
• Le code BIOS stocké dans une ROM ou une mémoire flash mappée à cet emplacement est donc exécuté.
• Le code BIOS examine les données de configuration du BIOS pour voir quel est le périphérique de démarrage. Ces données de configuration du BIOS peuvent généralement être modifiées en appuyant sur une séquence de touches spéciale juste après la mise sous tension, provoquant l'exécution du programme de configuration du BIOS. Entre autres choses, le périphérique de démarrage peut généralement être sélectionné ici.
• Le code BIOS charge le MBR du périphérique de démarrage dans la RAM. N'oubliez pas qu'un MBR ne fait que 512 octets! Les données chargées sont bien sûr le programme et les données que grub-install a créés dynamiquement et y ont écrit lorsque le programme grub-install a été exécuté.
• Le code BIOS passe à l'adresse de début du MBR chargé (c'est-à-dire que le code Grub s'exécute pour la première fois depuis la mise sous tension).
• Le code MBR de Grub charge un seul secteur dont l'adresse est câblée dans le bloc MBR. Il boucle ensuite sur les paires (adresse, len) de ce secteur en chargeant toutes les données du disque dans la mémoire (c'est-à-dire charge le contenu du fichier /boot/grub/core.imgou sa copie «incorporée»). Le code MBR passe ensuite au code chargé, c'est-à-dire «exécute» le programme en core.img.
• Comme décrit dans la section «Installation de Grub», cette astuce d'incorporation des adresses de blocs de disque brutes permet de stocker core.imgdans un espace qui n'est pas dans une partition, et qui n'a jamais été formaté comme système de fichiers («incorporation»). Et dans ce cas, s'il core.imgest modifié, tant que la nouvelle version est «intégrée» au même endroit, le code MBR n'a pas besoin d'être mis à jour.
• Alternativement, il est possible que le core.imgse trouve dans un vrai système de fichiers et que Grub lise le core.imgcontenu du fichier sans avoir de pilote pour ce système de fichiers. Cependant, dans ce cas, s'il core.imgest modifié, le premier bloc du fichier peut très bien recevoir une nouvelle adresse sur le disque; si cela se produit, le MBR doit être mis à jour pour pointer vers ce nouvel emplacement. Néanmoins, comme cela core.imgest généralement mis à jour en exécutant grub-install, ce n'est généralement pas un problème.
• Notez qu'en théorie, s'il se core.imgtrouve sur un périphérique différent du MBR et qu'un nouveau matériel est ajouté, l'enregistrement MBR généré par Grub peut ne pas être en mesure de charger correctement le core.imgfichier; l'identifiant d'appareil sur lequel se trouve le premier secteur de core.imgest câblé dans le MBR, pas recherché. Cependant, il n'y a pas de solution pour cela; il n'y a aucun moyen d'incorporer l'équivalent de la commande «recherche» de Grub dans le MBR de 512 octets. Ce problème n'est cependant pas probable; normalement, il core.imgest intégré au même appareil que le MBR. Et une fois core.imgchargé, il peut utiliser search.mod pour trouver tous les autres /boot/grubfichiers, et est donc à l'abri des réarrangements matériels.
• Le core.imgcode exécuté initialise maintenant tous les modules qui y sont intégrés (liés dans core.img); l'un de ces modules sera un pilote de système de fichiers capable de lire le système de fichiers sur lequel /boot/grubréside le répertoire .
• Il enregistre également un ensemble de commandes intégrées: set, unset, ls, insmod.
• Si un «fichier de configuration» a été lié core.img, il est ensuite transmis à un analyseur de script intégré très simple pour traitement. Les commandes de script dans le fichier de configuration ne peuvent appeler que des commandes intégrées ou liées. Des scénarios simples (par exemple, le démarrage d'un ordinateur de bureau typique à partir d'un lecteur local) ne nécessitent aucun fichier de configuration; cette fonction est utilisée pour des choses comme le démarrage via pxe, nfs à distance ou quand /boot/grubest sur un périphérique LVM.
• Core.imgcharge maintenant le fichier “/boot/grub/normal.mod”dynamiquement depuis le disque et passe à sa fonction d'entrée. Notez que cette étape nécessite la configuration du pilote de système de fichiers approprié (c'est-à-dire intégré).

REMARQUE: Lorsque vous voyez le menu GRUB2 typique dans lequel vous sélectionnez le système d'exploitation / noyau à démarrer, vous faites référence au /boot/grubrépertoire du système à ce stade.

Les références

• Démarrage de Linux sur x86 à l'aide de Grub2
• GNU GRUB - Wikipedia
• 6 étapes du processus de démarrage Linux (séquence de démarrage)
• À l'intérieur du processus de démarrage Linux
• Processus de démarrage de Linux
• Bootloader GRUB 2 - Tutoriel complet - Dedoimedo

Linux (le noyau) ne se soucie pas du nombre de partitions de démarrage dont vous disposez. Chargement du noyau à partir du disque est le travail du bootloader (par exemple grub, grub2, lilo) et ces outils aussi ne se soucient pas du nombre d'emplacements peut se trouver un noyau. Ils ne se soucient que de l'emplacement spécifique.

Par exemple, ma partition de démarrage est /dev/md1, qui est un miroir RAID mdadm soutenu par les partitions physiques /dev/sde1et /dev/sdf1. Je peux les monter individuellement si je le voulais et en tant que tel, cela compte techniquement comme ayant deux partitions de démarrage, bien qu'elles devraient contenir les mêmes données.

Avoir deux partitions pour / boot pour moi est un problème de disponibilité, mais il pourrait également s'agir de partitions / boot différentes. La prochaine étape est de savoir comment le chargeur de démarrage sait? Voici comment:

menuentry 'Linux 3.10.17 (sde) kernel-3.10.17-g' {
        root=hd0,1
        linux /boot/kernel-3.10.17-g domdadm dolvm root=/dev/md3
        initrd /boot/initrd-3.10.17-g
}

menuentry 'Linux 3.10.17 (sdf) kernel-3.10.17-g' {
        root=hd1,1
        linux /boot/kernel-3.10.17-g domdadm dolvm root=/dev/md3 
        initrd /boot/initrd-3.10.17-g
}

Ceci est un extrait d'une grub2configuration et vous remarquerez que les seules différences sont root=hd0,1et root=hd1,1qui établissent la partition de démarrage à laquelle cette entrée fait référence.

Maintenant, pour vous guider à travers une botte afin que vous puissiez comprendre ce qui se passe ici.

• Le BIOS lit le MBR à partir du volume de démarrage et passe au chargeur de démarrage
• Le chargeur de démarrage (par exemple grub2) est configuré pour savoir quel périphérique et quelle partition contient votre noyau. Grub2 accède directement à cette partition et charge votre noyau en mémoire.
• Votre chargeur de démarrage saute ensuite dans le noyau et le noyau démarre votre machine.

Le chargeur de démarrage ne se soucie pas du nombre de partitions de démarrage que vous avez, il ne se soucie que de leur emplacement et vous devez lui fournir ces informations.

Le noyau ne se soucie pas du nombre de partitions de démarrage dont vous disposez, car il n'a jamais besoin de les voir (il vous suffit de le disposer pour ajouter de nouveaux noyaux par exemple).