Linux : Rôle et utilisation d’initrd

I. Présentation

On a tendance à l’oublier, et pourtant cette fonction de nos chères distributions Linux est essentielle. Je veux parler d’initrd. L’acronyme fait frémir. En fait il s’agit de l’abréviation de Initial RamDisk qui n’est rien d’autre qu’une image d’un système d’exploitation minimal, initialisé lors de la phase de démarrage du système lui-même.

Ce type de fichier utilise un système de fichiers un peu particulier, appelé CRamFS, squashfs, ou de façon plus systématique initramfs . En réalité, il s’agit d’un système de fichiers compressé, au format gzip et archivé via la commande cpio. Cette image est alors chargée en mémoire vive, et va permettre ainsi de disposer d’un système minimal, qui activera le système d’exploitation principal, ou des systèmes sans disques, appelés diskless.

RAPPEL : le noyau Linux ne pourrait plus, aujourd’hui, contenir l’ensemble du code de tous les périphériques et toutes les fonctionnalités nécessaires aux systèmes pour fonctionner. C’est pourquoi, les distributions compilent un noyau minimal possédant des options de base et elles chargent (ou déchargent), à volonté les modules noyaux obligatoires, contenus dans l’archive de l’initrd.

Donc, on le comprend, ce système de fichiers ou initramfs, comme il est souvent appelé sur des distributions de type Debian, est juste essentiel au bon fonctionnement des distributions GNU/Linux.

En bref, voici les différentes phases d’un démarrage Linux :

- Chargement du noyau Linux
- Chargement de l’initrd (passé alors en paramètre au noyau)
- Lancement du script linuxrc, chargeant les modules nécessaires au démarrage
- Lancement de la tâche init, sur le périphérique sélectionné

Cela signifie que sans l’initrd, les étapes 2 et 3 ne pourraient jamais fonctionner. En plus, le système d’exploitation principal ne disposerait pas de toutes ses fonctionnalités, puisque les modules n’auraient pas été chargés.

Toutefois, en cas de modification d’architecture disque, de partition ou matériel au niveau du système de démarrage, il est impératif de recréer l’initrd (ou initramfs), en mentionnant, le cas échéant le nom du fichier de partitions /etc/fstab :

# mkinitrd–-fstab=/etc/fstab /boot/initrd-$(uname –r).img $(uname –r)

Enfin, maintenant que l’on est tous convaincus de l’utilité de cette fonction, on peut peut-être explorer son contenu, voire même s’aventurer à le modifier. Juste une dernière chose, avant de passer à la pratique, le fichier initrd est généralement stocké dans le répertoire /boot, puisqu’il fait partie du matériel de démarrage et qu’il est passé en paramètre au noyau.

II. Limitations du fichier initrd

Bien que cette méthode d’installation lors de la phase de démarrage soit efficiente, elle présente tout de même quelques limitations.

En premier lieu, le fichier initrd est basé sur un périphérique bloc à part entière qui a besoin d’un système de fichiers complet pour fonctionner, et ce, avec une taille fixe. Si jamais, on choisit une taille trop petite, on ne pourra donc pas y stocker la totalité des scripts ou des modules nécessaires.

REMARQUE : d’ailleurs, dans l’autre sens, si l’on choisit une taille trop grande, on gaspille la mémoire, car une partie de l’espace alloué ne sera pas utilisé.

Mais, comme initrd est un périphérique statique, bien réel, il consomme de la mémoire cache au niveau du noyau Linux et est donc, de fait, en capacité de gérer les fichiers selon les méthodes traditionnelles des autres systèmes de fichiers : paging, swap…

Du coup, cela accroit notablement la consommation de mémoire du fichier initrd. Pour régler ces inconvénients, le système initramfs a remplacé le fichier initrd initial. Mais, les principes fondamentaux restent les mêmes.

III. Préparation de la manipulation sur initrd

Comme pour toute opération un peu compliquée, il est fortement conseillé de sauvegarder le fichier initrd sur lequel on va travailler. Une mauvaise manipulation est si vite arrivée !

# cd /boot
# cp –a initramfs-$(uname –r).img initramfs-current.sav

REMARQUE : sur certaines distributions, comme CentOS ou RedHat, le fichier initrd est créé avec le nom initramfs. Mais, il s’agit bien de la même entité initrd.

Ensuite, il faut créer un répertoire de travail, pour pouvoir facilement manipuler le contenu de l’initrd :

# mkdir /work/initrd
# cd /work/initrd

IV. Traitements sur initrd

On peut maintenant faire en sorte, en une seule opération, de décompresser l’initrd du répertoire /boot, dans le répertoire de travail précédemment préparé tout en développant l’archive cpio :

# gunzip –c /boot/initrds-$(uname –r).img | cpio –i

ATTENTION : par contre, si l’on manipule un fichier initramfs : ce qui est généralement le cas pour les distributions CentOS et RedHat en version supérieure à 6, il faut utiliser la commande ci-dessous pour décompresser l’archive initramfs :

# /usr/lib/dracut/skipcpio /boot/initramfs-$(uname –r).img|gunzip –c|cpio –i –d

À ce stade, dans le sous-répertoire /work/initrd, on peut alors découvrir l’intégralité du contenu du fichier initrd (ou initramfs) développé :

On peut alors modifier ce que l’on souhaite, avant de reconstituer l’archive compressée du fichier initrd.

# find * | cpio –o –H newc | gzip -9 –c > /boot/initrd-$(uname –r)-new.img

De même que pour la décompression, la reconstitution de l’archive d’un fichier initramfs passe par les commandes suivantes :

# cd /work/initrd
# find . | cpio --create --format=’newc’ > /tmp/initramfs-new
# cd /tmp
# gzip initramfs-new
# mv initramfs-new.gz /boot/initramfs-new.img

REMARQUE : si l’on est très à l’aise avec ces commandes, on peut, bien sûr, directement écraser le fichier initrd actuel, au lieu de créer un fichier –new. Sinon, il faut également penser à modifier le fichier menu.lst du chargeur au démarrage GRUB, dans le répertoire /boot/grub, afin d’ajouter une entrée pour ce nouveau fichier initrd, que l’on vient de générer.

V. Cas d’usage

La plupart du temps ce genre de modification va permettre d’intégrer un nouveau module noyau, au fichier initrd. C’est ce qui est pratiqué sur des distributions comme Ubuntu (ou Debian, de façon plus générale), car il n’y a alors qu’un fichier texte, contenant la liste des modules à intégrer au noyau du système principal, à modifier au niveau des éléments contenus dans le fichier initrd.

Philippe PIERRE

A exercé de nombreuses années en tant qu'administrateur de base de données et comme administrateur Système Unix/Linux. Il a enseigné les réseaux au CNAM (Paris). Aujourd'hui, employé en tant qu'ingénieur infrastructure, au sein d'un laboratoire pharmaceutique et administrant un cluster de calculs HPC, il connaît parfaitement les environnements GNU/Linux dans le cadre d'une entreprise et des systèmes de haute disponibilité. Il aime partager son expérience.

See Full Bio