¿Cómo maneja Linux una partición / boot separada?

Ya no necesitas indagar más en otras webs ya que has llegado al espacio perfecto, tenemos la solución que buscas sin complicaciones.

Solución:

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 arranque. GRUB es instalado para /boot, y es cargado del código en el Master Boot Record. Aquí hay una descripción general simplificada del proceso de arranque moderno, asumiendo una distribución GNU / Linux con un MBR / BIOS (no GPT / UEFI):

1. Se carga la BIOS.
2. El BIOS carga el pequeño fragmento de código que se encuentra en el Registro de arranque maestro.
3. GRUB no cabe en 440 bytes, el tamaño del Master Boot Record. Por lo tanto, el código que se carga en realidad solo analiza la tabla de particiones, encuentra el /boot partición (que creo que se determina cuando instala GRUB en el Master Boot Record) y analiza la información del sistema de archivos. A continuación, carga la etapa 2 de GRUB. (Aquí es donde entra la simplificación).
4. La etapa 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 cargador de arranque, pero supongamos que la secuencia de arranque es estándar GNU / Linux.
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, inicia resume-from-swap, etc.
10. El ramdisk inicial usa el pivot_root utilidad para configurar /new_root como el real /.
11. init empieza. Las particiones se montan, los demonios se inician y el sistema se inicia.

Observe que el kernel solo se carga en el paso 7. Debido a esto, no hay concepto de montaje hasta el paso 7. Esta es la razón por /boot debe montarse de nuevo en el paso 9, aunque GRUB ya lo ha utilizado.

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

A Linux (el kernel) no le importa cuántas particiones de arranque tenga. Cargar el kernel desde el disco es tarea del gestor de arranque (p. Ej. grub, grub2, lilo) y estas herramientas tampoco se preocupan por la cantidad de ubicaciones que podría ubicarse un kernel. Solo se preocupan por 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/sde1 y /dev/sdf1. Puedo montarlos individualmente si quisiera y, como tal, esto técnicamente cuenta como tener dos particiones de arranque, aunque deberían contener los mismos datos.

Para mí, tener dos particiones para / boot es un problema de disponibilidad, pero podrían ser igualmente particiones / boot diferentes. El siguiente paso es ¿cómo lo 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 un grub2 configuración y notará que las únicas diferencias son root=hd0,1 y root=hd1,1 que establecen a qué partición de arranque hace referencia esa entrada.

---

Ahora te guiaré a través de una bota para que puedas entender lo que está sucediendo aquí.

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

---

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

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

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 posible que esto suceda antes de que / se monte realmente?

No creo que lo entiendas bien aquí. Desde la página de Wikipedia de GNU GRUB:

extracto

Cuando se enciende una computadora, el BIOS de la computadora encuentra el dispositivo de arranque principal configurado (generalmente el disco duro de la computadora) y carga y ejecuta el programa de arranque inicial 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. En octubre de 2013, todavía se puede acceder a dichos discos duros en sectores de 512 bytes mediante la emulación de 512e.

En GRUB versión 2 ocurre lo siguiente:

extracto

Arranque de la computadora

Cuando se enciende, sucede lo siguiente:

• El hardware se inicializa, configura la CPU en modo real (sin memoria virtual) y salta a la ubicación fija 0xFFFF0 (cableado en los circuitos de la CPU)
• Por lo tanto, se ejecuta el código de BIOS almacenado en una ROM o memoria flash asignada a esa ubicación.
• El código del BIOS mira 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 algunos key-secuencia justo después de encender la alimentación, 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 de la 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ó y escribió dinámicamente 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, longitud) en ese sector cargando todos esos datos del disco en la memoria (es decir, carga el contenido del archivo /boot/grub/core.img, o su copia “incrustada”). El código MBR luego salta al código cargado, es decir, “ejecuta” el programa en core.img.
• Como se describe en la sección “Instalación de Grub”, este truco de incrustar las direcciones de bloque de disco sin formato hace posible almacenar core.img en 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.img se modifica, siempre que la nueva versión esté “incrustada” en la misma ubicación, no es necesario actualizar el código MBR.
• Alternativamente, es posible que el core.img estar dentro de un sistema de archivos real, y que Grub lea el core.img el contenido del archivo sin tener un controlador para ese sistema de archivos. Sin embargo, en este caso, si core.img se modifica, entonces 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.img normalmente se actualiza ejecutando grub-install, esto no suele ser un problema.
• Tenga en cuenta que teóricamente, si core.img está en un dispositivo diferente al MBR y se agrega nuevo hardware, es posible que el registro MBR generado por Grub no pueda cargar correctamente el core.img expediente; el ID del dispositivo en el que el primer sector de core.img se encuentra conectado al MBR, no se busca. Sin embargo, no hay solución para esto; no hay forma de incrustar el equivalente del comando de “búsqueda” de Grub en el MBR de 512 bytes. Sin embargo, este problema no es probable; normalmente el core.img está integrado en el mismo dispositivo que el MBR. Y una vez core.img se ha cargado, puede usar search.mod para encontrar más /boot/grub archivos y, por lo tanto, es inmune a las reorganizaciones de hardware.
• El ejecutado core.img El código ahora inicializa todos los módulos que están integrados en él (vinculados a core.img); uno de estos módulos será un controlador del sistema de archivos capaz de leer el sistema de archivos en qué directorio /boot/grub vidas.
• También registra un conjunto de comandos integrados: set, unset, ls, insmod.
• Si se ha vinculado un “archivo de configuración” a core.img, esto luego se pasa a un analizador de secuencias de comandos incorporado muy simple para su procesamiento. Los comandos de secuencia de comandos en el archivo de configuración solo pueden invocar comandos integrados o vinculados. Los escenarios simples (por ejemplo, arrancar una computadora de escritorio típica desde una unidad local) no necesitan un archivo de configuración; esta función se utiliza para cosas como el arranque a través de pxe, nfs remotos o cuando /boot/grub está en un dispositivo LVM.
• Core.img ahora 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 del sistema de archivos adecuado (es decir, integrado).

NOTA: Cuando ve el menú típico de GRUB2 donde selecciona qué sistema operativo / kernel arrancar, está haciendo referencia al sistema /boot/grub directorio en este punto.

Referencias

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

Reseñas y valoraciones

Si te animas, tienes la libertad de dejar un artículo acerca de qué te ha impresionado de esta crónica.

---

---

Utiliza Nuestro Buscador