En la antigüedad, el núcleo estaba codificado para conocer el número mayor/menor del dispositivo de raíz fs y montaba ese dispositivo después de inicializar todos los controladores de dispositivo, que estaban integrados en el núcleo. El rdev La utilidad podría usarse para modificar el número de dispositivo raíz en la imagen del kernel sin tener que volver a compilarlo.
Eventualmente aparecieron cargadores de arranque y podían pasar una línea de comando al kernel. Si el root= se pasó el argumento, que le dijo al kernel dónde estaba la raíz fs en lugar del valor incorporado. Los controladores necesarios para acceder a eso todavía tenían que estar integrados en el kernel. Mientras que el argumento parece un nodo de dispositivo normal en el /dev directorio, obviamente no hay /dev directorio antes de que se monte el root fs, por lo que el núcleo no puede buscar un nodo de desarrollo allí. En cambio, ciertos nombres de dispositivos bien conocidos están codificados en el núcleo para que la cadena se pueda traducir al número de dispositivo. Debido a esto, el kernel puede reconocer cosas como /dev/sda1 , pero no cosas más exóticas como /dev/mapper/vg0-root o un UUID de volumen.
Más tarde, el initrd entró en escena. Junto con el kernel, el gestor de arranque cargaría el initrd image, que era una especie de imagen de sistema de archivos comprimida (imagen ext2 comprimida con gzip, imagen romfs comprimida con gzip, squashfs finalmente se volvió dominante). El núcleo descomprimiría esta imagen en un ramdisk y montaría el ramdisk como root fs. Esta imagen contenía algunos controladores y scripts de arranque adicionales en lugar de un init real. . Estos scripts de arranque realizaron varias tareas para reconocer el hardware, activar cosas como matrices de incursión y LVM, detectar UUID y analizar la línea de comando del kernel para encontrar la raíz real, que ahora podría especificarse por UUID, etiqueta de volumen y otras cosas avanzadas. Luego montó el fs raíz real en /initrd , luego ejecutó el pivot_root llamada al sistema para que el kernel intercambie / y /initrd , luego exec /sbin/init en la raíz real, que luego desmontaría /initrd y libere el ramdisk.
Finalmente, hoy tenemos el initramfs . Esto es similar al initrd , pero en lugar de ser una imagen de sistema de archivos comprimida que se carga en un ramdisk, es un archivo cpio comprimido. Un tmpfs se monta como raíz y el archivo se extrae allí. En lugar de usar pivot_root , que se consideró un truco sucio, el initramfs los scripts de arranque montan la raíz real en /root , elimine todos los archivos en la raíz tmpfs, luego chroot en /root y ejecuta /sbin/init .
Linux arranca inicialmente con un ramdisk (llamado initrd , para "INITial RamDisk") como / . Este disco tiene lo suficiente para poder encontrar la partición raíz real (incluidos los módulos de controlador y sistema de archivos necesarios). Monta la partición raíz en un punto de montaje temporal en el initrd , luego invoca pivot_root(8) para intercambiar los puntos de montaje raíz y temporal, dejando el initrd en condiciones de ser umount ed y el sistema de archivos raíz real en / .
Parece que está preguntando cómo "sabe" el kernel qué partición es la partición raíz, sin acceso a los archivos de configuración en /etc.
El núcleo puede aceptar argumentos de línea de comandos como cualquier otro programa. GRUB, o la mayoría de los cargadores de arranque, pueden aceptar argumentos de la línea de comandos como entrada del usuario, o almacenarlos y hacer que varias combinaciones de argumentos de la línea de comandos estén disponibles a través de un menú. El gestor de arranque pasa los argumentos de la línea de comandos al kernel cuando lo carga (no sé el nombre o la mecánica de esta convención, pero probablemente sea similar a cómo una aplicación recibe argumentos de la línea de comandos de un proceso de llamada en un kernel en ejecución).
Una de esas opciones de línea de comando es root , donde puede especificar el sistema de archivos raíz, es decir, root=/dev/sda1 .
Si el kernel usa un initrd, el cargador de arranque es responsable de decirle al kernel dónde está, o de poner el initrd en una ubicación de memoria estándar (creo), al menos así es como funciona en mi Guruplug.
Es completamente posible no especificar uno y luego hacer que su kernel entre en pánico inmediatamente después de comenzar a quejarse de que no puede encontrar un sistema de archivos raíz.
Puede haber otras formas de pasar esta opción al kernel.