Comment Linux / xBSD a-t-il démarré avant GRUB?

23

Selon Wikipedia , GRUB a été publié en 1995. À ce stade, Linux et xBSD existaient depuis plusieurs années. Je sais que les premières versions d'Unix étaient liées au matériel dans les années 70 et 80, mais Linux et xBSD étaient libres de distribuer et d'installer. Ce qui pose la question de savoir comment démarrer Linux à l'époque? Les distributions étaient-elles livrées avec leurs propres implémentations de chargeurs de démarrage?

boot-loader history

— Sergiy Kolodyazhnyy
source

32

Umm ... Vous n'étiez pas là quand LILO était le seul chargeur de démarrage Linux? Et je n'ai jamais utilisé LILO ni Grub sur mes systèmes BSD. Lequel vous intéresse? Voir par exemple biosboot(8).

— Kusalananda

8

@Kusalananda Malheureusement, je me souciais plus des jouets et des tortues ninja que des tuyaux, des cadres et des coquillages à l'époque :) Je m'intéresse à l'histoire générale, pas au chargeur de démarrage spécifique. Depuis la page que vous avez liée, je vois qu'OpenBSD a biosbootdeux architectures, i386 et amd64. Cela signifie-t-il qu'OpenBSD devait spécifiquement cibler les architectures au lieu d'en avoir un, un outil unificateur?

— Sergiy Kolodyazhnyy

1

Le chargeur de démarrage du premier étage serait différent pour chaque architecture (seuls i386 et amd64 ont un BIOS "bios" de toute façon). Jetez un œil à NetBSD si vous êtes intéressé par des architectures plus exotiques que le PC standard des marais.

— Kusalananda

3

@Kusalananda Je ne pense pas que LILO ait jamais été le seul chargeur de démarrage Linux. Autant que je sache, le chargeur intégré aux images du noyau est antérieur à LILO, et au moment où le support du chargeur intégré a été interrompu, il y avait au moins une poignée d'autres chargeurs de démarrage.

— kasperd

2

LILO était le chargeur de démarrage par défaut pour de nombreuses distributions jusqu'au début des années 2000

— phuclv

51

La première distribution Linux que j'ai utilisée dans les années 90 ( Slackware 3.0IIRC) utilisait LILO comme chargeur de démarrage. Et de nombreuses distributions ont été utilisées LILOpendant des années, même lorsqu'il GRUBdevenait le chargeur de démarrage "par défaut".

De plus, dans les premières années de Linux, il était courant de démarrer Linux à partir d'un autre système d'exploitation (c'est-à-dire DOS ou Windows) au lieu de compter sur un chargeur de démarrage / double démarrage. Par exemple, il y avait loadlin .

N'oubliez pas Syslinux , qui est un chargeur de démarrage plus simple souvent utilisé pour les distributions d'installation / récupération USB auto-amorçables. Ou Isolinux (du même projet) utilisé par de nombreuses distributions "Live".

Gardez à l'esprit qu'aujourd'hui GRUBpeut être utilisé pour charger de nombreux systèmes d'exploitation, alors qu'il LILOétait plus limité, et ciblait spécifiquement Linux (c'est-à-dire LInux LOader), avec une certaine prise en charge du double démarrage vers Windows.
GRUBest très utile pour le démarrage à double / multiple en raison de ses nombreuses options configurables, des fonctions de script, etc ...
Si vous voulez un seul système d' exploitation sur votre machine « any » (ie quel que soit bootloader est la valeur par défaut pour votre distribution Linux / BSD) devrait être assez.

— M. Shunz
source

5

@MrShunz: il n'y avait pas d'UEFI à l'époque. Le démarrage de Windows consistait simplement à ajouter une entrée, par exemple other=/dev/hda1avec table=/dev/hdaà lilo.conf, et lilo ne ferait que transférer le contrôle au secteur de démarrage à hda1, sachant que la table de partition serait à hda.

— ninjalj

2

Auparavant, vous pouviez obtenir NTLDR pour charger LILO; voir jaeger.morpheus.net/linux/ntldr.php ; J'ai découvert la même chose indépendamment, à l'époque.

— Roger Lipscombe

2

L'inconvénient de l'approche LILO est qu'elle se casse si l'emplacement du disque des fichiers à charger change. En particulier, cela signifie que LILO devait être réécrit dans l'emplacement de démarrage (MBR ou secteur de démarrage de partition) après chaque mise à niveau du noyau.

— plugwash

1

@plugwash: GRUB a le même problème avec son fichier de deuxième étape. La différence ici est que 1) la "deuxième étape" de LILO était le noyau, donc ce sont les mises à jour du noyau, et non les mises à jour de LILO qui ont cassé les choses; et 2) les mises à jour GRUB incluent une réécriture automatique de l'emplacement de la deuxième étape sur le MBR (avec la deuxième étape puis le chargement du noyau Linux, avec une connaissance complète du système de fichiers, l'emplacement du noyau n'a donc pas d'importance). ;-)

