¿Cómo trata Linux con una partición separada / de arranque?

Estoy interesado en aprender cómo Linux trata con particiones de arranque separadas. Estoy no interesado en realidad hacer esto, pero me gustaría saber cómo funciona esto bajo el capó.

Considere un disco duro sda, que tiene dos particiones sda1y sda2. Digamos que esa sda2es la rootpartición /que contiene el sistema operativo Linux.

Tengo entendido que el gestor de arranque GRUB2está montado en /boot. Sin embargo, cuando el directorio /bootestá en una partición separada sda2, ¿cómo es que esto puede suceder antes de /que realmente se monte?

¿Cómo se produce con /bootéxito la interacción entre el BIOS, el registro de arranque maestro y GRUB (o los archivos ) en este caso? ¿Es que los datos /bootno están realmente montados en el /sistema de archivos en esta etapa temprana?

Nota: esta pregunta trata sobre el montaje de la partición raíz, pero no trata sobre una partición de arranque separada.

Aquí está el problema en su comprensión:

Tengo entendido que el gestor de arranque GRUB2 está montado en / boot.

GRUB no está "montado" en el maletero. GRUB se instala a /boot, y está cargado de código en el registro maestro de arranque. Aquí hay una descripción general simplificada del proceso de arranque moderno, suponiendo una distribución GNU / Linux con un MBR / BIOS (no GPT / UEFI):

1. El BIOS se carga.
2. El BIOS carga el pequeño fragmento de código que se encuentra en el Master Boot Record.
3. GRUB no cabe en 440 bytes, el tamaño del registro de arranque maestro. Por lo tanto, el código que se carga en realidad solo analiza la tabla de particiones, encuentra la /bootpartición (que creo que se determina cuando instala GRUB en el Registro de inicio maestro) y analiza la información del sistema de archivos. Luego carga la etapa 2 GRUB. (Aquí es donde entra la simplificación).
4. Stage 2 GRUB carga todo lo que necesita, incluida la configuración de GRUB, luego presenta un menú (o no, según la configuración del usuario).
5. Se elige una secuencia de arranque. Esto podría ser por un tiempo de espera, por el usuario seleccionando una entrada de menú o iniciando una lista de comandos.
6. La secuencia de arranque comienza a ejecutarse. Esto puede hacer varias cosas, por ejemplo, cargar un kernel, cargar en cadena a otro gestor de arranque, pero supongamos que la secuencia de arranque es GNU / Linux estándar.
7. GRUB carga el kernel de Linux.
8. GRUB carga el disco RAM inicial .
9. El ramdisk inicial se monta /debajo /new_root(posiblemente desbloqueándolo criptográficamente), inicia udev, comienza resume-from-swap, etc.
10. El ramdisk inicial usa la pivot_rootutilidad para establecer /new_rootcomo real /.
11. initempieza. Las particiones se montan, los demonios comienzan y el sistema arranca.

Observe cómo el núcleo solo se carga en el paso 7. Debido a esto, no hay concepto de montaje hasta el paso 7 . Es por eso /bootque debe montarse nuevamente en el paso 9, aunque GRUB ya lo haya usado.

También puede ser útil mirar la sección GRUB 2 de la página de Wikipedia en GRUB.

Pregunta 1

Tengo entendido que el gestor de arranque GRUB2 está montado en / boot. Sin embargo, cuando el directorio / boot está en una partición separada sda2, ¿cómo es que esto puede suceder antes de que / se monte realmente?

No creo que lo entiendas, aquí está. De la página de Wikipedia de GNU GRUB :

extracto

Cuando se enciende una computadora, el BIOS de la computadora encuentra el dispositivo de arranque primario configurado (generalmente el disco duro de la computadora) y carga y ejecuta el programa inicial de arranque desde el registro de arranque maestro (MBR). El MBR es el primer sector del disco duro y tiene el número 0 (el recuento de sectores comienza en 0). Durante mucho tiempo, el tamaño de un sector ha sido de 512 bytes, pero desde 2009 hay discos duros disponibles con un tamaño de sector de 4096 bytes, llamados discos de formato avanzado . A partir de octubre de 2013, a estos discos duros todavía se accede en sectores de 512 bytes, utilizando la emulación 512e .

En GRUB versión 2 tiene lugar lo siguiente:

extracto

Arrancando la computadora

Cuando se enciende, sucede lo siguiente:

