Como o Linux / xBSD foi inicializado antes do GRUB?

23

Segundo a Wikipedia , o GRUB foi lançado em 1995. Nesse ponto, o Linux e o xBSD existiam há vários anos. Eu sei que as primeiras versões do Unix estavam ligadas ao hardware nos anos 70 e 80, mas o Linux e o xBSD estavam livres para distribuir e instalar. O que levanta a questão: como você inicializaria o Linux naquela época? As distribuições estavam sendo enviadas com suas próprias implementações de gerenciadores de inicialização?

boot-loader history

— Sergiy Kolodyazhnyy
fonte

32

Umm ... Você não estava por perto quando o LILO era o único gerenciador de inicialização do Linux? E nunca usei o LILO nem o Grub nos meus sistemas BSD. Em qual você está interessado? Veja por exemplo biosboot(8).

— Kusalananda

8

@ Kusalananda Infelizmente, eu me importava mais com brinquedos e desenho de Tartarugas Ninja do que com cachimbos, executivos e conchas naquela época :) Estou interessado na história geral, não no gerenciador de inicialização específico. Na página que você vinculou, vejo o OpenBSD biosbootpara duas arquiteturas, i386 e amd64. Isso significa que o OpenBSD teve que visar especificamente as arquiteturas em vez de ter uma ferramenta unificadora?

— Sergiy Kolodyazhnyy 07/01

1

O carregador de inicialização de primeiro estágio seria diferente para cada arquitetura (apenas o i386 e o amd64 têm um BIOS "BIOS" de qualquer maneira). Dê uma olhada no NetBSD se você estiver interessado em arquiteturas mais exóticas do que o PC padrão.

— Kusalananda

3

@ Kusalananda Acho que o LILO nunca foi o único gerenciador de inicialização do Linux. Até onde eu sei, o carregador incorporado nas imagens do kernel é anterior ao LILO, e quando o suporte ao carregador incorporado foi descontinuado, havia pelo menos alguns outros gerenciadores de inicialização.

— kasperd 7/01

2

O LILO era o gerenciador de inicialização padrão para muitas distribuições até o início dos anos 2000

— phuclv

51

A primeira distribuição Linux que eu usei nos anos 90 ( Slackware 3.0IIRC) usou o LILO como um gerenciador de inicialização. E muitas distribuições usadas LILOpor anos, mesmo quando GRUBestavam se tornando o gerenciador de inicialização "padrão".

Além disso, nos primeiros anos do Linux, era comum inicializar o Linux a partir de outro sistema operacional (por exemplo, DOS ou Windows), em vez de depender de um carregador de inicialização / inicialização dupla. Por exemplo, havia loadlin .

Não se esqueça do Syslinux , que é um carregador de inicialização mais simples, geralmente usado para distribuições de instalação / recuperação auto-inicializáveis por USB. Ou o Isolinux (do mesmo projeto) usado por muitas distros "Live".

Lembre-se de que hoje GRUBpode ser usado para carregar muitos sistemas operacionais, enquanto LILOera mais limitado e especificamente direcionado ao Linux (ou seja, LInux LOader), com algum suporte para inicialização dupla no Windows.
GRUBé muito útil para dupla de multi boot / por causa de suas muitas opções configuráveis, recursos de script, etc ...
Se você quer apenas um único sistema operacional em sua máquina "qualquer" (ou seja, qualquer que seja o bootloader é o padrão para a sua distribuição Linux / BSD) deve seja suficiente.

— Mr Shunz
fonte

5

@ MrShunz: não havia UEFI naquela época. Inicializar o Windows era apenas uma questão de adicionar uma entrada de, por exemplo, other=/dev/hda1com table=/dev/hdato lilo.conf, e o lilo apenas transferia o controle para o setor de inicialização no hda1, sabendo que a tabela de partição estaria no hda.

— ninjalj 7/01

2

Você costumava conseguir que o NTLDR carregasse o LILO; veja jaeger.morpheus.net/linux/ntldr.php ; Descobri o mesmo de forma independente, naquela época.

— Roger Lipscombe

2

A desvantagem da abordagem do LILO é que ela quebra se o local do disco dos arquivos para carregar mudar. Em particular, isso significa que o LILO precisava ser reescrito no local de inicialização (no setor de inicialização MBR ou de partição) após cada atualização do kernel.

— plugwash

1

@ plugwash: O GRUB tem o mesmo problema com seu arquivo de segundo estágio. A diferença aqui é que 1) o "segundo estágio" do LILO era o kernel, portanto, foram as atualizações do kernel, não as atualizações do LILO que quebraram as coisas; e 2) as atualizações do GRUB incluem uma reescrita automática do local do segundo estágio no MBR (com o segundo estágio carregando o kernel do Linux, com conhecimento completo do sistema de arquivos para que a localização do kernel não importe). ;-)

