Le disque virtuel initial (initrd) est généralement une version allégée du système de fichiers racine contenant uniquement ce qui est nécessaire pour monter le système de fichiers racine réel et lui abandonner le démarrage.
L'initrd existe parce que dans les systèmes modernes, le chargeur de démarrage ne peut pas être suffisamment intelligent pour trouver le système de fichiers racine de manière fiable. Il existe tout simplement trop de possibilités pour un programme aussi petit que le chargeur de démarrage. Considérez la racine NFS, les cartes RAID non standard, etc. Le chargeur de démarrage doit faire son travail en utilisant uniquement le BIOS plus le code qui peut être entassé dans le secteur de démarrage.
L'initrd est stocké quelque part que le chargeur de démarrage peut trouver, et il est suffisamment petit pour que le peu d'espace supplémentaire qu'il prend ne dérange généralement personne. (Dans les petits systèmes embarqués, il n'y a généralement pas de "vraie" racine, juste l'initrd.)
L'initrd est précieux: son contenu doit être conservé dans toutes les conditions, car si l'initrd tombe en panne, le système ne peut pas démarrer. Un choix de conception que ses concepteurs ont fait pour garantir cela est de faire en sorte que le chargeur de démarrage charge l'initrd en lecture seule. Il y a aussi d'autres principes qui fonctionnent dans ce sens, comme celui dans le cas de petits systèmes où il n'y a pas de "vraie" racine, vous montez toujours séparément /tmp
, /var/cache
et par exemple pour stocker des choses. La modification de l'initrd n'est effectuée que rarement et doit être effectuée très soigneusement.
Pour en revenir au cas normal où il existe un véritable système de fichiers racine, il est initialement monté en lecture seule car initrd l'était. Il est ensuite conservé en lecture seule aussi longtemps que possible pour à peu près les mêmes raisons. Toute écriture à la racine réelle qui doit être effectuée est interrompue jusqu'à ce que le système soit démarré, de préférence, ou au moins jusqu'à la fin du processus de démarrage lorsque cette préférence ne peut pas être satisfaite.
La chose la plus importante qui se produit pendant cette phase de lecture seule est que le système de fichiers racine est vérifié pour voir s'il a été démonté correctement. C'est quelque chose que le chargeur de démarrage pourrait certainement faire au lieu de le laisser à l'initrd, mais que se passe-t-il alors si le système de fichiers racine n'a pas été démonté proprement? Ensuite, il doit appeler fsck
pour vérifier et éventuellement le réparer. Alors, où irait- initrd
il fsck
, s'il était responsable de cette étape au lieu d'attendre le transfert à la "vraie" racine? Vous pourriez dire que vous devez copier fsck
dans le initrd
lors de la construction, mais maintenant c'est plus gros. Et en plus de cela, lequel fsck
allez-vous copier? Les systèmes Linux utilisent régulièrement une dizaine de systèmes de fichiers différents. Copiez-vous seulement celui nécessaire pour la vraie racine au moment où leinitrd
est créé? Faites-vous gonfler la taille de initrd
en y copiant tous les fsck.foo
programmes disponibles , au cas où le système de fichiers racine serait migré plus tard vers un autre type de système de fichiers, et que quelqu'un oublie de reconstruire l'initrd?
Les architectes du système de démarrage Linux ont judicieusement choisi de ne pas alourdir l'initrd avec ces problèmes. Ils ont délégué la vérification du système de fichiers racine réel au système de fichiers racine réel, car il est mieux placé pour le faire que l'initrd.
Une fois que le processus de démarrage a suffisamment avancé pour que cela puisse être fait en toute sécurité, l'initrd est échangé sous la racine réelle avec pivot_root(8)
, et le système de fichiers est remonté en mode lecture-écriture.