Amorcer avec le disque virtuel (RAM-disk) initial

Base de données support (initrd)

SuSE Linux: des versions à partir de 6.3

Problème :

Dès que le noyau Linux est monté et a monté le système de fichiers racine (de "root") ("/"), vous pouvez exécuter des programmes et charger des modules de noyau additionnels dans le but d'ajouter de nouvelles fonctionnalités.

Cependant, différentes conditions doivent être remplies pour pouvoir simplement monter le système de fichiers racine : le noyau nécessite les pilotes adéquats afin de pouvoir s'adresser aux différents périphériques et en particulier à celui sur lequel se trouve le système de fichiers racine (surtout les pilotes SCSI). En outre, le noyau doit contenir le code nécessaire à la lecture du système de fichiers racine (ext2, reiserfs, romfs, etc.). Par ailleurs, il est possible que justement le système de fichiers racine soit chiffré ; dans ce cas, la saisie du mot de passe ou de la clé est nécessaire pour pouvoir monter le système de fichiers.

Si l'on considère uniquement le problème des pilotes SCSI, plusieurs solutions sont envisageables : le noyau peut déjà contenir tous les pilotes possibles. Ceci est problématique parce que certains pilotes peuvent être incompatibles et interférer les uns avec les autres. En outre, le noyau devient alors très gros. Une autre possibilité est de mettre à disposition plusieurs noyaux, chacun contenant un seul ou un nombre réduit de pilotes SCSI. Cependant, cette possibilité pose également problèmes car elle nécessite un nombre important de noyaux différents. Ces problèmes sont encore accrus par l'utilisation de différents noyaux optimisés (optimisé Pentium, SMP, etc.).

La solution qui consiste à monter les pilotes SCSI en tant que module est également problématique ; cependant, le problème peut être réglé par le concept du disque virtuel initial (initial ramdisk) : la création d'une méthode pour exécuter les programmes de l'espace utilisateur avant d'avoir procédé au montage du système de fichiers racine.

Concept du disque virtuel initial (initial ramdisk)

Le disque virtuel initial ou initial ramdisk, il s'agit d'un disque RAM initialisé au démarrage du système, (également appelé initdisk ou bien encore initrd) est en fait la simulation d'un lecteur de disquettes en mémoire vive et permet de résoudre les problèmes décrits ci-dessus : le noyau Linux offre la possibilité de charger un (petit) système de fichiers sur un disque virtuel et, à partir de là, d'exécuter des programmes avant que le système de fichiers racine n'ait été chargé. Le chargement du disque virtuel initrd sera exécuté par un chargeur d'amorçage (LILO, loadlin, etc.) ; tous ces chargeurs d'amorçage peuvent se contenter des routines BIOS pour charger des données depuis un support d'amorçage. Lorsque le chargeur d'amorçage peut charger le noyau, il peut également charger le disque virtuel initial (initial ramdisk). En conséquence, aucun pilote spécial n'est nécessaire.

Description de la procédure d'amorçage avec initrd

Le chargeur d'amorçage charge le noyau et initrd dans la mémoire et démarre le noyau tout en l'informant de la présence de initrd et de sa position dans la mémoire.

Si initrd était compressé (ce qui est généralement le cas), le noyau le décompresse et le monte sur le système de fichiers racine temporaire. Après cela, un programme nommé linuxrc sera démarré dans initrd. Ce programme peut procéder à toutes les opérations nécessaires pour monter le véritable système de fichiers racine. Une fois que linuxrc est terminé, le disque virtuel (temporaire) initrd est démonté et la procédure d'amorçage sera alors normalement effectuée avec le montage du véritable système de fichiers racine. Le montage de initrd et l'exécution de linuxrc peuvent ainsi être considérés comme un petit intermède durant la procédure normale d'amorçage.

En fait, le noyau tente de monter le disque virtuel initial sur /initrd. Dans le cas où cela s'avère impossible, le noyau tente de démonter initrd.

linuxrc

Le programme linuxrc dans le disque virtuel initrd doit simplement satisfaire aux conditions suivantes : il doit absolument porter le nom spécial linuxrc et doit être situé dans le répertoire racine de initrd. En outre, il doit être uniquement exécuté par le noyau. Ceci signifie que linuxrc peut tout à fait être l'objet de liens dynamiques. Cependant, dans ce cas, les bibliothèques partagées doivent bien entendu être disponibles dans leur intégralité sous /lib dans le disque virtuel initrd. En outre, linuxrc peut également être un script shell ; dans ce cas, l'existence d'un terminal dans /bin est, bien entendu, nécessaire. En résumé, initrd doit contenir une système Linux minimal qui permette l'exécution du programme linuxrc. Linuxrc nécessite les permissions "root" pour être exécuté.

Le véritable système de fichiers racine

