Chargement du système de A à Z

Ce n'est pas un tutoriel, mais juste quelques principes pour avoir des repères : qui fait quoi ? et où ? et à quel moment ?…

Je sépare cette partie du multiboot bien qu'elle ait un sérieux rapport avec ce sujet, mais un point de vue différent de la simple configuration de Grub.

Le sujet est intéressant parce qu'il peut y avoir des problèmes : de BIOS, de disque, de mémoire, de type de kernel, de configuation. Et depuis la mise sous tension du PC jusqu'au lancement du sytème, c'est une sacrée aventure !

Un peu complexe, parce que Linux doit pouvoir booter des kernels sur différents supports (Disque, CDroms, disquettes) sur différents types de BIOS et de processeurs (et donc de micros), sur différents types de disques, diiférentes partitions… avec ou sans l'ACPI, etc… (Du coup j'ai trouvé où pouvait se passer un vieux problème de EDD facilities avec mon BIOS) :

1. Quelques notions de bases

1. Le MBR

1. Le bootloader

1. La carte mémoire pour recevoir le MBR, le bootloader, le kernel et initrd (programmes et données)

1. Les différents types d'images de kernel et de protocoles de boot (Linux évolue)

1. La partie boot du kernel

1. Le chargement d'initrd (celui du boot)

