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.