¿Para qué es realmente la partición / boot?

Estoy leyendo un texto relativamente antiguo sobre particiones Linux y sistemas de archivos (la Biblia de certificación LPIC 1 ). Dice:

Algunas versiones de los cargadores de arranque de Linux no pueden acceder a un núcleo que está fuera de los primeros 1024 cilindros en un disco. Al colocar la partición / boot al comienzo de la unidad, puede estar seguro de que no tendrá problemas al acceder al núcleo durante el arranque. Este problema se muestra con mayor frecuencia en casos de arranque dual de Linux junto con otro sistema operativo que se encuentra en la primera partición.

¿Por qué un gestor de arranque " no tiene acceso al núcleo fuera de los primeros 1024 cilindros en un disco "?

Además, ¿qué significa " poner la partición / boot al comienzo de la unidad "?

Esta es una limitación impuesta por tener un BIOS y un cargador de arranque muy antiguos en lugar de Linux en sí. El BIOS solo podría acceder a los primeros 1024 cilindros del disco (consulte aquí para obtener más información sobre qué cilindros / cabezas / sectores son). Esta limitación se extendería a los gestores de arranque que, debido a su naturaleza simple, no tendrían sus propios controladores de disco y utilizarían los servicios de BIOS para acceder al disco.

Esto significaba que tanto el gestor de arranque como el kernel (ya que es el trabajo del gestor de arranque cargarlo) tendrían que estar dentro de los primeros 1024 cilindros en sistemas con esta limitación. Una manera simple de hacer esto era crear una /bootpartición separada que contuviera el núcleo y colocarla al comienzo de la unidad (generalmente solo convirtiéndola en la primera partición). Esto significa que residiría físicamente dentro de los primeros 1024 cilindros, siempre que la partición no fuera demasiado grande.

La limitación ya no es un problema porque solo se aplica a las BIOS antiguas. Además, muchos cargadores de arranque modernos (por ejemplo, GRUB) tienen sus propios controladores de disco y, por lo tanto, no necesitan depender de los servicios del BIOS. Los cargadores de arranque modernos pueden usarse /bootpara otros fines, pero ya no es necesario estar en una partición separada y dentro de los primeros 1024 cilindros (aunque hay muchos casos en los que es necesario tener /bootuna partición separada).

La historia

