Pourquoi avons-nous besoin de initramfs et initrd

Je comprends le but de ce concept.
Par exemple, nous avons un système de files exotique sur le disque et afin de charger le système, nous avons besoin du système de files racine. Mais nous ne pouvons pas parce qu'il n'y a pas de pilote approprié existe dans l'image du kernel.

Laissez-moi vous expliquer comment je comprends le kernel et initrd .

Lorsque le kernel est compilé, nous pouvons sélectionner différents modules à inclure dans l'image du kernel (un seul file)
Par exemple mon système de files racine est reiserfs et j'ai configuré le kernel pour ne pas inclure de module pour ce système de files
Dans ce cas, le kernel ne sait pas comment monter un tel système de files et il a besoin d'aide -> chargez donc initramfs dans la memory
Trouver le bon module en ram fs (lib / modules ou etc)
Charge ce module sur le kernel
Maintenant, le kernel peut monter des reiserfs il monte et décharge la memory occupée par ramfs

Ai-je raison ?

Mais je ne comprends pas pourquoi avons-nous besoin d' initramfs dans chaque dissortingbution (je l'ai vu dans chaque dissortingbution que j'ai jamais installé) si la plupart des pilotes spécifiques sont déjà présents dans l'image du kernel le kernel peut être chargé à partir du système de files après son assembly.

Alors est-ce vraiment une partie essentielle de toute dissortingbution?

S'il vous plaît aider à comprendre ce genre de choses.

PS Quel est le plus souvent utilisé initramfs ou initrd et pourquoi?

La force vient de toutes les autres choses que vous pouvez faire en plus de charger des modules. Fondamentalement, il vous donne un espace user et la possibilité de faire toutes les choses que vous pouvez faire à partir de cela.

Un exemple: j'utilise un initrd pour avoir un fs encrypté, ce qui nécessite un code qui n'a pas de sens dans le kernel.

La section "Reason" de la page Wikipedia sur initrd a plus d'exemples.

initramfs est une implémentation plus récente (mais toujours assez ancienne) de la même idée, mais le nom initrd a souvent survécu pour se référer à l'image utilisée comme espace user précoce.

Une raison totalement différente pour laquelle je viens de penser: les périphériques embarqués, ils n'ont peut-être pas assez de memory pour faire face à un kernel qui inclut tout.

Il y a beaucoup de raisons d'avoir un initramfs, certains sont ci-dessous.

Lorsque vous avez besoin d'un / usr séparé, / var comme certaines dissortingbutions dépend de ces directorys dans /
Quand vous voulez chiffrer / mais vous aimez avoir / boot sur un stick USB car vous ne pouvez pas avoir un chiffrement / boot
Quand vous ne voulez pas avoir de trucs dans le kernel, mais en tant que module, de cette façon vous ne chargez que ce dont vous avez besoin et cela se fait dans un espace user précoce
Lorsque vous utilisez dmraid sur /
Lorsque vous avez besoin de plus de controls, c.-à-d. Que vous avez un server distant sur lequel vous avez besoin de configurer un réseau dans l'espace user avec dropbear (minuscule ssh daemon) pour vous permettre de décrypter votre / et de démarrer normalement; )

Je peux continuer encore et encore pourquoi vous avez besoin d'un initramfs, mais à la fin s'il y a un logiciel qui doit s'exécuter avant «switch_root …», vous aurez besoin d'un initramfs pour cela.

Je suppose qu'il est vrai que le matériel moderne ne dérangerait pas par exemple un kernel de 50 Mo. Vous pourriez argumenter que le chargement de tout comme des modules séparés n'a pas été aussi important depuis un certain time maintenant.

Cependant, le système initial de RAM permet d'amorcer n'importe quelle configuration possible, sans nécessiter de manipulation particulière dans le kernel. L'écriture du code du kernel est une grosse affaire. Le système de ram initial est la bonne solution. Nous pouvons utiliser beaucoup de code similaire au système principal, par exemple systemd ;-).

Le démarrage à partir d'un système de files crypté en est un excellent exemple. Le kernel n'a pas à requestr la phrase secrète.

Un exemple que chaque installation moderne utilise est de find le système de files racine par UUID (ou peut-être le nom du volume LVM). C'est utile car sinon votre démarrage se casse lorsque vous supprimez une partition non liée, car ils sont tous renumérotés. Ou lorsque vous déplacez des disques ou entre des ordinateurs. Ou quand le disque est un CD live.

Pourquoi avons-nous besoin d'un système de files ram? Parce que nous ne voulons pas être étroitement couplé au firmware / boot loader. Il peut simplement nous remettre datatables comme un bloc de memory, et nous avons terminé. Nous voulons garder le process de démarrage aussi simple que possible. Bootup est à la fois critique, et un cas particulier. Nous n'avons pas besoin d'une interface complexe avec d' autres logiciels spéciaux. Surtout le cas du firmware. Le micrologiciel est un cas si particulier, donc nous ne nous en soucierions pas le rest du time, il sera criblé de bugs que personne n'a remarqué. Et le firmware est si critique, que les correctifs sont très risqués. Utilisé pour être il était ROM et vous ne pourriez pas le patcher du tout.