Comment un noyau monte-t-il la partition racine?

Ma question concerne le démarrage d'un système Linux à partir d'une partition / boot distincte. Si la plupart des fichiers de configuration se trouvent sur une partition / séparée, comment le noyau la monte-t-il correctement au démarrage?

Toute élaboration à ce sujet serait formidable. J'ai l'impression de manquer quelque chose de basique. Je m'intéresse principalement au processus et à l'ordre des opérations.

Merci!

EDIT: Je pense que ce que je devais demander était plus dans le sens du fichier de développement utilisé dans le paramètre du noyau racine. Par exemple, disons que je donne mon paramètre racine en tant que root = / dev / sda2. Comment le noyau a-t-il un mappage du fichier / dev / sda2?

Linux démarre initialement avec un ramdisk (appelé an initrd, pour "INITial RamDisk") comme /. Ce disque en a juste assez pour pouvoir trouver la vraie partition racine (y compris tous les pilotes et modules de système de fichiers requis). Il monte la partition racine sur un point de montage temporaire sur le initrd, puis invoque pivot_root(8)pour échanger les points de montage racine et temporaire, laissant le initrden position à umountmodifier et le système de fichiers racine réel activé /.

Dans les temps anciens, le noyau était codé en dur pour connaître le nombre majeur / mineur de périphérique de la racine fs et monté ce périphérique après avoir initialisé tous les pilotes de périphériques, qui ont été intégrés au noyau. L' rdevutilitaire peut être utilisé pour modifier le numéro de périphérique racine dans l'image du noyau sans avoir à le recompiler.

Finalement, les chargeurs de démarrage sont arrivés et pouvaient passer une ligne de commande au noyau. Si l' root=argument était passé, cela indiquait au noyau où se trouvait la racine fs au lieu de la valeur intégrée. Les pilotes devaient accéder à ce qui devait encore être intégré dans le noyau. Bien que l'argument ressemble à un nœud de périphérique normal dans le /devrépertoire, il n'y a évidemment pas de /devrépertoire avant que le fs racine ne soit monté, donc le noyau ne peut pas rechercher un nœud de développement là-bas. Au lieu de cela, certains noms de périphériques bien connus sont codés en dur dans le noyau afin que la chaîne puisse être traduite en numéro de périphérique. Pour cette raison, le noyau peut reconnaître des choses comme /dev/sda1, mais pas des choses plus exotiques comme /dev/mapper/vg0-rootou un UUID de volume.

Plus tard, le initrdest entré en scène. Avec le noyau, le chargeur de démarrage chargerait l' initrdimage, qui était une sorte d'image de système de fichiers compressée (image extz gzippée, image romfs gzippée, squashfs est finalement devenue dominante). Le noyau décompresserait cette image dans un disque virtuel et monterait le disque virtuel en tant que racine fs. Cette image contient des pilotes et des scripts de démarrage supplémentaires au lieu d'un vrai init. Ces scripts de démarrage ont effectué diverses tâches pour reconnaître le matériel, activer des éléments tels que les tableaux RAID et LVM, détecter les UUID et analyser la ligne de commande du noyau pour trouver la vraie racine, qui pourrait maintenant être spécifiée par l'UUID, l'étiquette de volume et d'autres choses avancées. Il a ensuite monté le vrai root fs dans /initrd, puis exécuté l' pivot_rootappel système pour que le noyau permute /et/initrd, puis exécutez /sbin/initsur la vraie racine, qui démonterait /initrdet libérerait alors le ramdisk.

Enfin, nous avons aujourd'hui le initramfs. Ceci est similaire à initrd, mais au lieu d'être une image de système de fichiers compressée qui est chargée dans un disque virtuel, il s'agit d'une archive cpio compressée. Un tmpfs est monté en tant que racine et l'archive y est extraite. Au lieu d'utiliser pivot_root, qui était considéré comme un hack sale, les initramfsscripts de démarrage montent la vraie racine dans /root, suppriment tous les fichiers dans la racine tmpfs, puis chrootdans /rootet exécutent /sbin/init.

On dirait que vous demandez comment le noyau "sait" quelle partition est la partition racine, sans accès aux fichiers de configuration sur / etc.

Le noyau peut accepter des arguments de ligne de commande comme n'importe quel autre programme. GRUB, ou la plupart des autres chargeurs de démarrage, peut accepter des arguments de ligne de commande comme entrée utilisateur, ou les stocker et rendre diverses combinaisons d'arguments de ligne de commande disponibles via un menu. Le chargeur de démarrage transmet les arguments de ligne de commande au noyau lorsqu'il le charge (je ne connais pas le nom ou la mécanique de cette convention, mais c'est probablement similaire à la façon dont une application reçoit les arguments de ligne de commande d'un processus appelant dans un noyau en cours d'exécution).

L'une de ces options de ligne de commande est root, où vous pouvez spécifier le système de fichiers racine, c'est-à-dire root=/dev/sda1.

Si le noyau utilise un initrd, le chargeur de démarrage est responsable de dire au noyau où il se trouve, ou de placer l'initrd dans un emplacement mémoire standard (je pense) - c'est au moins la façon dont cela fonctionne sur mon Guruplug.

Il est tout à fait possible de ne pas en spécifier un, puis de paniquer votre noyau immédiatement après avoir commencé à vous plaindre qu'il ne trouve pas de système de fichiers racine.

Il pourrait y avoir d'autres façons de passer cette option au noyau.

Grub monte la /bootpartition puis exécute le noyau. Dans la configuration de Grub, il indique au noyau quoi utiliser comme périphérique racine.

Par exemple dans Grub's menu.lst:

kernel /boot/linux root=/dev/sda2

Allez, GRUB ne "monte" pas / boot, il lit juste 'menu.lst' et certains modules, il ne fait pas non plus partie du noyau LINUX. Lorsque vous appelez le noyau, vous passerez un argument "root" avec la partition root. Au pire, le noyau sait que juste / boot a été monté (LOL).

Suivant: geekosaur a raison, Linux utilise un disque virtuel initial au format d'image compressée, puis monte le véritable système de fichiers racine en appelant pivot_root. Linux démarre donc à partir d'une image, puis à partir de votre lecteur de disque local.

Le chargeur de démarrage, que ce soit grub ou lilo ou autre, indique au noyau où chercher avec l' root=indicateur, et charge éventuellement un premier disque virtuel en mémoire via initrdavant de démarrer le noyau.

Le noyau se charge ensuite, teste ses pilotes de matériel et de périphérique et recherche dans le système ce qu'il peut voir (vous pouvez consulter ces informations de diagnostic en tapant dmesg; de nos jours, il défile probablement trop rapidement pour être vu) puis tente de monter la partition mentionnée dans le root=paramètre.

Si un initrd est présent, il est monté en premier et tous les modules / pilotes de périphérique qu'il contient sont chargés et testés avant le montage du système de fichiers racine. De cette façon, vous pouvez compiler les pilotes de vos disques durs sous forme de modules et toujours pouvoir démarrer.