• El hardware se inicializa, establece la CPU en modo real (sin memoria virtual) y salta a la ubicación fija 0xFFFF0 (cableada en los circuitos de la CPU)
• Por lo tanto, se ejecuta el código del BIOS almacenado en una ROM o memoria flash asignada a esa ubicación.
• El código del BIOS examina los datos de configuración del BIOS para ver cuál es el dispositivo de arranque. Estos datos de configuración del BIOS generalmente se pueden editar presionando alguna secuencia de teclas especial justo después de encenderlo, lo que hace que se ejecute el programa de configuración del BIOS. Entre otras cosas, el dispositivo de arranque generalmente se puede seleccionar aquí.
• El código del BIOS carga el MBR del dispositivo de arranque en la RAM. ¡Recuerde que un MBR tiene solo 512 bytes! Los datos cargados son, por supuesto, el programa y los datos que grub-install creó dinámicamente y escribió allí cuando se ejecutó el programa grub-install.
• El código del BIOS salta a la dirección de inicio del MBR cargado (es decir, el código Grub se ejecuta por primera vez desde el encendido).
• El código MBR de Grub carga un solo sector cuya dirección está cableada en el bloque MBR. Luego recorre los pares (dirección, len) en ese sector cargando todos los datos del disco en la memoria (es decir, carga el contenido del archivo /boot/grub/core.imgo su copia "incrustada"). El código MBR luego salta al código cargado, es decir, "ejecuta" el programa core.img.
• Como se describe en la sección "Instalación de Grub", este truco de incrustar las direcciones de bloque de disco sin procesar hace posible almacenar core.imgen un espacio que no está en una partición, y que nunca ha sido formateado como un sistema de archivos ("incrustación"). Y en este caso, si core.imgse modifica, siempre y cuando la nueva versión esté "incrustada" en la misma ubicación, no es necesario actualizar el código MBR.
• Alternativamente, es posible core.imgque esté dentro de un sistema de archivos real y que Grub lea el core.imgcontenido del archivo sin tener un controlador para ese sistema de archivos. Sin embargo, en este caso, si core.imgse modifica, el primer bloque del archivo puede recibir una nueva dirección en el disco; Si esto sucede, el MBR debe actualizarse para apuntar a esta nueva ubicación. Sin embargo, como core.imggeneralmente se actualiza ejecutando grub-install, esto no suele ser un problema.
• Tenga en cuenta que, en teoría, si core.imgestá en un dispositivo diferente al MBR, y se agrega nuevo hardware, entonces el registro MBR generado por Grub podría no ser capaz de cargar el core.imgarchivo correctamente ; el id del dispositivo en el que se encuentra el primer sector de core.imgestá conectado al MBR, no se busca. Sin embargo, no hay solución para esto; no hay forma de incrustar el equivalente del comando "buscar" de Grub en el MBR de 512 bytes. Sin embargo, este problema no es probable; normalmente core.imgestá incrustado en el mismo dispositivo que el MBR. Y una vez que core.imgse ha cargado, puede usar search.mod para encontrar todos los /boot/grubarchivos adicionales y, por lo tanto, es inmune a los reordenamientos de hardware.
• El core.imgcódigo ejecutado ahora inicializa todos los módulos que están integrados en él (enlazados core.img); uno de estos módulos será un controlador del sistema de archivos capaz de leer el sistema de archivos en el que /boot/grubvive el directorio .
• También registra un conjunto de comandos integrados: set, unset, ls, insmod.
• Si se ha vinculado un "archivo de configuración" core.img, este se pasa a un analizador de secuencias de comandos incorporado muy simple para su procesamiento. Los comandos de secuencias de comandos en el archivo de configuración solo pueden invocar comandos integrados o vinculados. Los escenarios simples (por ejemplo, el inicio de una computadora de escritorio típica desde una unidad local) no necesitan un archivo de configuración; Esta función se utiliza para arrancar a través de pxe, nfs remotos o cuando /boot/grubestá en un dispositivo LVM.
• Core.imgahora carga el archivo “/boot/grub/normal.mod”dinámicamente desde el disco y salta a su función de entrada. Tenga en cuenta que este paso requiere que se configure el controlador de sistema de archivos apropiado (es decir, integrado).

NOTA: Cuando vea el menú típico de GRUB2 en el que selecciona qué sistema operativo / núcleo arrancar, hace referencia al /boot/grubdirectorio del sistema en este momento.

Referencias

• Arranque de Linux en x86 usando Grub2
• GNU GRUB - Wikipedia
• 6 etapas del proceso de arranque de Linux (secuencia de inicio)
• Dentro del proceso de arranque de Linux
• Proceso de inicio de Linux
• Gestor de arranque GRUB 2 - Tutorial completo - Dedoimedo

Linux (el núcleo) no le importa cuántas particiones de arranque tenga. Cargar el kernel desde el disco es el trabajo del gestor de arranque (p grub. Ej . grub2, lilo) Y a estas herramientas tampoco les importa la cantidad de ubicaciones en las que se pueda ubicar un kernel. Solo les importa la ubicación específica.

Como ejemplo, mi partición de arranque es /dev/md1, que es un espejo RAID mdadm respaldado por las particiones físicas /dev/sde1y /dev/sdf1. Puedo montarlos individualmente si quisiera y, como tal, técnicamente cuenta como tener dos particiones de arranque, aunque deberían contener los mismos datos.

Tener dos particiones para / boot para mí es un problema de disponibilidad, pero igualmente podrían ser particiones / boot diferentes. El siguiente paso es cómo sabe el gestor de arranque. Aquí es cómo:

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
}

Este es un extracto de una grub2configuración y notará que las únicas diferencias son root=hd0,1y root=hd1,1que establecen a qué partición de arranque hace referencia esa entrada.

Ahora para caminar a través de una bota para que pueda comprender lo que está sucediendo aquí.

• El BIOS lee el MBR del volumen de arranque y salta al cargador de arranque
• El gestor de arranque (por ejemplo grub2) está configurado para saber qué dispositivo y partición contiene su núcleo. Grub2 accede a esta partición directamente y carga su núcleo en la memoria.
• Su gestor de arranque luego salta al núcleo y el núcleo inicia su máquina.

Al gestor de arranque no le importa cuántas particiones de arranque tiene, solo le importa dónde están y debe decirle esa información.

Al núcleo no le importa cuántas particiones de arranque tenga, porque nunca necesita verlas (solo necesita tenerlo disponible para agregar nuevos núcleos, por ejemplo).