¿Cómo arrancó Linux / xBSD antes de GRUB?

23

Según Wikipedia , GRUB se lanzó en 1995. En ese momento, Linux y xBSD existían durante varios años. Sé que las primeras versiones de Unix estaban vinculadas al hardware en los años 70 y 80, pero Linux y xBSD eran libres de distribuir e instalar. Lo que plantea la pregunta de cómo arrancarías Linux en ese entonces. ¿Se distribuyeron distribuciones con sus propias implementaciones de cargadores de arranque?

boot-loader history

— Sergiy Kolodyazhnyy
fuente

32

Umm ... ¿No estabas cerca cuando LILO era el único gestor de arranque de Linux? Y nunca he usado LILO ni Grub en mis sistemas BSD. ¿En cuál estás interesado? Ver por ej biosboot(8).

— Kusalananda

8

@Kusalananda Desafortunadamente, en ese entonces me importaban más los juguetes y dibujar tortugas ninja que las pipas, los ejecutivos y los proyectiles :) Estoy interesado en la historia general, no en el gestor de arranque específico. Desde la página que ha vinculado, veo que OpenBSD tiene biosbootdos arquitecturas, i386 y amd64. ¿Eso significa que OpenBSD específicamente tuvo que apuntar a las arquitecturas en lugar de tener una herramienta unificadora?

— Sergiy Kolodyazhnyy

1

El gestor de arranque de la primera etapa sería diferente para cada arquitectura (de todos modos, solo i386 y amd64 tienen un BIOS "bios"). Eche un vistazo a NetBSD si está interesado en arquitecturas más exóticas que la PC estándar de bog.

— Kusalananda

3

@Kusalananda No creo que LILO haya sido el único gestor de arranque de Linux. Hasta donde sé, el cargador integrado en las imágenes del kernel es anterior a LILO, y para cuando se interrumpió el soporte para el cargador incorporado, había al menos un puñado de otros gestores de arranque.

— Kasperd

2

LILO era el gestor de arranque predeterminado para muchas distribuciones hasta principios de la década de 2000

— phuclv

51

La primera distribución de Linux que usé en los años 90 ( Slackware 3.0IIRC) usó LILO como gestor de arranque. Y muchas distribuciones se utilizaron LILOdurante años, incluso cuando se GRUBestaba convirtiendo en el gestor de arranque "predeterminado".

Además, en los primeros años de Linux era común arrancar Linux desde otro sistema operativo (es decir, DOS o Windows) en lugar de depender de un gestor de arranque / arranque dual. Por ejemplo había loadlin .

No olvides Syslinux , que es un gestor de arranque más simple que se usa a menudo para las distribuciones de instalación / recuperación de autoarranque USB. O Isolinux (del mismo proyecto) utilizado por muchas distribuciones "Live".

Tenga en cuenta que hoy en día GRUBse puede usar para cargar muchos sistemas operativos, mientras que LILOera más limitado y estaba específicamente dirigido a Linux (es decir, LInux LOader), con cierto soporte para el arranque dual en Windows.
GRUBes muy útil para múltiples arranque dual / debido a sus muchas opciones configurables, las capacidades de scripting, etc ...
Si lo que desea es un único sistema operativo en la máquina "ninguna" (es decir, el que sea gestor de arranque es el predeterminado para la distribución de Linux / BSD) debe bastar.

— Señor shunz
fuente

55

@MrShunz: no había UEFI en ese entonces. Arrancar ventanas era solo cuestión de agregar una entrada de, por ejemplo, other=/dev/hda1con table=/dev/hdato lilo.conf, y lilo simplemente transferiría el control al sector de arranque en hda1, sabiendo que la tabla de particiones estaría en hda.

— ninjalj

2

Solía poder hacer que NTLDR cargara LILO; ver jaeger.morpheus.net/linux/ntldr.php ; Descubrí lo mismo independientemente, en el pasado.

— Roger Lipscombe

2

La desventaja del enfoque de LILO es que se rompe si cambia la ubicación del disco de los archivos para cargar. En particular, esto significa que LILO necesitaba reescribirse en la ubicación de inicio (ya sea MBR o sector de inicio de partición) después de cada actualización del kernel.

— lavar el

1

@plugwash: GRUB tiene el mismo problema con su archivo de segunda etapa. La diferencia aquí es que 1) la "segunda etapa" de LILO fue el kernel, por lo que fueron las actualizaciones del kernel, no las actualizaciones de LILO las que rompieron las cosas; y 2) las actualizaciones de GRUB incluyen una reescritura automática de la ubicación de la segunda etapa en el MBR (con la segunda etapa y luego cargando el kernel de Linux, con pleno conocimiento del sistema de archivos para que la ubicación del kernel no importe). ;-)