Une fois que linuxrc est terminé, le disque virtuel (temporaire) initrd est démonté et écarté et la procédure d'amorçage continue normalement, le noyau procédant au montage du véritable système de fichiers racine. linuxrc peut déterminer et modifier ce qui sera monté en tant que système de fichiers racine. À cette fin, linuxrc doit simplement monter le système de fichiers /proc et enregistrer la valeur du véritable système de fichiers racine sous forme numérique dans /proc/sys/kernel/real-root-dev.

Chargeur d'amorçage

La plupart des chargeurs d'amorçage (et en particulier LILO, loadlin et syslinux) peuvent fonctionner avec initrd. Chacun des chargeurs d'amorçage sont ainsi avisés d'utiliser un disque initrd :

1. LILO

en saisissant la ligne suivante dans le fichier /etc/lilo.conf :

initrd=/boot/initrd

Le fichier "/boot/initrd" est le disque virtuel initial. Il peut être compressé (cependant, cela n'est pas nécessaire).

2. loadlin.exe

à l'aide de :

loadlin <kernelimage> initrd=C:\linux\initrd <parameter>

3. syslinux

saisissez la ligne suivante dans syslinux.cfg

append initrd=initrd <autres paramètres>

Utilisation de initrd dans le cas de SuSE

Installation du système

Le disque virtuel initrd est utilisé depuis déjà relativement longtemps pour les installations : ainsi, l'utilisateur peut charger des modules dans linuxrc et y saisir les paramètres nécessaires à une installation (comme, par exemple, le support d'installation). Linuxrc démarre alors YaST, qui procède à l'installation. Lorsque YaST a effectué son travail, il informe linuxrc où le système de fichiers racine du système nouvellement installé se situe. Linuxrc enregistre cette valeur dans /proc, se termine, puis le noyau redémarre dans le système nouvellement installé.

Ainsi, lors de l'installation de SuSE Linux, le système qui vient d'être installé, est quasiment démarré dès le départ. Un véritable redémarrage après l'installation arrive uniquement lorsque le noyau en fonctionnement est incompatible avec les modules qui ont été installés dans le système. Étant donné que SuSE Linux utilise actuellement un noyau pour système uni-processeur, cela n'arrive que lorsqu'un noyau SMP et les modules correspondants sont installés dans le système. Le noyau SMP nouvellement installé dans le système doit doit donc être démarré afin de pouvoir utiliser tous les modules.

Amorçage du système installé

Dans le passé, YaST offrait au système plus de 40 noyaux disponibles pour l'installation pour lesquels la principale différence réside dans le fait que chacun dispose d'un noyau SCSI différent. Ceci était nécessaire pour pouvoir monter le système de fichiers racine après le démarrage. Il était alors possible de charger d'autres modules.

Cependant, étant donné qu'il existe maintenant des noyaux optimisés, ce concept n'est plus applicable (entre temps, plus de 100 images seraient nécessaires).

En conséquence, nous utilisons maintenant initrd également pour le démarrage normal du système. Le mode de fonctionnement est semblable à celui d'une installation. Cependant, le linuxrc employé ici n'est qu'un simple script shell qui a uniquement pour mission de charger quelques modules bien déterminés. Il s'agit en fait d'un seul module, pour être précis, du pilote SCSI qui est nécessaire pour l'accès au système de fichiers racine.

Création d'un disque initrd

On procède à la création d'un disque initrd à l'aide du script mk_initrd. Les modules à charger se trouvent, dans le cas de SuSE Linux sous la variable INITRD_MODULES dans /etc/rc.config. Après une installation, la valeur correcte est automatiquement "pré-attribuée" à cette variable (l'outil d'installation linuxrc sait quels modules ont été chargés). Il faut d'ailleurs remarquer que les modules sont chargés dans l'ordre exact dans lequel ils apparaissent dans INITRD_MODULES. Ceci est particulièrement important lorsque plusieurs pilotes SCSI sont utilisés ; dans le cas contraire, la dénomination des disques pourrait être altéré. Il serait en fait suffisant de charger uniquement le pilote SCSI en question, celui qui est nécessaire à l'accès au système de fichiers racine. Cependant, étant donné que le chargement automatique de pilotes SCSI supplémentaires peut être problématique, nous effectuons le chargement de tous les pilotes SCSI lors de l'installation à l'aide de initrd.

Le mk_initrd actuel vérifie si un pilote SCSI est absolument nécessaire pour l'accès au système de fichiers racine. Si on exécute mk_initrd sur un système dans lequel / se trouve sur un disque EIDE, il ne procède pas à la création d'un disque virtuel initrd, car, dans ce cas, cela n'est pas nécessaire, étant donné que les noyaux utilisés par SuSE contiennent déjà un pilote EIDE. Cependant, étant donné que toujours plus de contrôleurs EIDE spéciaux apparaissent sur le marché, il sera vraissemblablement nécessaire dans le futur de recourir aussi pour ces cas à un disque initrd pour l'amorçage du système installé.