/bootcontiene archivos que no son utilizados por el sistema operativo, sino por su gestor de arranque . Encontrará los archivos del gestor de arranque en sí mismo (como /boot/grub/*para Grub) y el kernel de Linux ( /boot/vmlinuz*) y, a menudo, un initrd o initramfs asociado .

En una PC con BIOS heredado (a diferencia del UEFI más reciente que se encuentra en las computadoras más recientes), el software en ROM carga los primeros 512 bytes del disco de arranque en la memoria (el sector de arranque ). Con solo 512 bytes (no todos contienen código: algunos contienen datos como la tabla de particiones), el código no puede hacer mucho, no puede haber un controlador de disco real allí. Todo lo que se puede hacer en un espacio tan limitado es usar una interfaz BIOS para cargar más código. Esta interfaz proporciona un comando para cargar el enésimo sector en el disco, y el tamaño de N es limitado, por lo que solo se puede alcanzar el comienzo del disco de esa manera.

La interfaz del BIOS ha evolucionado un poco en las últimas tres décadas, pero sus limitaciones de tamaño han tenido problemas para mantenerse al día con los tamaños de los discos, lo que ha provocado que los BIOS y cargadores de arranque más antiguos se agoten a 32 MB, 512 MB, 2 GB, 8 GB (y posiblemente otros umbrales que no recuerdo). El gestor de arranque debe poder utilizar la interfaz del BIOS para cargar todas las piezas necesarias para acceder directamente a la unidad de disco. Los cargadores de arranque generalmente no contienen controladores para todos los controladores de disco, por lo que todo hasta cargar el kernel de Linux (y el initrd / initramfs) tiene que usar la interfaz del BIOS y, por lo tanto, tiene que caber al comienzo del disco.

Tenga en cuenta que esta es una limitación del BIOS o del gestor de arranque, no del propio Linux o de una distribución.

Separa /boothoy

En un sistema con un BIOS reciente y un gestor de arranque reciente, o con UEFI, las limitaciones de tamaño ya no son relevantes: los tamaños de disco ahora tienen mucho tiempo para ponerse al día. Sin embargo, hay otros casos de uso que hacen que una /bootpartición separada sea útil. Permite que el sistema principal esté en un dispositivo RAID que el gestor de arranque no admite, o en un tipo de sistema de archivos que el gestor de arranque no admite. Permite que el sistema principal esté en un dispositivo cifrado, que Linux puede descifrar pero no el gestor de arranque.

Si ninguna de estas limitaciones y casos de uso se aplican a usted, mantener /bootuna partición separada no es útil. Pero afectan a suficientes personas que la mayoría de las distribuciones lo respaldan.

Otra razón al lado del problema de BIOS mencionado es que una /bootpartición separada permite el uso de un sistema de archivos para el /volumen que el cargador de arranque no comprende (sin limitarse a la carga de listas de bloqueo como lilo).

EL ARRANQUE ES DURO

Arrancar ... bueno ... realmente es la parte más difícil. Cada vez que una computadora arranca, básicamente se encuentra de nuevo. Se familiariza con sus diversas partes, y por cada una de ellas cumple con su capacidad. Pero tiene que levantarse con sus propias botas, por así decirlo, desde el principio todo el tiempo.

Al diseñar un proceso de arranque, el truco consiste en poner la máquina en funcionamiento por etapas. Su arranque debe ser rápido y confiable, y debe ser ambas cosas en un entorno completamente desconocido cada vez . Ni siquiera me aventuraré en una conversación en modo Real / Protegido (lo que no quiere decir que incluso podría) , pero están sucediendo muchas cosas en el arranque. A medida que la computadora asimila sus diversos componentes cada vez que lo hace en pasos graduados. Probablemente, el más crucial de estos es el paso de la ejecución de código integrado a la ejecución de código en disco o, en otras palabras, el kernel exec. Esto es cuando el firmware (aparentemente) se rinde al sistema operativo.

Hace muchos años, este no era el caso. Solía ​​ser el BIOS, realmente era la entrada / salida básica: los programas regulares realizaban llamadas al firmware por cosas como dibujar la pantalla y acceder al disco. Estos se llamaban interrupciones : los sombreros viejos podrían recordarlos mejor por la emoción de deleite que a menudo encontraban al asignar IRQ para su nueva matriz de puntos o USR.

INT13H

Es la serie de funciones de interrupción ( o INTen jerga de ensamblaje ) 13H que el BIOS ofrece como servicios para acceso a disco. Todavía se usan hoy en día para sistemas BIOS en el proceso de arranque para dar el salto del firmware al disco.

Un sistema BIOS verificará los primeros bytes de cada disco que encuentre y buscará un patrón que reconozca como Registro de arranque maestro ( oMBR ) . Este es un estándar de facto de décadas de antigüedad e incluye un poco de binario en bruto y ejecutable que se escribe en la cabeza del disco. El MBR marca un disco de BIOS como de arranque. Dejará de comprobar cuando encuentre uno, por lo que prácticamente uno es todo lo que obtienes sin algún truco inteligente. Cuando encuentra uno, lo asigna a la memoria y lo ejecuta (en modo Real, pero todavía no voy allí) .

El MBR ejecutado casi definitivamente no es el núcleo de su sistema: 512 bytes (más o menos) serían bastante inútiles en ese departamento. Probablemente sea un gestor de arranque , un programa diseñado específicamente para superar una de las muchas limitaciones de direccionamiento del BIOS, específicamente que no comprende ningún tipo de sistema de archivos.

Cuando el gestor de arranque se lee en el núcleo real y ejecuta que en la memoria (como todos oren lo hará cada vez) , es probable que hacerlo pidiendo a la BIOS a través de una INT13Hllamada de interrupción. Y si no es así, muchos gestores de arranque más sofisticados montarán sistemas de archivos en el sentido convencional y ejecutarán el código de otra manera, entonces es muy poco probable que el gestor de arranque se haya vuelto tan elegante sin uno INT13Ho dos. A menudo, los gestores de arranque deben cargarse en cadena, o en varias etapas de sí mismos, porque los 512 bytes asignados primero no satisfacen ni siquiera sus necesidades.

POLLO Y HUEVO

Todo esto es una forma indirecta de discutir el disco, lo sé, pero en este punto debería estar muy claro que el problema principal, uno podría llamarlo de tipo huevo y gallina , es acceder al disco que contiene las instrucciones del programa. sobre cómo acceder a los discos . La clave de este problema es el firmware , y sigue siendo de maneras muy diferentes, incluso en los sistemas EFI, y, más débil o no, el firmware es el eslabón más importante en la cadena de arranque.

Verá, una vez que el núcleo se ejecuta, y todas sus innumerables rutinas para acceder y controlar el hardware se inician, todos estos problemas desaparecen (o, al menos, cambian un poco) , porque los sistemas operativos modernos toman el control total de un sistema, pero hasta que lo hagan, los límites del sistema se extenderán solo hasta donde el firmware lo permita. Esto dice mucho: el BIOS no ha cambiado mucho desde el 8086. La INT13Hllamada es un original 8086. Sí, ha habido extensiones (innumerables) y hacks, por supuesto, pero ¿innovaciones ...?

MEJOR Y MEJOR

La mayoría de los cambios en el BIOS han sido meras vendas en el mejor de los casos. Solía ​​ser un disco duro que tenía que ser mapeado físicamente: se referían varios aspectos específicos de su geometría cuando los datos se almacenaban o se recuperaban. Finalmente, el disco duro convencional creció hasta un tamaño que lo prohibió. Incluso solo el mapa abstracto era demasiada información para un BIOS. Como solo puede funcionar en modo real, el BIOS está limitado a 1 MB por registro de memoria. Aumente el mapa de cilindros más grande que eso, o haga que cualquiera de sus propiedades sea más grande de lo que se puede abordar en tantos bits, y el BIOS está literalmente perdido, fuera de límites.

Esta barrera se ha cumplido y roto muchas veces. Cada vez que el mapa se abstrae y codifica de una manera más nueva, inteligente y menos precisa. Y así, en estos días es literalmente imposible que un BIOS asigne con precisión una unidad. El direccionamiento de bloque lógico es el estándar de facto ahora, aunque todavía son necesarias algunas traducciones de cilindro / cabeza / sector (o CHS) . Lo que el firmware de la placa base ha perdido en precisión / responsabilidad, tales extensiones han abstraído y agregado a las responsabilidades del firmware del disco para llenar los vacíos.

Es este juego de gato y ratón al que se hace referencia en su pregunta. Cuando el BIOS no puede entender un disco más allá de un cierto punto debido a su gran tamaño, entonces cualquier información que desee recuperar en el arranque, como un gestor de arranque o un kernel, probablemente sea mejor que no se encuentre más allá de ese punto. De aquí es de donde /bootvino.

QUIZÁS REALMENTE MEJOR

Estos días, afortunadamente, tales cosas se vuelven irrelevantes por la desaparición de BIOS. Llegaron 30 años, pero ha sido reemplazado en gran medida en los últimos años por el estándar UEFI (o EFI 2.0) . UEFI proporciona una montura desde el minuto uno, se inicializa en modo protegido, incorpora su propio gestor de arranque, proporciona almacenamiento variable de memoria flash con reinicio persistente, se especifica para manejar unos innumerables zetabytes o lo que sea por disco ... y mucho más. Está lejos de ser perfecto, pero es una gran mejora con respecto a su predecesor.

Incluso los argumentos para cargadores de arranque especializados que involucran cifrado de disco o sistemas de archivos en capas caen cuando considera que todos estos deben ser manejados por el núcleo del sistema operativo de todos modos, y si se le proporciona un montaje en el arranque, siempre tiene un claro: tiro a ejecutarlo (especialmente teniendo en cuenta que el kernel de Linux, en su configuración predeterminada, es un EFI ejecutable por sí solo) .

Entonces, una /bootpartición separada probablemente no debería preocuparte demasiado, y si estás en un sistema EFI, entonces probablemente ya tengas un análogo en la partición del sistema EFI de todos modos, ya que es un requisito para arrancar el modo EFI.

El hecho de que haya un /bootdirectorio está históricamente determinado y desde allí "arreglado" en el Estándar de Jerarquía del Sistema de Archivos . Tener un estándar de este tipo permite que los programas (y los administradores de sistemas) esperen ciertos archivos en ciertas ubicaciones. En este caso, los archivos asociados con el proceso de arranque.

Tener una /bootpartición al comienzo de un disco tenía sentido para los BIOS más antiguos que no podían indexar bloques / sectores en el rango completo de las unidades que estaban disponibles. Debido a esto, la información que debe cargarse debe estar en un sector que pueda indexarse, por lo tanto, una partición separada (con números de sector bajos) /bootdesde la cual el BIOS podría cargar datos / programas adicionales (que a su vez fueron capaces de abordar la totalidad rango de disco sin usar el BIOS).

También puede ser muy ordenado tener una partición separada / de arranque. En mi máquina, tengo muchas distribuciones y copias de seguridad, cada una en sus propias particiones, pero todas comparten la misma partición / boot, que es donde residen todos los núcleos para todos los SO. Además, todas las distribuciones apuntan a mi única copia de lilo.conf que también está en / boot, por lo que nunca tengo que adivinar qué diablos sucede cuando agrego núcleos, agrego distribuciones, lo que sea. Aquí hay un fragmento de mi lilo.conf:

image  = /boot/vmlinuz-3.16.0-4-686-pae
initrd = /boot/initrd.img-3.16.0-4-686-pae
root   = "LABEL=y5--5-Debian1"
label  = y5:D1:16.0-4

image  = /boot/vmlinuz-3.16.0-4-686-pae
initrd = /boot/initrd.img-3.16.0-4-686-pae
root   = "LABEL=y8--5-Debian2"
label  = y8:D2:16.0-4

image  = /boot/vmlinuz-3.16.0-4-686-pae
initrd = /boot/initrd.img-3.16.0-4-686-pae
root   = "LABEL=y11-5-Debian3"
label  = y11:D3:16.0-4

image  = /boot/vmlinuz-3.16.0-4-686-pae
initrd = /boot/initrd.img-3.16.0-4-686-pae
root   = "LABEL=w5--5-Debian1"
label  = w5:D1:16.0-4

... esas son solo mis copias de seguridad de Debian en dos discos. ¿Ves lo fácil que es hacer un seguimiento de los núcleos? (en este momento, todas las copias de seguridad usan el mismo núcleo).

Aunque en los sistemas modernos, se puede acceder a los sectores de un archivo en cualquier parte de un disco, aún tiene sentido limitar los materiales de arranque a su propia partición de arranque, simplemente por el principio de "no poner todos los huevos en una canasta".

Suponga que el sistema de archivos principal está dañado de tal manera que algún gestor de arranque de la etapa inferior no puede leer la siguiente etapa correctamente. Si, en cambio, los materiales del cargador de arranque están en su propia partición, entonces el núcleo puede aparecer y manejar adecuadamente la partición raíz corrupta a través de fsck. Eso mismo puede estar en su propia partición.

La partición de arranque puede darle opciones de "rescate", como montar una partición raíz alternativa. Además, ¿qué sucede si arranca de manera múltiple diferentes sistemas operativos en diferentes particiones? Entonces los materiales de arranque no pertenecen a ninguno de esos sistemas. Es razonable que tenga su propia partición. Puede reemplazar cualquiera de las particiones del sistema operativo con un sistema operativo diferente, sin embargo, puede iniciar los sistemas operativos restantes.

Además, ¿qué sucede si desea utilizar un sistema de archivos para su partición principal que el gestor de arranque no comprende en absoluto? O, digamos, ¿para qué el soporte del lado del cargador de arranque es solo experimental? En situaciones como esa, todavía se puede usar un archivo de tiempo de arranque si hay un mapa de sector (y el cargador de arranque admite tal cosa: el buen y antiguo cargador de arranque de Linux LILO usaba mapas de sector, por lo que no tenía que entender el sistema de archivos estructura en absoluto). Pero los mapas sectoriales son inherentemente escamosos. Si el sistema de archivos se reorganiza, los sectores se mueven y, por lo tanto, los mapas de sectores se vuelven incorrectos y deben regenerarse, de lo contrario, el sistema no puede reiniciarse.

Por último, existe el principio organizativo de que incluso si no tiene una partición real, sigue siendo una buena idea que todas las cosas de arranque estén al menos debajo /booty no dispersas en ningún otro lado.

Esto no fue una limitación de la distribución de Linux, pero fue una limitación de BIOS anteriores. En aquellos días, para garantizar que Linux pudiera arrancar, todos los archivos relacionados con el arranque se colocaron en su propia partición, que se convirtió en la primera partición en el disco duro para garantizar que el cargador de arranque cayera dentro de los primeros 1024 cilindros. Cree una partición que sea más pequeña que el tamaño que se encuentre en 1024 cilindros (varía de un disco duro a otro). Pero si crea una primera partición que es más grande que este límite, existe la posibilidad de que los archivos del cargador de arranque se ubiquen fuera de 1024 cilindros y el BIOS no pueda cargarlos.

También puede lograr el mismo efecto creando dos pequeñas particiones, ambas ubicadas dentro de los primeros 1024 cilindros, y colocando todos los archivos del cargador de arranque en el segundo.

Otra razón para la partición de arranque en estos días son:

• Arranque desde NFS o NBD
• partición raíz encriptada
• / boot compartido entre diferentes distribuciones