— DevSolar

1

Si es posible, IIRC grub almacenará una "etapa 1.5" que comprende el sistema de archivos entre el MBR y la primera partición y solo recurrirá al almacenamiento de una referencia a sectores específicos del sistema de archivos si no hay espacio para la etapa 1.5 (o si se está instalando para un sector de arranque de partición en lugar del MBR)

— plugwash

28

LILO fue el estándar de facto para arrancar Linux en PC antes de Grub, desde una etapa muy temprana (MCC, una de las primeras distribuciones de Linux, lo usó). Varios otros gestores de arranque se utilizaron simultáneamente. Loadlin era bastante común; arrancó Linux desde DOS e incluso se usó en algunas configuraciones umsdospara alojar un entorno Linux en un sistema de archivos DOS ... Otra configuración común no involucraba en absoluto un gestor de arranque: el núcleo podía arrancarse desde un disquete, y la mayoría Los usuarios de Linux mantuvieron un par de disquetes "boot y root" bien conocidos, uno que contiene el kernel y el otro un sistema básico de archivos raíz para fines de rescate.

También había varias formas de usar los cargadores de arranque de otros sistemas operativos para arrancar Linux; por ejemplo, el administrador de arranque de OS / 2 o el NTLDR de Windows NT.

Otros sistemas tenían sus propios gestores de arranque:

SILO en SPARC (estaciones de trabajo solares y otras);
PALO en PA-RISC (estaciones de trabajo HP);
YaBoot y Quik en PowerPC;
aBoot y MILO en Alpha ...

Incluso hoy en día Grub no es el único gestor de arranque que verá. Si bien el inicio del kernel directamente desde un disquete ya no es muy útil (no he comprobado si todavía es posible, suponiendo que pueda construir un kernel lo suficientemente pequeño como para caber en un disquete), puede arrancar directamente desde EFI (que es efectivamente su propio sistema operativo pequeño diseñado para cargar otros sistemas operativos, como es Grub). En muchos sistemas más pequeños (sistemas integrados, computadoras de placa única ...) encontrará U-Boot . (Y también hay una capa EFI para U-Boot ).

— Stephen Kitt
fuente

La arquitectura PowerPC también es interesante porque algunas placas base tenían un BIOS Turing completo: Openfirmware (básicamente el lenguaje de programación Forth con algunas funciones preinstaladas). Esto permitió arrancar directamente desde el BIOS sin el gestor de arranque si sabes cómo configurar tu BIOS

— slebetman

Oye, solo curiosidad, ¿NTLDR puede cargar el kernel de Linux directamente? Escuché que NTLDR puede cargar en cadena grub4dos y luego cargar el kernel de Linux.

— 炸鱼薯条德里克

@slebetman: Más precisamente, OpenFirmware fue desarrollado por Sun para SPARC y luego adoptado por la alianza PowerPC (IBM, Apple, Motorola) para la arquitectura de referencia PowerPC, y específicamente por Apple para Macintoshs basados en PowerPC. Uno de los aspectos poderosos era que los controladores simples podían almacenarse dentro de los chips ROM en las tarjetas de expansión, o en alguna área de arranque designada de un HDD, y dado que estaban escritos en código de bytes contra un ABI específico conocido, funcionarían independientemente de qué CPU arquitectura y sistema operativo que intentabas arrancar.

— Jörg W Mittag

Por ejemplo, podría tener un adaptador RAID que tenga su controlador OpenFirmware dentro de un chip ROM, luego el entorno OpenFirmware podría usar ese controlador para acceder al RAID, dentro del RAID, podría haber otro controlador para el formato de tabla de partición, lo que permitiría el entorno OFW Para encontrar las particiones, al comienzo de cada partición habría un controlador OFW para el sistema de archivos, lo que permitiría al sistema OFW encontrar el núcleo, y el núcleo tendría un pequeño gestor de arranque escrito en el código de bytes OFW al principio.

— Jörg W Mittag

GRUB puede funcionar de manera similar, pero la diferencia es que todos esos controladores tienen que estar escritos específicamente para GRUB, mientras que la belleza de OFW es que el dispositivo traería consigo sus controladores, lo que significa que incluso los dispositivos que aún no lo hicieron existir cuando el entorno OFW fue escrito simplemente funcionaría "mágicamente". UEFI también puede funcionar de manera similar, pero su "formato de código de bytes portátil" es esencialmente un subconjunto de DOS, que es la razón principal por la que Itaniums todavía necesita un emulador x86.

— Jörg W Mittag

12

Hasta mediados de 2.6 núcleos, el núcleo x86 era directamente arrancable si se copiaba en un disquete (como si fuera una imagen de disco).