— DevSolar

1

IIRC grub stockera si possible une "étape 1.5" qui comprend le système de fichiers entre le MBR et la première partition et n'aura recours au stockage d'une référence à des secteurs de système de fichiers spécifiques que s'il n'y a pas de place pour l'étape 1.5 (ou s'il s'installe sur un secteur de démarrage de partition plutôt que le MBR)

— plugwash

28

LILO était la norme de facto pour le démarrage de Linux sur PC avant Grub, à un stade très précoce (MCC, l'une des premières distributions Linux, l'a utilisé). Divers autres chargeurs de démarrage ont été utilisés simultanément. Loadlin était assez courant; il a démarré Linux à partir de DOS et a même été utilisé dans certaines configurations avec umsdospour héberger un environnement Linux dans un système de fichiers DOS ... Les utilisateurs de Linux ont conservé une bonne paire de disquettes «boot et root», l'une contenant le noyau, l'autre un système de fichiers racine de base à des fins de sauvetage.

Il y avait plusieurs façons d'utiliser les chargeurs de démarrage d'autres systèmes d'exploitation pour démarrer Linux également; par exemple, le gestionnaire de démarrage d'OS / 2 ou le NTLDR de Windows NT.

D'autres systèmes avaient leurs propres chargeurs de démarrage:

SILO sur SPARC (postes de travail Sun et autres);
PALO sur PA-RISC (stations de travail HP);
YaBoot et Quik sur PowerPC;
aBoot et MILO sur Alpha ...

Même de nos jours, Grub n'est pas le seul chargeur de démarrage que vous verrez. Bien que le démarrage du noyau directement à partir d'une disquette ne soit plus très utile (je n'ai pas vérifié s'il est toujours possible, en supposant que vous pouvez créer un noyau suffisamment petit pour tenir sur une disquette), il peut démarrer directement à partir d'EFI (qui est en fait son propre petit système d'exploitation conçu pour charger d'autres systèmes d'exploitation, tout comme Grub). Sur de nombreux petits systèmes (systèmes embarqués, ordinateurs à carte unique ...), vous trouverez U-Boot . (Et il y a aussi une couche EFI pour U-Boot .)

— Stephen Kitt
source

L'architecture PowerPC est également intéressante car certaines cartes mères avaient un BIOS complet de Turing - Openfirmware (essentiellement le langage de programmation Forth avec quelques fonctions préinstallées). Cela a permis de démarrer directement à partir du BIOS sans chargeur de démarrage si vous savez comment configurer votre BIOS

— slebetman

Hé, juste curieux, NTLDR peut charger le noyau Linux directement? J'ai entendu dire que NTLDR peut charger grub4dos et charger le noyau linux.

— 炸鱼薯条德里克

@slebetman: Plus précisément, OpenFirmware a été développé par Sun pour SPARC puis adopté par l'alliance PowerPC (IBM, Apple, Motorola) pour l'architecture de référence PowerPC, et spécifiquement par Apple pour les Macintosh basés sur PowerPC. L'un des aspects puissants était que les pilotes simples pouvaient être stockés dans des puces ROM sur les cartes d'extension, ou dans une zone de démarrage désignée d'un disque dur, et comme ils étaient écrits en bytecode par rapport à un ABI spécifié connu, ils fonctionneraient quel que soit le CPU l'architecture et le système d'exploitation que vous tentiez de démarrer.

— Jörg W Mittag

Par exemple, vous pourriez avoir un adaptateur RAID qui a son pilote OpenFirmware à l'intérieur d'une puce ROM, puis l'environnement OpenFirmware pourrait utiliser ce pilote pour accéder au RAID, à l'intérieur du RAID, il pourrait y avoir un autre pilote pour le format de table de partition, ce qui permettrait à l'environnement OFW pour trouver les partitions, au début de chaque partition serait un pilote OFW pour le système de fichiers, ce qui permettrait au système OFW de trouver le noyau, et le noyau aurait un petit chargeur de démarrage écrit en bytecode OFW au début.

— Jörg W Mittag

GRUB peut fonctionner de la même manière, mais la différence est que tous ces pilotes doivent être écrits spécifiquement pour GRUB, alors que la beauté d'OFW était que le périphérique apporterait ses pilotes avec lui, ce qui signifie que même les périphériques qui ne l'ont pas encore fait exister lorsque l'environnement OFW a été écrit fonctionnerait tout simplement "par magie". UEFI peut également fonctionner de manière similaire, mais son "format de bytecode portable" est essentiellement un sous-ensemble de DOS, ce qui est la principale raison pour laquelle les Itanium ont toujours besoin d'un émulateur x86.

— Jörg W Mittag

12