— DevSolar 8/01

1

Se possível, o grub IIRC armazenará um "estágio 1.5" que compreenda o sistema de arquivos entre o MBR e a primeira partição e só recorrerá ao armazenamento de uma referência a setores específicos do sistema de arquivos se não houver espaço para o estágio 1.5 (ou se estiver instalando no um setor de inicialização da partição em vez do MBR)

— plugwash 8/01

28

O LILO era o padrão de fato para inicializar o Linux em PCs antes do Grub, desde muito cedo (a MCC, uma das primeiras distribuições Linux, o utilizava). Vários outros gerenciadores de inicialização foram usados contemporaneamente. Loadlin era bastante comum; inicializou o Linux a partir do DOS e até foi usado em algumas configurações umsdospara hospedar um ambiente Linux em um sistema de arquivos DOS ... Outra configuração comum não envolveu um gerenciador de inicialização: o kernel pode se inicializar a partir de um disquete, e a maioria Os usuários do Linux mantinham um par conhecido de disquetes de “inicialização e raiz”, um contendo o kernel e o outro um sistema básico de arquivos raiz para fins de resgate.

Havia várias maneiras de usar os gerenciadores de inicialização de outros sistemas operacionais para inicializar o Linux também; por exemplo, o gerenciador de inicialização do OS / 2 ou o NTLDR do Windows NT.

Outros sistemas tinham seus próprios gerenciadores de inicialização:

SILO em SPARC (estações de trabalho Sun e outras);
PALO no PA-RISC (estações de trabalho HP);
YaBoot e Quik no PowerPC;
aBoot e MILO em Alpha ...

Ainda hoje em dia, o Grub não é o único gerenciador de inicialização que você verá. Embora a inicialização do kernel diretamente do disquete não seja mais muito útil (não verifiquei se ainda é possível, supondo que você possa construir um kernel pequeno o suficiente para caber em um disquete), ele pode inicializar diretamente do EFI (que é efetivamente seu próprio sistema operacional pequeno projetado para carregar outros sistemas operacionais, como o Grub). Em muitos sistemas menores (sistemas embarcados, computadores de placa única ...), você encontrará o U-Boot . (E também há uma camada EFI para U-Boot .)

— Stephen Kitt
fonte

A arquitetura PowerPC também é interessante porque algumas placas-mãe possuem um BIOS completo Turing - Openfirmware (basicamente a linguagem de programação Forth com algumas funções pré-instaladas). Isso permitiu a inicialização diretamente do BIOS sem o gerenciador de inicialização, se você souber como configurar o BIOS

— slebetman

Ei, apenas curioso, o NTLDR pode carregar o kernel do linux diretamente? Ouvi dizer que o NTLDR pode carregar o grub4dos em cadeia e depois carregar o kernel do linux.

— 炸鱼薯条

@slebetman: Mais precisamente, o OpenFirmware foi desenvolvido pela Sun para SPARC e, em seguida, adotado pela aliança PowerPC (IBM, Apple, Motorola) para a PowerPC Reference Architecture, e especificamente pela Apple para Macintoshs baseados em PowerPC. Um dos aspectos poderosos era que drivers simples podiam ser armazenados dentro de chips ROM nas placas de expansão ou em alguma área de inicialização designada de um HDD e, como eram escritos em bytecode contra uma ABI especificada conhecida, funcionariam independentemente de qual CPU arquitetura e sistema operacional que você estava tentando inicializar.

— Jörg W Mittag

Por exemplo, você pode ter um adaptador RAID com seu driver OpenFirmware dentro de um chip ROM, então o ambiente OpenFirmware pode usar esse driver para acessar o RAID, dentro do RAID, pode haver outro driver para o formato da tabela de partição, o que permitiria o ambiente OFW para encontrar as partições, no início de cada partição haveria um driver OFW para o sistema de arquivos, o que permitiria ao sistema OFW encontrar o kernel, e o kernel teria um pequeno carregador de inicialização escrito no bytecode OFW no início.

— Jörg W Mittag

O GRUB pode operar de maneira semelhante, mas a diferença é que todos esses drivers precisam ser escritos especificamente para o GRUB, enquanto a beleza do OFW era que o dispositivo traria seus drivers com ele, o que significa que mesmo os dispositivos que ainda não o fizeram existir quando o ambiente OFW foi escrito funcionaria "magicamente". O UEFI também pode operar de maneira semelhante, mas seu "formato portátil de bytecode" é essencialmente um subconjunto do DOS, que é a principal razão pela qual os Itaniums ainda precisam de um emulador x86.

— Jörg W Mittag

12

Até meados dos 2,6 kernels, o kernel x86 era inicializável diretamente se copiado para um disquete (como se fosse uma imagem de disco).