Esta fue, de hecho, la forma original de arrancar Linux.

Si observa el encabezado de un núcleo x86 hoy, verá un mensaje de error que dice que el arranque desde disquetes como ese ya no funciona.

— Joshua
fuente

2

Por otro lado, el núcleo x86 ahora es directamente arrancable si se entrega a un firmware UEFI. Así que todavía hay un cargador de arranque stub pegado frente al kernel, solo un tipo diferente ...

— Grawity

@grawity: ¿Estás seguro de que no te refieres a x64?

— Joshua

1

@ Joshua: No estoy seguro de lo que quieres decir con eso. EFI en realidad no ejecuta esta parte como código.

— Grawity

2

@Joshua qué? Es "DEC BP", "POP DX" en modo de 16 bits (EBP / EDX en modo de 32 bits). Pero no debe ejecutarse de todos modos; Los archivos binarios EFI son archivos PE (que por supuesto no importa si está escrito en un sector de arranque ...).

— Stephen Kitt

1

@Joshua OK, pero ese no es un comportamiento indefinido x86 en mi mente ;-). (Pienso en "comportamiento x86 indefinido" como códigos de operación cuyo comportamiento no está definido, no comportamiento de plataforma indefinido)

— Stephen Kitt

5

Comencé con Linux a finales de los 90 y, como se mencionó, liloera el predeterminado. Si quisieras un arranque dual con un sistema DOS, podrías hacer un arranque simple sin cargar cosas en HIMEM o cargar controladores de CD, etc. y usar loadlin. Para el arranque dual de Win95, puede hacer que la unidad arranque primero con DOS, luego instalar '95, y el cargador de arranque de '95 le permitiría arrancar el kernel de DOS aún, y luego podría usarlo loadlin.

Para el arranque dual con NT4, el truco consistía en escribir LILO en la /partición, luego quitar los primeros 512 bytes usando dd( dd if=/dev/sda2 of=/path/to/file bs=512 count=1) y colocar el archivo resultante donde ntldrpudiera verlo y podría usarlo desde el cargador de arranque de WinNT. El problema al hacerlo es que cuando actualizaste tu kernel, tenías que recordar repetir todos los pasos antes de reiniciar, de lo contrario tendrías problemas para volver al sistema Linux. El mismo proceso funcionó con Win2k.

Con LILO, cada vez que se actualizaba el kernel, tenía que recordar actualizar LILO.

Cada loadlinvez que el núcleo se actualizaba, tenía que recordar copiar el núcleo a la partición de DOS.

Otra opción que se insinúa en otras respuestas fue escribir el núcleo directamente en un disquete utilizando dd if=/path/to/vmlinuz of=/dev/fd0PERO el dispositivo raíz tenía que estar configurado correctamente en el núcleo, ya sea en el momento de la compilación o mediante la rdevutilidad.

Cuando GRUBsurgió, hubo mucho regocijo porque ya no tenía que recordar actualizar LILO, o actualizar LILO y volver a quitar la información de arranque, etc. No más quedar fuera de su sistema Linux porque olvidó actualizar el cargador de arranque info ...

— ivanivan
fuente

Parece que fue mucho trabajo y una alta posibilidad de quedarse con una máquina sin arranque en ese momento, pero definitivamente una experiencia educativa

— Sergiy Kolodyazhnyy

@SergiyKolodyazhnyy sí, y no había tanta información en Internet, ni los grandes motores de búsqueda para encontrarla si estaba allí. Hubo varias distribuciones de rescate de disquete que tenían suficiente Linux para arrancar y reparar LILO, etc. ¡Hemos recorrido un largo camino!

— ivanivan

La ejecución make installse ejecutaría /sbin/lilo, por lo que realmente no tuvo que actualizar nada a mano (y ese puede ser el caso, si lo ha liloinstalado). Eso puede ser una cuestión de opinión, pero no recuerdo mucho regocijarme grub, por el contrario. Y lilo(al menos su versión de 1999) podría tener dos ventanas de arranque bien, sin necesidad loadlin.

— Mosvy

0

Y antes de LILO y GRUB, tenía que iniciarlo desde la línea de comandos con algún tipo de utilidad de cargador de arranque personalizado.

Como ejemplo, el Amiga tenía Linux disponible. Debía usar una utilidad de línea de comandos llamada amiboot para cargar el kernel ELF en la memoria y saltar a él.

Aquí hay un video de alguien usando amiboot desde la línea de comando para iniciar Linux en un Amiga 600 . Su script StartInstall está llamando al ejecutable amiboot. Puede ver amiboot configurar la memoria, averiguar la dirección de carga deseada y pasar los parámetros al núcleo alrededor de las 0:55.

— AburridoVer
fuente