SuSE Linux: des versions à partir de 6.3
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.
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.
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.
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é.
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.
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
:
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).
à l'aide de :
loadlin <kernelimage> initrd=C:\linux\initrd <parameter>
saisissez la ligne suivante dans syslinux.cfg
append initrd=initrd <autres paramètres>
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.
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.
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
!
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.
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.
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
.
/usr/src/linux/Documentation/ramdisk.txt
/usr/src/linux/Documentation/initrd.txt