Dans les temps anciens, le noyau était codé en dur pour connaître le numéro majeur/mineur du périphérique racine fs et montait ce périphérique après avoir initialisé tous les pilotes de périphérique, qui étaient intégrés au noyau. Le rdev Cet utilitaire peut être utilisé pour modifier le numéro de périphérique racine dans l'image du noyau sans avoir à le recompiler.
Finalement, des chargeurs de démarrage sont arrivés et pouvaient transmettre une ligne de commande au noyau. Si le root= argument a été passé, qui a indiqué au noyau où se trouvait la racine fs au lieu de la valeur intégrée. Les pilotes nécessaires pour y accéder devaient encore être intégrés au noyau. Alors que l'argument ressemble à un nœud de périphérique normal dans le /dev répertoire, il n'y a évidemment pas de /dev répertoire avant que le fs racine ne soit monté, de sorte que le noyau ne peut pas y rechercher un nœud de développement. 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-root ou un UUID de volume.
Plus tard, le initrd est entré dans l'image. Avec le noyau, le chargeur de démarrage chargerait le initrd image, qui était une sorte d'image de système de fichiers compressée (image ext2 gzippée, image romfs gzippée, squashfs est finalement devenu dominant). Le noyau décompresserait cette image dans un disque virtuel et monterait le disque virtuel en tant que root fs. Cette image contenait des pilotes supplémentaires et des scripts de démarrage 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 baies RAID et LVM, détecter les UUID et analyser la ligne de commande du noyau pour trouver la véritable racine, qui peut désormais être spécifiée par UUID, étiquette de volume et autres éléments avancés. Il a ensuite monté la vraie racine fs en /initrd , puis exécuté le pivot_root appel système pour que le noyau permute / et /initrd , puis exécutez /sbin/init sur la vraie racine, qui démonterait alors /initrd et libérez le disque virtuel.
Enfin, aujourd'hui nous avons le initramfs . Ceci est similaire au initrd , mais au lieu d'être une image de système de fichiers compressée 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 piratage sale, le initramfs les scripts de démarrage montent la vraie racine en /root , supprimez tous les fichiers de la racine tmpfs, puis chroot en /root , et exec /sbin/init .
Linux démarre initialement avec un disque virtuel (appelé initrd , pour "INITial RamDisk") comme / . Ce disque contient juste assez pour pouvoir trouver la véritable partition racine (y compris tous les modules de pilote et 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, en laissant le initrd en mesure d'être umount ed et le système de fichiers racine réel sur / .
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 en tant qu'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 chargé de dire au noyau où il se trouve ou de placer l'initrd dans un emplacement mémoire standard (je pense) - c'est du moins ainsi que cela fonctionne sur mon Guruplug.
Il est tout à fait possible de ne pas en spécifier un et que votre noyau panique immédiatement après avoir commencé à se plaindre qu'il ne trouve pas de système de fichiers racine.
Il peut y avoir d'autres façons de transmettre cette option au noyau.