Jusqu'au milieu des noyaux 2.6, le noyau x86 était directement amorçable s'il était copié sur une disquette (comme s'il s'agissait d'une image disque).

C'était, en fait, la façon originale de démarrer Linux.

Si vous regardez l'en-tête d'un noyau x86 aujourd'hui, vous voyez un message d'erreur indiquant que le démarrage à partir de disquettes de ce type ne fonctionne plus.

— Joshua
source

2

D'un autre côté, le noyau x86 est désormais directement amorçable s'il est donné à un firmware UEFI. Donc, il y a toujours un bootloader stub cloué devant le noyau, juste un type différent ...

— grawity

@grawity: Êtes-vous sûr de ne pas vouloir dire x64?

— Joshua

1

@Joshua: Je ne sais pas ce que tu veux dire par là. EFI n'exécute pas réellement cette partie en tant que code.

— grawity

2

@Joshua quoi? C'est «DEC BP», «POP DX» en mode 16 bits (EBP / EDX en mode 32 bits). Mais cela ne devrait pas être exécuté de toute façon; Les binaires EFI sont des fichiers PE (ce qui n'a bien sûr pas d'importance s'il est écrit dans un secteur de démarrage ...).

— Stephen Kitt

1

@Joshua OK, mais ce n'est pas un comportement x86 indéfini dans mon esprit ;-). (Je pense à «comportement x86 non défini» comme des opcodes dont le comportement n'est pas défini, pas un comportement de plate-forme non défini.)

— Stephen Kitt

5

J'ai commencé avec Linux à la fin des années 90 et comme mentionné, liloc'était la valeur par défaut. Si vous vouliez effectuer un double amorçage avec un système DOS, vous pourriez faire un amorçage nu sans charger des éléments dans HIMEM ou charger des pilotes de CD, etc. et utiliser loadlin. Pour le double démarrage de Win95, vous pouvez d'abord rendre le disque amorçable avec DOS, puis installer '95, et le chargeur de démarrage de '95 vous permettrait de démarrer le noyau DOS, puis vous pourriez utiliser loadlin.

Pour un double démarrage avec NT4, l'astuce consistait à écrire LILO sur la /partition, puis à supprimer les 512 premiers octets à l'aide de dd( dd if=/dev/sda2 of=/path/to/file bs=512 count=1) et à placer le fichier résultant où le ntldrvoir et vous pouvez l'utiliser à partir du chargeur de démarrage de WinNT. Le problème avec cela est que lorsque vous avez mis à niveau votre noyau, vous devez vous rappeler de répéter toutes les étapes avant de redémarrer, sinon vous auriez des problèmes pour revenir dans le système Linux. Le même processus a fonctionné avec Win2k.

Avec LILO, chaque fois que le noyau était mis à jour, vous devez vous rappeler de mettre à jour LILO.

À loadlinchaque fois que le noyau était mis à jour, vous deviez vous rappeler de copier le noyau sur la partition DOS.

Une autre option suggérée dans d'autres réponses était d'écrire le noyau directement sur une disquette en utilisant dd if=/path/to/vmlinuz of=/dev/fd0MAIS le périphérique racine devait être défini correctement dans le noyau, soit au moment de la compilation, soit en utilisant l' rdevutilitaire.

Quand il GRUBest arrivé, il y avait beaucoup de joie parce que vous n'aviez plus à vous rappeler de mettre à jour LILO, ou de mettre à jour LILO et de supprimer les informations de démarrage, etc. Info...

— ivanivan
source

On dirait que c'était beaucoup de travail et de grandes chances de se retrouver avec une machine sans démarrage à l'époque, mais certainement une expérience éducative

— Sergiy Kolodyazhnyy

@SergiyKolodyazhnyy oui, et il n'y avait pas une telle richesse d'informations sur Internet, ou les excellents moteurs de recherche pour le trouver s'il était là. Il y avait plusieurs distributions de sauvetage sur disquette unique qui avaient juste assez de Linux pour démarrer et réparer LILO, etc. Nous avons parcouru un long chemin!

— ivanivan

L'exécution make installs'exécuterait /sbin/lilo, vous n'avez donc pas vraiment eu à mettre à jour quoi que ce soit à la main (et cela peut toujours être le cas, si vous avez liloinstallé). C'est peut-être une question d'opinion, mais je ne me souviens pas de beaucoup de réjouissances grub, au contraire. Et lilo(au moins sa version de 1999) pourrait très bien double dual windows, pas besoin de loadlin.

— mosvy

0

Et avant LILO et GRUB, vous deviez le lancer à partir de la ligne de commande avec une sorte d'utilitaire de démarrage personnalisé.

Par exemple, l'Amiga avait Linux disponible. Vous avez dû utiliser un utilitaire de ligne de commande appelé amiboot pour charger l'ELF du noyau en mémoire et y accéder.

Voici une vidéo d'une personne utilisant amiboot depuis la ligne de commande pour lancer linux sur un Amiga 600 . Son script StartInstall appelle l'exécutable amiboot. Vous pouvez regarder amiboot configurer la mémoire, déterminer l'adresse de chargement souhaitée et passer les paramètres au noyau vers 0:55.

— BoredBsee
source