¿Por qué necesitamos un gestor de arranque?

Después de que se inicia el BIOS, o algo similar que sirve como firmware, el control se pasa al gestor de arranque, que yo sepa.

¿Por qué el BIOS no puede cargar el núcleo del sistema operativo directamente?

Además, el manual de GRUB dice: brevemente, un gestor de arranque es el primer programa de software que se ejecuta cuando se inicia una computadora . ¿No es el BIOS el primer programa que se ejecuta?

Un BIOS necesitaría saber cómo cargar un kernel, y esto haría que el BIOS sea demasiado complicado: imagine un BIOS que necesita saber cómo cargar los diferentes sistemas operativos disponibles, cómo pasarles los parámetros del kernel, etc.

Por lo tanto, solo inicializa el hardware y salta a un lugar conocido donde se almacena el gestor de arranque; entonces, se le pasa el control.

Del COMO de Fundamentos de Unix e Internet :

Quizás se pregunte por qué el BIOS no carga el kernel directamente, ¿por qué el proceso de dos pasos con el gestor de arranque? Bueno, el BIOS no es muy inteligente. De hecho, es muy estúpido, y Linux no lo usa en absoluto después del tiempo de arranque. Originalmente fue escrito para PC primitivas de 8 bits con pequeños discos, y literalmente no puede acceder a suficiente disco para cargar el núcleo directamente. El paso del cargador de arranque también le permite iniciar uno de varios sistemas operativos desde diferentes lugares de su disco, en el improbable caso de que Unix no sea lo suficientemente bueno para usted.

En cuanto a que el BIOS es el primer programa que se ejecuta: (de Wikipedia )

El software del BIOS está integrado en la PC y es el primer código que ejecuta una PC cuando se enciende ('firmware de arranque').

Pero un firmware es software. Entonces supongo que el manual de GRUB es al menos confuso en esa parte; El gestor de arranque puede verse como el primer software definido por el usuario que se ejecuta en la computadora.

La razón es la flexibilidad. Es posible que tenga varios sistemas operativos diferentes en un disco duro (Windows, Linux, etc.), o puede tener varias versiones diferentes del mismo sistema operativo. Por lo tanto, es mejor tener un código independiente del sistema operativo que sepa dónde reside cada sistema operativo instalado en el disco duro, cómo cargar cada uno de ellos, cuál cargar, si presentar un menú o no, etc. Esto es Un gestor de arranque.

El BIOS carga y ejecuta el código ubicado en una ubicación predefinida en un disco duro (primer sector). Llamamos a este código un gestor de arranque, pero técnicamente si instaló Windows en un disco duro en blanco, este código también lo instala Windows, por lo que puede llamarlo parte de Windows, especialmente porque el gestor de arranque de Windows no puede cargar ningún otro sistema operativo además de Windows.

Con respecto al primer programa de software que se ejecuta cuando se inicia una computadora: la distinción firmware / software es bastante delgada, y el proceso de inicio de la computadora moderna es muy complicado. El BIOS en sí mismo tampoco es un programa monolítico, sino varias etapas distintas encadenadas. Sin embargo, el gestor de arranque es el primer código que se puede cambiar por el usuario que se ejecuta. Esta es la primera pieza de código que el usuario puede dañar, borrar, infectar con un virus, etc. Por lo tanto, supongo que aunque técnicamente el BIOS es el primer software que se ejecuta, el gestor de arranque es el primero en el sentido de que si la computadora no inicia el usuario necesita para verificar si está bien.

¿Por qué el BIOS no puede cargar el núcleo del sistema operativo directamente?

Tres razones:

• El BIOS en la plataforma de PC original cuando se introdujo en 1981 estaba destinado a funcionar en la misma función que en el sistema operativo CP / M, es decir, una capa de abstracción delgada para un par de dispositivos y un simple cargador de arranque de disco. CP / M tenía otra capa llamada "BDOS" que manejaba el sistema de archivos. DOS era similar a CP / M en muchos aspectos, ya que era el sistema operativo en boga en ese momento, y estaba estructurado de manera similar. El BIOS estaba destinado a manejar aspectos específicos de hardware de la plataforma, una función que los controladores en los sistemas operativos cumplen ahora.

• La noción de un sistema de archivos separado del sistema operativo todavía no se había establecido.

• En este momento, RAM y ROM eran recursos caros y escasos. La PC IBM 5150 original se podía obtener con tan solo 16K de RAM ( referencia ). El tamaño de ROM de este sistema era de 48K y eso incluía un intérprete BÁSICO. Tampoco existía un sistema de archivos estándar en ese momento.

Dado que DOS se convirtió en el sistema operativo más popular para esta plataforma, y ​​Windows a partir de entonces, que trabajó con esta configuración, nadie pensó en extender el BIOS de esta manera para incluir la capacidad real de carga de arranque.

No estoy seguro de las capacidades de UEFI: puede tener una capacidad de carga de arranque real que Windows no usa por una razón u otra (Windows insiste en usar su propio administrador de arranque cuando lo instala). Otros firmwares que no son BIOS como U-Boot y aquellos en muchos teléfonos y enrutadores cargan y ejecutan kernels directamente. No ha habido una razón técnica para ello desde que las BIOS comenzaron a tener espacio en la ROM para hacer más cosas.