1. Les options CMD LINE du kernel depuis grub ou en ligne de cde (bootsplash, vga, et bien d'autres…)

1. Le montage provisoire d'un sytème de fichier : initrd : ram disk pour monter le reste du sytème

1. Le chargement de la suite du kernel

1. Le lancement du kernel

1. Init du système et Initrd (celui du système).

1. La carte des périphériques

1. Run level 5

1. Run level 3

1. Analyse du journal de démarrage

1. Configuration du bootloader

1. Config de initrd (celui du boot)

1. Config du kernel

1. Config de initrd (celui du système)

Il ne s'agit pas d'un cours exhaustif sur les divers points abordés dans ce chapitre, mais de mettre en lumière les points où ils interviennent dans le processus.

C'est le programme de gestion de la carte mère. Pour fonctionner il utilise le chipset de la carte mère ( et non pas le processeur). Ce programme est gravé dans les Eprom et il utilise une RAM qui lui est propre.

Il assure l'interface entre l'OS et les périphériques. L'OS communique avec le BIOS gräce à des requètes réponses, normalisées.

Le programme du BIOS est “top secret” des fabricants de CM. Même si des versions sont disponibles pour ajouter des fonctionnalités au BIOS, ce programme en binaire exécutable est complètement indéchiffrable. Il est lié aux composants de la carte mère et aux chips des périphériques : secrets de fabrication également (conncurrence oblige).

Cependant le BIOS et l'OS ont besoin de données de base communes que le BIOS stocke au début de la mémoire RAM. Ceci n'étant pas suffisant, de nouveaux BIOS utilisent une zone complémentaire EBDA : Extended Bios Data Area, qui est parfois génante pour le boot…

Le BIOS est lancé automatiquement à la mise sous tension et affiche donc des informations sur le matériel et sur sa configuration : une étape de configuration à ne pas oublier.

Pour ce qui nous concerne, le BIOS parcourt dans l'ordre la liste des périphériques sur lequel il doit chercher un secteur de boot (MBR) pour lancer un sytème, y compris un sytème d'installation d'OS sur CDrom. Pour les disques, il choisit celui qui a été configuré comme bootable dans le BIOS.

Le BIOS n'assure pas le chargement d'un sytème, en mémoire, il ne charge que ce secteur de boot, limité à 512 octets, c'est très peu, trop peu pour y placer un programme capable de charger complètement un sytème.En plus le MBR, n'est pas capable d'adresser toute la mémoire disponible.

Il ne faut pas oublier que le BIOS est une antiquité… Aussi ce programme MBR, doit fonctionner quel que soit le type de processeur utlisé. Il faut donc faire simple.

Le BIOS, lorsqu'il achargé ce programme MBR dans un emplacement normalisé de la mémoire RAM, donne la main à ce programme qui s'éxécute dans le processeur.

C'est une machine infernale qui va éxécuter des instructions spécifiques en codées en binaire et traiter des données également codées en binaire : les deux étant stockées en mémoire. c'est à la construction du programme qu'on définit où sont les données et ouù commencent les instructions du programme.

Le processeur permet aussi de faire des opérations d'entrées sorties qui lui permettent de communiquer avec le BIOS qui les dirigera vers les périphs concernés.

Les processeurs évoulent progressivement : 8 bits pour les plus anciens, puis 16, 32 et enfin 64 bits. Mais puisque le MBR est commun à tous les types de processeurs, il ne travaille pas en 64 bits, ni en 32 bits, mais en 16 bits.

Les nouveaux processeurs disposent d'une fonctionnalité qui leur permet de travailler comme un vieux 8086 : en 16bits, et donc d'être compatibles avec des programmes écrits pour ce type de processeur, comme le MBR par exemple, ce qui limite considérablement ses possibilités d'adressage de la mémoire et du disque…

Le MBR va donc travailler sur les premières pages de la mémoire et n'est donc pas acapble de charger directement un système volumineux.

Il existe deux catégories :

• Le langage assembleur propre au processeur (voir la notice Intel ou AMD), qui sera assemblé pour être traduit en binaire exécutable.

• Les langages évolués (C, Pascal, Python, etc) indépendants et qui seront compilés pour chaque type de processeur.

Pour ce qui concerne le boot, c'est le langage assembleur qui a été retenu, car il est au plus près de la machine, (du processeur et du BIOS), et donc plus simple et moins volumineux qu'un programme en C où chaque ligne crée des dizaines d'instructions machine, alors qu'une seule suffit parfois en assembleur. Une grande partie du boot est écrite en assembleur pour être compatible avec les vieux processeurs. A cause du manque de place, elle est écrite pour un processeur 16 bits.

Lorsque vous lancez une application dans votre système, c'est un FICHIER binaire éxécutable par le processeur. Mais le sytème installé va aller le chercher avec le système de gestion de fichiers utlisé pour le disque ( NTFS, FAT, Ext3 ou reiserfs ) Mais, ce syrtème de gestion de fichiers qui fait partie du sytème est également un programme éxécutable, qui fait partie du sytème et donc chargé en mémouire pour fonctionner. Mais il es beaucoup trop sophistiqué et donc trop volumineux, mais aussi il marche avec le sytème qu'on a pas encore chargé.

Aussi on utilise pas les programmes de gestion de système de fichiers pour charger le sytème (mais on l'utilisera plus tard, lorsque le chargeent aura un peu avancé) pour l'instant on a une mémoire avec un programme qui contient 512 octets seulement…

Un adressage direct du disque pour aller chercher les infos qu'il contient dans ses secteurs (programme et données), dont on a besoin, avec deux modes d'adressage différents : CHS et LBA. Donc on ne parle pas de fichiers, mais de secteurs ou de blocks.

Il ne faut pas oublier que le DOS et windows travaillent en CHS (Win XP travaille en LBA, mais pas pour le boot), le CHS est très limité en adressage et Linux travaille en LBA.

Enfin sous linux, le chargeur Lilo, travaille enCHs, pour faire simple et GRUb travaille en LBA.

Toute la suite du boot dépend de cette nuance fondamentale, qui complique vraiment les choses, mais Grub est moins limité que Lilo, pour son installation sur un disque.

Chaque sytème d'exploitation et Lilo et grub ont leur propre MBR, pour commencer le chargement.

On ne peut pas parler de modes d'adressage CHS ou LBA , sans parler de géométrie de disque. C'est encore une chose à configurer dans le BIOS avant de faire une installation.

Pour charger un programme en adressant les secteurs du disque, il faut trouver son emplacement exact et donc utiliser la bonne géométrie lorsqu'on a des sytèmes différents qui utilisent LBA et d'autres le CHS, sinon on risque d'avoir des messages d'erreurs.

C'est ça !

Une suite de valeurs en hexa en correspondant à un programme binaire éxécutable et indéchiffrable !

C'est cette suite d'octets que le BIOS charge en mémoire, et ensuite il lance son exécution par le processeur.

Voici les 512 octets du secteur 0 d'un disque quelconque :

0x000: FA EB 21 01 B4 01 4C 49 4C 4F 16 05 4B 7E BD 41

0x010: 00 00 00 00 57 B9 E5 01 B3 5F B3 5F 81 00 80 60

0x020: DA 0B FF 01 B8 C0 07 8E D0 BC 00 08 FB 52 53 06

0x030: 56 FC 8E D8 31 ED 60 B8 00 12 B3 36 CD 10 61 B0

0x040: 0D E8 66 01 B0 0A E8 61 01 B0 4C E8 5C 01 60 1E

0x050: 07 80 FA FE 75 02 88 F2 BB 00 02 8A 76 1E 89 D0

0x060: 80 E4 80 30 E0 78 0A 3C 10 73 06 F6 46 1C 40 75

0x070: 2C 88 F2 66 8B 7E 18 66 09 FF 74 21 52 B4 08 B2

0x080: 80 CD 13 72 55 92 98 91 BA 7F 00 42 66 31 C0 40

0x090: E8 71 00 66 3B BF B8 01 74 03 E2 EF 5A 53 8A 76

0x0A0: 1F BE 20 00 E8 4B 00 B4 99 66 81 7F FC 4C 49 4C

0x0B0: 4F 75 27 5E 68 80 08 07 31 DB E8 35 00 75 FB BE

0x0C0: 06 00 89 F7 B9 0A 00 F3 A6 75 0D B0 02 AE 75 08

0x0D0: 06 55 B0 49 E8 D3 00 CB B4 9A B0 20 E8 CB 00 E8

0x0E0: B8 00 FE 4E 00 74 08 BC E8 07 61 60 E9 60 FF F4

0x0F0: EB FD 66 AD 66 09 C0 74 0A 66 03 46 10 E8 04 00

0x100: 80 C7 02 C3 60 55 55 66 50 06 53 6A 01 6A 10 89

0x110: E6 53 F6 C6 60 74 58 F6 C6 20 74 14 BB AA 55 B4

0x120: 41 CD 13 72 0B 81 FB 55 AA 75 05 F6 C1 01 75 4A

0x130: 52 06 B4 08 CD 13 07 72 59 51 C0 E9 06 86 E9 89

0x140: CF 59 C1 EA 08 92 40 83 E1 3F F7 E1 93 8B 44 08

0x150: 8B 54 0A 39 DA 73 39 F7 F3 39 F8 77 33 C0 E4 06

0x160: 86 E0 92 F6 F1 08 E2 89 D1 41 5A 88 C6 EB 06 66

0x170: 50 59 58 88 E6 B8 01 02 EB 02 B4 42 5B BD 05 00

0x180: 60 CD 13 73 10 4D 74 0A 31 C0 CD 13 61 4D EB F0

0x190: B4 40 E9 45 FF 8D 64 10 61 C3 C1 C0 04 E8 03 00

0x1A0: C1 C0 04 24 0F 27 04 F0 14 40 60 BB 07 00 B4 0E

0x1B0: CD 10 61 C3 00 00 4A 7C B3 5F B3 5F 00 00 00 01

0x1C0: 01 00 07 0F FF FF 3F 00 00 00 B1 8D 38 01 80 0F

0x1D0: FF FF 83 0F FF FF 3B 8B 38 01 FC 08 FA 00 00 0F

0x1E0: FF FF 0F 0F FF FF 37 94 32 02 29 04 96 00 00 00

0x1F0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 AA

Cette suite d'octets comprend des données et des instructions.

Parmi les données, on retrouve : la description de la première partition primaire, de la deuxième, de la troisième, de la quatrième et la signature de fin du MBR.

L'emplacement de ces données ainsi que leur structure sont normalisés et tous les OS doient les respecter.

Pour le programme ça dépend si c'est un MBR windows, un MBR Grub ou un MBR Lilo.

Dans ce sujet, je ne traite que Grub, car c'est le LE CHARGEUR UNIVERSEL, capable de booter des OS exotiques…

Du MBR on sait deux choses, son emplacement en mémoire déterminé par le BIOS et normalisé et son adresse de lancement : le début du programme (il ne commence pas à l'adresse 00 00 du programme ci dessus. Elle est aussi normalisée, puis que c'est le BIOS qui effectue le branchement et elle est donc la même pour tous les types de chargeur).

Voici les différentes zones de la mémoire, utilisées pour l'instant, lorsque le BIOS a chargé le MBR. (tout le reste est à zéro depuisla mise sous tension du PC).

00100  +-------------------------+

. |....Reserved for MBR/BIOS.....|

. |..............................|

000800 +-------------------------+

. |....Typically used by MBR.....|    Zone utilisée pour le MBR

. |..............................|

000600 +-------------------------+

. |....BIOS use only.............|    <- Mémoire utilisée par le BIOS

. |..............................|

000000 +-------------------------+  

Le BIOS intalle stage1 à partir de : 000600 jusqu'à 0007FF dans la mémoire, donc la section: Typically used by MBR qui n'occupe pour l'instant que 512 octets.

Avant d'aller plus loin dans le fonctionnement du MBR, tout de suite un truc important :

Lorsque vous faites une install, vous créez des partitions : le partitionneur les enregitre dans la table des partions sur le premier secteur du disque à une place pariticulière. Donc on ne peut pas simplement copier le programme binaire d'un aurtre disque sur cet emplacement pour avoir un MBR tout neuf, parce qu'on va écraser la table des partitions de ce disque… : Bingo !

L'installation d'un chargeur demande donc cette manip faite à l'install de Grub :

Lire le table des partitions existantes, la copier à sa place dans le fichier binaire du MBR ailleurs sur le disque, et de recoller le tout sur le premier secteur du disque.

Si on a fait une sauvegarde du MBR sur disquette et qu'on a pas modifié entre temps la table des partitions primaires, on peut la copier telle quelle sur le disque, sinon c'est la cata assurée…

MBR = mini programme de chargement + table des partitions

Avec Grub on appelle le MBR : stage 1 : première étape du boot !

Trouver sur le disque la suite du chargeur : stage 2, et le charger en mémoire.

Pour celà, il utilise l'adressage en secteurs du disque, aussi il passe le plus clair de son temps à vérifier la géométrie du disque pour trouver stage2 quelque part sur le disque.

Avec les paquetages source de grub qui sont compiliés à l'installation de Grub.

Le répertoire ses sources de stage 1 contient ces fichiers :

/grub-0.95/stage1/Makefile.in

/grub-0.95/grub/ Makefile.am

grub-0.95/stage1/stage_1.h

grub-0.95/stage1/stage_1.S

Les deux premiers sont les fichiers nécessaires pour lancer la compilation et l'assemblage des programmes sources.

Les deux suivants sont le programme source pour fabriquer le binaire stage 1

Un fichier en source en langage C : grub-0.95/stage1/stage_1.h, qui va fixer les adresses standards du boot ( celles du BIOS)

Un fichier source en assembleur : le programme stage 1 lui même : grub-0.95/stage1/stage_1.S

Il existe une autre méthode pour fabriquer stage 1 et l'installer :

Grub est une application à part entière dans Linux et lorsque le système tourne, on peut lancer grub et lui donner la cde install. Il va donc créer le stage 1 en binaire pour cette installation.

Le source de stage 1 est plus compréhensible que le programme binaire pur, et grace aux commentaires du source on peut comprendre un peu plus ce qu'il fait :

Vous retrouverez facilement qu'il charge stage 2 :

• la suite du chargeur (bootloader ) à l'addresse mémoire 0001000

• le lance à l'adresse 0007C00.

La place reservée pour stage 2 allant de 0001000 à 0010000, ce nouveau chargeur en mémoire pourra faire plus de choses, que le petit MBR et entre autres afficher un menu de boot sur l'écran, mais aussi un mode intercactif avec des cdes en ligne.

On ne lance pas le programme avec une cde start, ou un run, et le nom du fichier, mais avec un instruction de saut jmp (jump) à telle adresse en mémoire, et le programme de boot se poursuit.

On se retrouve ainsi avec cette carte mémoire à la fin de l'éxécution de stage 1 :

010000 +------------------------+

|...............................|    Boot sector entry point 0000:7C00

|...............................|

|...........stage 2.............|    

|...............................|

|...............................|

001000 +------------------------+

|...............................|

|....Reserved for MBR/BIOS......|

|...............................|

000800 +------------------------+

|...............................|

|... Typically used by MBR......|    <- Stage 1

|...............................|

000600 +------------------------+

|...............................|

|...... BIOS use only...........|    <- Mémoire utilisée par le BIOS

|...............................|

000000 +------------------------+

Vous allez bientôt pouvoir choisir le sytème que vous voulez lancer.

Stage 2 c'est un gros morceau… Le paquetage source contient énormément de fichiers… et stage 2 a une architecture plus modulaire.

Il se charge en deux temps :

• La première fois on l'a vu, c'est stage 1 qui charge ses deux premiers secteurs.

• Ensuite stage 1 lui passe la main et stage 2 continue à se charger.

• Charger le kernel et initrd du sytème qu'un a choisi si c'est un Linux qu'on veut lancer.

• Ou passer la main au chargeur de windows, seul capable de charger un système windows. ( chacun son job !) avec la cde chainloader

• Ou bien aussi passer la main à un autre chargeur Grub ou lilo ou autre, installé sur un autre disque (toujours avec la cde chainloader..).

Ensuite stage 2 aura besoin de connaître et de gérer les partitions pour accéder au kernel et à l'initrd du sytème qu'on veut lancer . Il lui faut donc un petit programme de gestion des systèmes de fichiers.. Ce sont tous les stage 1.5 (un par type de système de fichier qu'on peut rencontrer sous Linux, Unix et Windows.)

Grub utilise deux fichiers de configurations qui sont créés lors de son install : device.map, et menu.list

Rappel : Le kernel, c'est le noyau de Linux, qui sera toujours présent en mémoire : le minimal.

Le sytème linux pour fonctionner a besoin d'autres programmes qui sont situés dans les répertoires de la partition : / il faut donc “installer” ces répertoires dans le sytème.

Aussi on va avoir recours à initrd, de façon momentanée. C'est un ramdisk initial : autrement dit un gestionnaire de disque stocké en mémoire et capable de gérer le système de fichiers qu'on lui a indiqués lors de sa configuration ( c'est Yast qui le fait pour vous à l'instal du système ), juste pour intégrer les répertoires supplentaires de la /, dans le système, après on en a plus besoin, et on le vire.

Aussi stage 2 va charger initrd et le kernel.

Pour garder une idée des tailles de tous ces porgrammes chargés en mémoire :

• stage 1 : 512 octets

• stage 2 : 105 ko

• le kernel : 1,5 Mo

• initrd : 1,5 Mo

Mais pour le kernel et initrd ce sont des images compressées chargées en mémoire et qui seront décompressés ensuite en mémoire.. Le format de compression a évolué au fil du temps et il existe trois formats d'images ..

Aussi le kernel se charge en deux temps… (un peu comme stage 2) autrement dit stage 2 va charger la première partie (kernel boot sector) et ensuite le kernel va se charger lui même et se décompresser tout seul, avant de se configurer et de se lancer.

Ainsi la carte mémoire devient celle ci, et stage 2 va charger une partie du kernel selon cette carte mémoire. Elle est plus ou moins imposée, et une des préoccupations majeure de l'installation du kernel est de déterminer la place libre en fonction des zones déjà occupée ou des zones reservées.

Il est indispensable d'avoir ces notions d'install du kernel en mémoire pour comprendre ce que fait stage2.

Par exemple dans la commande kernel de menu.lst vous pouvez passer des paramètres au kernel. C'est donc stage 2 qui les fournit et les charges dans la zone prédeterminée cmdline.

On reviendra donc à stage 2 plus tard.

0A0000 +------------------------+

|......Reserved for BIOS........| Reserved for BIOS EBDA.: Extended Bios Data Area

|...............................|

09A000 +------------------------+

|......Stack/heap/cmdline.......| Zone utilisée par le kernel real-mode code.

|...............................| 8192 octets

098000 +------------------------+

|...............................| The kernel real-mode code.

|......Kernel setup.............| ( pas encore déchiffré cette zone )

|...............................|

|...............................|

090200 +------------------------+

|......Kernel boot sector.......| Le secteur de boot du kernel sera chargé ici .

090000 +------------------------+

|...............................| The bulk of the kernel image.

|...............................|

|......Protected-mode kernel....| ( pas encore déchiffré cette zone )

|...............................|

|...............................|

|...............................|

010000 +------------------------+

|...............................| C'est ici que stage 2 tourne en mémoire

|......Stage2...................| pour charger le kernel

|...............................| selon la carte mémoire imposée ci dessus.

001000 +------------------------+

|......Reserved for MBR/BIOS....|

000800 +------------------------+

|......Stage 1..................|

000600 +------------------------+

|......BIOS use only............| <- zone mémoire utilisée par le BIOS

000000 +------------------------+

Si vous avez la curiosité de regarder dans les sources du kernel installé :

file:/usr/src/linux-2.6.8-24.14/arch/i386/

Il y a un répertoire arch pour compiler le kernel selon les différentes architectures urtilisables, et surtout un répertoire boot Ce répertoire boot contient les sources nécessaires pour l'install du kernel, selon les règles précitées et définies par le concepteur de Linux.

Le kernel de Linux, ce n'est pas un grosse vache qu'on charge d'un seul coup en mémoire ! Il se charge et s'autocomplète, s'autoconfigure par étapes. C'est donc le rôle de ce répertoires de fichiers sources /boot.

Il ne faut pas oublier qu'on peut mettre un minikernel sur disquette, ce qui complique un peu plus les programmes d'install. C'est aussi le même sytème qui a évolué en fonction des évolutions du noyau et des PC…

Voici la liste de ces fichiers sources qui servent à la compilation du kernel et à son chargement en mémoire :

-rw-r--r--  1 root root  2157 2004-08-14 07:36 bootsect.S

drwxr-xr-x  2 root root  4096 2005-04-11 17:54 compressed

-rw-r--r--  1 root root  5200 2004-08-14 07:36 edd.S

-rw-r--r--  1 root root   974 2004-08-14 07:37 install.sh

-rw-r--r--  1 root root  3744 2005-03-29 14:26 Makefile

-rw-r--r--  1 root root   330 2004-08-14 07:36 mtools.conf.in

-rw-r--r--  1 root root 26013 2005-03-29 14:26 setup.S

drwxr-xr-x 2 root root 4096 2005-04-11 17:54 tools

-rw-r--r-- 1 root root 40429 2005-03-29 14:26 video.S

progr@ip-10:/usr/src/linux-2.6.8-24.14/arch/i386/boot>

Ils gèrent principalement l'emplacement mémoire et le BIOS pour l'implantation du kernel…

Stage 2 va travailler en fonction de ça puisqu'il charge l'image du kernel par étape, image qui a été créée lors de la compil du kernel.