Important : étant donné que le chargement du disque initrd par le chargeur d'amorçage se déroule exactement de la même façon que le chargement du noyau lui-même (LILO prend note de la position des fichiers dans son fichier carte (map-file)), il faut réinstaller LILO après chaque modification du disque initrd ! Ainsi, après l'exécution d'un mk_initrd il est toujours nécessaire de procéder à un lilo !

Erreurs et problèmes avec SuSE Linux 6.3

Noyaux auto-compilés

Si vous compilez vous-même votre noyau, cela peut découler sur le problème suivant : par habitude, le périphérique SCSI sera intégré au noyau, cependant, le disque initrd demeure inchangé. Lors de l'amorçage, ceci se produit : le noyau contient déjà un pilote SCSI, le matériel est reconnu. Le disque initrd tente alors de charger encore une fois le pilote, cette fois-ci, en tant que module ; ceci conduit, dans le cas de certains pilotes SCSI (en particulier dans le cas du aic7xxx) au blocage du système. Il s'agit en fait d'une erreur du noyau (un pilote déjà présent ne devrait pas pouvoir être chargé à nouveau en tant que module), le problème est cependant connu dans un autre contexte (pilotes en série).

Il existe plusieurs solutions à ce problème : ou bien le pilote est configuré en tant que module (ainsi il sera chargé correctement dans le disque initrd), ou bien l'entrée pour le disque initrd doit être supprimé de /etc/lilo.conf. L'équivalent de cette dernière solution est de supprimer le pilote de INITRD_MODULES puis d'exécuter mk_initrd, qui remarquera alors qu'un disque initrd n'est pas nécessaire.

Paramètres de module

Si la saisie de paramètres est nécessaire au chargement d'un certain module, ceux-ci seront perdus après l'installation ; ils ne seront pas enregistrés sur le disque initrd utilisé pour l'amorçage du système. Heureusement, il n'existe que très peu de pilotes SCSI qui nécessitent absolument la saisie de paramètres. Si vous deviez rencontrer ce problème, démarrez votre système avec la disquette d'amorçage de l'installation et compilez un noyau qui contienne le pilote SCSI.

Le problème a été entre temps résolu ; avec SuSE Linux 6.4, les paramètres de module sont également utilisés dans le disque initrd lors du démarrage du système.

Pilotes de réseau dans le disque virtuel initrd

Si des pilotes de réseau sont chargés lors de l'installation, ils sont également enregistrés dans INITRD_MODULES et ainsi, chargés dans le disque virtuel initrd lors du démarrage du système. Bien que ceci ne soit pas une erreur en soi, cela peut cependant, dans certains cas, conduire à des problèmes :

1. Cartes compatibles NE2000 : le pilote pour ces cartes nécessite un module additionnel (8390.o). Cependant, les dépendances du module ne sont pas encore prises en compte, en conséquence, le chargement du module ne.o ne fonctionnera pas. Étant donné que plus tard lors la configuration du réseau, le chargement du pilote de réseau, sera géré par kerneld (et cette fois-ci, les dépendances seront prises en compte grâce à l'utilisation de "modprobe"), il ne s'agit en fait que d'un problème purement cosmétique : le premier chargement échoue avec un message d'erreur, le deuxième chargement, lui, sera réalisé avec succès étant donné que l'alias eth0=ne dans /etc/modules.conf a été correctement entré.

2. Forçage de certains paramètres de configuration : s'il s'avère nécessaire de forcer une carte réseau en mode full-duplex ou si un type bien précis de média doit être utilisé (par exemple dans le cas d'un pilote tulip à travers le paramètre options=xxx), cela ne fonctionne pas, car, comme décrit ci-dessus, les paramètres utilisés lors de l'installation ne sont plus utilisés par la suite.

Entre temps, ces problèmes ont également été résolus. D'une part, les paramètres de module seront, à l'avenir, correctement utilisés après l'installation, d'autre part, l'outil d'installation linuxrc ne sauvegarde maintenant que les seuls pilotes SCSI dans INITRD_MODULES.

Informations complémentaires :

/usr/src/linux/Documentation/ramdisk.txt
/usr/src/linux/Documentation/initrd.txt


Voir aussi:
o Concept d'amorçage à partir de SuSE Linux 6.3

Mots-clés: BOOT, AMORCER, INITRD, RAMDISK, RAM-DISK, RAM-DISQUE, DISQUE VIRTUEL, VFS, SCSI, LILO, LOADLIN

SDB-initrd, Copyright SuSE Linux AG, Nürnberg, Germany - Version: 07. Mai 2002
SuSE Linux AG - Dernière modification: 14. Mai 2002 de ip (sdb_gen 1.40.0)