Sobald der Linux-Kernel geladen und das Root-Dateisystem (/) gemountet ist, können Programme ausgeführt und weitere Kernel-Module eingebunden werden, um zusätzliche Funktionalitäten bereitzustellen. Um aber das Root-Dateisystem überhaupt mounten zu können, müssen verschiedene Bedingungen erfüllt sein: Der Kernel benötigt die entsprechenden Treiber, um das Gerät ansprechen zu können, auf dem das Root-Dateisystem liegt (insbesondere SCSI-Treiber). Weiter muss der Kernel den Code enthalten, der benötigt wird, um das Dateisystem lesen zu können (ext2, reiserfs, romfs usw.). Weiterhin ist es denkbar, dass bereits das Root-Dateisystem verschlüsselt ist. Zum Mounten ist in diesem Fall die Eingabe des Schlüssels/Passworts erforderlich.

Betrachtet man nur einmal das Problem der SCSI-Treiber, so sind verschiedene Lösungsansätze denkbar: Der Kernel kann alle denkbaren Treiber enthalten. Dies ist problematisch, da sich die verschiedenen Treiber beißen können. Außerdem wird der Kernel dadurch sehr groß. Eine andere Möglichkeit besteht darin, verschiedene Kernel zur Verfügung zu stellen, die jeweils nur einen oder sehr wenige SCSI-Treiber enthalten. Auch dieser Weg ist problematisch, da er eine sehr große Zahl unterschiedlicher Kernel notwendig macht. Ein Problem, das durch verschieden optimierte Kernel (Athlon-Optimierung, SMP) noch weiter verschärft wird.

Der Ansatz, den SCSI-Treiber als Modul zu laden, führt zur generellen Problematik, der durch das Konzept der initial ramdisk begegnet wird: Das Bereitstellen einer Möglichkeit, Userspace-Programme bereits vor dem Mounten des Root-Dateisystems ausführen zu können.

Die initial ramdisk (auch initdisk oder initrd genannt) löst genau diese oben beschriebenen Probleme. Der Linux-Kernel bietet die Möglichkeit, ein (kleines) Dateisystem in eine Ramdisk zu laden, und darin Programme ausführen zu lassen, bevor das eigentliche Root-Dateisystem gemountet wird. Das Laden der initrd wird dabei vom Bootloader (GRUB, LILO usw.) übernommen; all diese Bootloader benötigen lediglich BIOS-Routinen, um Daten vom Bootmedium zu laden. Wenn der Bootloader den Kernel laden kann, kann er auch die initial ramdisk laden. Spezielle Treiber sind somit nicht erforderlich.

Der Bootloader lädt den Kernel und die initrd in den Speicher und startet den Kernel, wobei der Bootloader dem Kernel mitteilt, dass eine initrd vorhanden ist und wo im Speicher diese liegt. Ist die initrd komprimiert (was typischerweise der Fall ist), so dekomprimiert der Kernel die initrd und mountet sie als temporäres Root-Dateisystem. Hierauf wird in der initrd ein Programm mit dem Namen linuxrc gestartet. Dieses Programm kann nun all die Sachen tun, die erforderlich sind, um das richtige Root-Dateisystem mounten zu können. Sobald linuxrc terminiert, wird die (temporäre) initrd wieder abgehängt unmounted und der Bootvorgang wie gewohnt mit dem Mounten des richtigen Root-Dateisystems fortgeführt. Das Mounten der initrd und das Ausführen von linuxrc kann somit als ein kurzes Intermezzo während eines normalen Bootvorgangs betrachtet werden. Der Kernel versucht nach dem Booten der tatsächlichen Root-Partition, die initrd auf das Verzeichnis /initrd umzumounten. Wenn das fehlschlägt, weil zum Beispiel der Mountpunkt /initrd nicht vorhanden ist, wird der Kernel versuchen, die initrd abzuhängen. Sollte auch dies fehlschlagen, ist das System zwar voll funktionsfähig, jedoch kann der durch die initrd belegte Speicher nie freigegeben werden; er steht somit nicht mehr zur Verfügung.

Die meisten Bootloader (vor allem GRUB, LILO und syslinux) können mit initrd umgehen. Die einzelnen Bootloader werden wie folgt angewiesen, eine initrd zu verwenden:

Übersetzt man sich selbst einen Kernel, so kann es zu folgendem Problem kommen: Versehentlich wird der SCSI-Treiber fest in den Kernel gelinkt, die bestehende initrd bleibt aber unverändert. Beim Booten geschieht Folgendes: Der Kernel enthält bereits den SCSI-Treiber, die Hardware wird erkannt. Die initrd versucht nun jedoch, den Treiber nochmals als Modul zu laden. Dies führt bei einigen SCSI-Treibern (insbesondere beim aic7xxx) zum Stillstand des Systems. Streng genommen handelt es sich um einen Kernelfehler (ein bereits vorhandener Treiber darf nicht ein zweites Mal als Modul geladen werden können) – das Problem ist bereits im Zusammenhang mit seriellen Treibern bekannt.

Es gibt mehrere Lösungen: Entweder den Treiber als Modul konfigurieren (dann wird er korrekt in der initrd geladen) oder aber den Eintrag für die initrd aus /etc/grub/menu.lst bzw. /etc/lilo.conf entfernen. Äquivalent zur letzteren Lösung ist es, den Treiber aus INITRD_MODULES zu entfernen und mkinitrd aufzurufen, das dann feststellt, dass keine initrd benötigt wird.

Für die Zukunft ist denkbar, dass eine initrd für weitaus mehr (und anspruchsvollere) Dinge verwendet wird als nur für das Laden der Module, die für den Zugriff auf / benötigt werden.