Essa era, de fato, a maneira original de inicializar o Linux.

Se você olhar o cabeçalho de um kernel x86 hoje, verá uma mensagem de erro dizendo que a inicialização a partir de disquetes não funciona mais.

— Joshua
fonte

2

Por outro lado, o kernel x86 agora é inicializável diretamente se fornecido a um firmware UEFI. Portanto, ainda há um carregador de inicialização de stub pregado na frente do kernel, apenas um tipo diferente ...

— grawity

@rawity: Tem certeza de que não quer dizer x64?

— Joshua

1

@ Josué: Eu não tenho certeza do que você quer dizer com isso. Na verdade, a EFI não executa esta parte como código.

— grawity

2

@Joshua what? É "DEC BP", "POP DX" no modo de 16 bits (EBP / EDX no modo de 32 bits). Mas não deve ser executado de qualquer maneira; Os binários EFI são arquivos PE (o que, obviamente, não importa se ele é gravado em um setor de inicialização ...).

— Stephen Kitt

1

@ Josué OK, mas isso não é um comportamento x86 indefinido em minha mente ;-). (Acho que do “comportamento x86 indefinido” como opcodes cujo comportamento não está definido, não indefinido comportamento plataforma.)

— Stephen Kitt

5

Comecei com o Linux no final dos anos 90 e, como mencionado, liloera o padrão. Se você quisesse a inicialização dupla com um sistema DOS, poderia fazer uma inicialização simples sem carregar coisas no HIMEM ou carregar drivers de CD, etc. e usá-la loadlin. Para a inicialização dupla do Win95, você pode tornar a unidade inicializável primeiro com o DOS, depois instalar o '95, e o carregador de inicialização do '95 permitirá que você inicialize o kernel do DOS ainda e, em seguida, use-o loadlin.

Para a inicialização dupla com o NT4, o truque era gravar o LILO na /partição, remover os primeiros 512 bytes usando dd( dd if=/dev/sda2 of=/path/to/file bs=512 count=1) e colocar o arquivo resultante onde ele ntldrpoderia ser visto e você poderia usá-lo no gerenciador de inicialização do WinNT. O problema é que, quando você atualizou seu kernel, lembre-se de repetir todas as etapas antes de reiniciar; caso contrário, você terá problemas para voltar ao sistema Linux. O mesmo processo funcionou com o Win2k.

Com o LILO, sempre que o kernel foi atualizado, você precisava se lembrar de atualizar o LILO.

A loadlinqualquer momento que o kernel era atualizado, você precisava se lembrar de copiar o kernel para a partição DOS.

Uma outra opção sugerida em outras respostas foi gravar o kernel diretamente em um disquete usando dd if=/path/to/vmlinuz of=/dev/fd0MAS O dispositivo raiz teve que ser configurado corretamente no kernel, em tempo de compilação ou usando o rdevutilitário.

Quando GRUBsurgiu, houve muita alegria porque você não precisou mais se lembrar de atualizar o LILO ou atualizar o LILO e remover novamente as informações de inicialização, etc. info ...

— ivanivan
fonte

Parece que foi muito trabalho e grandes chances de ser deixada com uma máquina que não inicializa naquela época, mas definitivamente uma experiência educacional

— Sergiy Kolodyazhnyy

@SergiyKolodyazhnyy sim, e não havia tanta informação na internet, nem os grandes mecanismos de busca para encontrá-la, se ela estivesse lá. Havia várias distribuições de recuperação de disquete que tinham Linux suficiente para inicializar e corrigir o LILO, etc. Percorremos um longo caminho!

— ivanivan

A execução make installseria executada /sbin/lilo, portanto você não precisava atualizar nada manualmente (e esse ainda pode ser o caso, se você tiver liloinstalado). Isso pode ser uma questão de opinião, mas não me lembro de muita alegria grub, pelo contrário. E lilo(pelo menos em sua versão de 1999), as janelas de inicialização dupla podem ficar bem, sem necessidade loadlin.

— mosvy 9/01

0

E antes do LILO e GRUB, era necessário iniciá-lo a partir da linha de comando com algum tipo de utilitário de carregador de inicialização personalizado.

Como exemplo, o Amiga tinha Linux disponível. Você tinha que usar um utilitário de linha de comando chamado amiboot para carregar o ELF do kernel na memória e pular para ele.

Aqui está um vídeo de alguém usando o amiboot na linha de comando para iniciar o linux em um Amiga 600 . Seu script StartInstall está chamando o executável de inicialização inicial. Você pode assistir uma inicialização do sistema configurando a memória, descobrir o endereço de carregamento desejado e passar parâmetros para o kernel por volta das 0:55.

— BoredBsee
fonte