¿Cómo un kernel monta la partición raíz?

Mi pregunta es sobre el arranque de un sistema Linux desde una partición / boot separada. Si la mayoría de los files de configuration se encuentran en una partición / separada, ¿cómo funciona el kernel correctamente al momento del arranque?

Cualquier elaboración sobre esto sería genial. Siento que me falta algo básico. Me preocupa principalmente el process y el order de las operaciones.

¡Gracias!

EDITAR: Creo que lo que tenía que preguntar estaba más en la línea del file dev que se usa en el parámetro raíz del kernel. Por ejemplo, digamos que le doy a mi root param como root = / dev / sda2. ¿Cómo tiene el núcleo una asignación del file / dev / sda2?

Linux inicialmente arranca 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 controlleres y los modules del sistema de files necesarios). Monta la partición raíz en un punto de assembly temporal en el initrd , luego invoca pivot_root(8) para intercambiar los puntos de assembly raíz y temporal, dejando el initrd en una position para umount y el sistema de files raíz real en / .

En la antigüedad, el kernel estaba codificado para saber el número mayor / menor del dispositivo de la raíz fs y montado ese dispositivo después de inicializar todos los controlleres de dispositivo, que estaban integrados en el kernel. La utilidad rdev se puede usar para modificar el número de dispositivo raíz en la image del kernel sin tener que volver a comstackrlo.

Eventualmente, los cargadores de arranque llegaron y pudieron pasar una línea de command al kernel. Si se pasó el argumento root= , eso le dijo al kernel dónde estaba la raíz fs en lugar del valor incorporado. Los controlleres necesarios para acceder aún tenían que estar integrados en el kernel. Mientras que el argumento parece un nodo de dispositivo normal en el directory /dev , obviamente no hay directory /dev antes de que se monte la raíz fs, por lo que el kernel no puede search un nodo dev allí. En cambio, ciertos nombres de dispositivos bien conocidos están codificados en el kernel para que la cadena se pueda traducir al número del 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 la image initrd , que era una especie de image comprimida del sistema de files (image ext2 gzip, image romfs gzip, finalmente squashfs se volvió dominante). El kernel descomprimiría esta image en un ramdisk y montaría el ramdisk como root fs. Esta image contenía algunos controlleres adicionales y scripts de arranque en lugar de un init real. Estos scripts de arranque realizan varias tareas para reconocer hardware, activar arreglos RAID y LVM, detectar UUID y analizar la command-line del kernel para encontrar la raíz real, que ahora se puede especificar mediante UUID, label de volumen y otras funciones avanzadas. Luego montó la raíz real fs en /initrd , luego ejecutó la pivot_root sistema pivot_root para tener el núcleo swap / y /initrd , luego exec /sbin/init en la raíz real, que luego desmontaría /initrd y liberaría ramdisk.

Finalmente, hoy tenemos el initramfs . Esto es similar al initrd , pero en lugar de ser una image comprimida del sistema de files que se carga en un ramdisk, es un file cpio comprimido. A tmpfs se monta como raíz y el file se extrae allí. En lugar de utilizar pivot_root , que se consideraba un hack sucio, los scripts de arranque de initramfs montan la raíz real en /root , eliminan todos los files en la raíz tmpfs, luego chroot en /root y exec /sbin/init .

Suena como si estuvieras preguntando cómo el núcleo "sabe" qué partición es la partición raíz, sin acceso a los files de configuration en / etc.

El núcleo puede aceptar arguments de línea de command como cualquier otro progtwig. GRUB, o la mayoría de otros cargadores de arranque pueden aceptar arguments de línea de command como input de usuario, o almacenarlos y hacer que varias combinaciones de arguments de línea de command estén disponibles a través de un menu. El gestor de arranque pasa los arguments de la línea de command al kernel cuando lo carga (no conozco el nombre o la mecánica de esta convención, pero es probablemente similar a cómo una aplicación recibe arguments de línea de command de un process de llamada en un kernel en ejecución).

Una de esas opciones de línea de command es root , donde puede especificar el sistema de files raíz, es decir, root=/dev/sda1 .

Si el kernel usa un initrd, el gestor de arranque es responsable de decirle al núcleo dónde está, o poner el initrd en una location de memory estándar (creo); al less es así como funciona en mi Guruplug.

Es completamente posible no especificar uno y luego tener el pánico de su kernel inmediatamente después de comenzar a quejarse de que no puede encontrar un sistema de files raíz.

Puede haber otras maneras de pasar esta opción al kernel.

Grub monta la partición /boot y luego ejecuta el kernel. En la configuration de Grub, le dice al kernel qué usar como dispositivo raíz.

Por ejemplo, en el menu de menu.lst :

 kernel /boot/linux root=/dev/sda2 

Vamos, GRUB no "monta" / arranca, solo lee 'menu.lst' y algunos modules, tampoco es parte del kernel LINUX. Cuando llame al kernel, pasará un argumento "raíz" con la partición raíz. En el peor de los casos, el kernel sabe que just / boot ha sido montado (LOL).

Siguiente: geekosaur tiene razón, Linux usa un ramdisk inicial en formatting de image comprimida y luego monta el sistema de files raíz real al llamar a pivot_root . Entonces Linux comienza a ejecutarse desde una image, y luego desde su unidad de disco local.

El gestor de arranque, ya sea grub o lilo o lo que sea, le dice al kernel dónde search con el indicador root= y opcionalmente carga un ramdisk inicial en la memory a través de initrd antes de arrancar el kernel.

Luego, el kernel carga, testing su hardware y controlleres de dispositivos y mira alnetworkingedor del sistema para ver qué puede ver (puede revisar esta información de diagnóstico escribiendo dmesg ; actualmente es probable que se desplace demasiado rápido para ver) luego intenta montar la partición mencionada en el parámetro root=

Si hay un initrd, se monta primero y los modules / controlleres de dispositivo en él se cargan y sondean antes de montar el sistema de files raíz. De esta forma, puede comstackr los controlleres para sus discos duros como modules y aún así poder arrancar.