Hallo,

ich haette da mal ne grundlegende Frage. Welchen Sinn macht denn eine initrd bei einem selbsgebastelten Kernel? Ein Bei einem Selbstgebastelten Kernel sehe ich so direkt keinen Sinn, solange mit "selbstgebastelt" gemeint ist, dass Du Dir für jeden Deiner Rechner immer und ständig einen eigenen Kernel übersetzen willst.

Wenn ich doch eh die Unterstuetzung fuer den Symbios Chip brauche (SCSI-Controller) o.ae., warum wird das dann nicht fest in den Kernel eingebunden? Ich habe nun schon zahlreiche PCs mit Linux installiert, aber irgendwie habe ich noch nie eine initrd gebraucht! Bin ich da nun rueckstaendig, lebe ich hinterm Mond, oder habe ich einfach eine PC-Konfiguration, die das nicht noetig macht? :-) In letzter Zeit lese ich gerade hier auf der Liste aber immer mehr, dass Leute initrd ein- setzen. Ist das irgendwie gerade "in"? Koennte mir das mal jemand erklaeren, wenn es nicht zu viele Umstaende macht?

Stell Dir vor, Du hast einen PC, der keine doofe 08/15 Hardware hat. Nehmen wir zum Beispiel einmal an, Du hast einen PC ohne IDE Platten und statt dessen schöne SCSI Platten mit 10.000 UPM ... Nun könnte ich mir einen Kernel zusammenstellen, der auch meinen SCSI-Controller mit drinnen hat. Wenn das ein exotisches Teil war, dann musste ich bisher das Teil selbst bauen. Und das ist im Massenmarkt einfach nicht unbedingt forderbar! (Wenn jetzt jemand sagt, dass dem doch so ist: Dann veralgemeinert das auch auf KDE und so ... Laut LinuxMagazin (oder war es LinuxUser?) benötigt ein P3-700MHz um 2 Tage reine kompilierzeit für das ganze KDE ... Nett ... Wird man wohl nicht fordern wollen!). So aber habe ich einen Bootloader, der das BIOS nutzt. Das heisst, dass LILO sowohl den Kernel als auch das initrd Image laden kann ... Der Kernel wird entpackt ... dieser lädt sich dann einfach das Modul zu dem SCSI Controller und schon kann er sich / mounten ... Das ist nur ein Anwendungsgebiet für die initrd - aber wohl mit das Hauptanwendungsgebiet ... denkbar sind aber auch noch ganz viele andere Dinge ... Also Sinn der initrd: - keine unnötigen treiber im Kernel halten - keine hundert Kernel, wo mans ich dann den richtigen auswählen muss (uahhh ... wer kennt nicht noch diese Zeit ... welche Bootdisk brauche ich? Waren ja nur 10 unterschiedliche zur Auswahl ... und wehe man hatte SCSI Platten und Mitsumi CD-ROM oder sowas in der Art ... Alle Kombinationen gab es auch nicht immer ... oder es war dann so viel im Kernel, dass er im "autoprobing" hing ... ach ja ...) Ich hoffe, ich konnte etwas zur klärung beitragen. Mit den besten Grüßen, Konrad Neitzel -- Konrad Neitzel Frankfurt / Main

Hallo David, danke für die viele Mühe bzgl. initrd, scheint dich ja richtig aufzuregen. Ich habe leider noch zu wenig Ahnung von Linux aber auf meinem PC, auf dem Suse Linux von einer EIDE Platte bootet, wird der SCSI Hostcontroller (Symbios 53c875 Rev.38), den ich für das ansprechen meines CD-Brenners brauche eben nicht automatisch geladen, obwohl ich ihn in /etc/modules.conf als "alias scsi-hostadapter sym53c8xx eingetragen hatte. Das manuelle Nachladen mittels modprobe oder insmod funktioniert hingegen problemlos. Kannst Du das erklären? Jürgen Gowin hat vor ein paar Tagen eine Erklärung zu den Hintergründen dieses Problems gegeben. Danke Jürgen. Weiterhin verweise ich auf den SDB Artikel "Wie binde ich einen SCSI Adapter ein", der sich genau auf meine PC Konfig. bezieht und initrd als Lösung angibt. Aufgrund dieses Artikels bin ich überhaupt erst auf die RAM-Disk gekommen. Das scheint dann wohl Unsinn zu sein, was die Leute von Suse da schreiben, oder? Schließlich geht's doch ganz einfach über /etc/modules.conf, nicht wahr? Vermutlich hast Du aber recht, daß die einfachste Variante das feste Einkompilieren des Hostadapter Treibers in den Kernel ist. Ich hatte halt zunächst den Ehrgeiz, den Kernel möglichst modularisiert zu halten, man hört ja überall, daß dies die zu bevorzugende Variante sein soll. Ich habe nach einigem Rumprobieren zwar inzwischen das Skript mk_initrd erfolgreich ausgeführt und die RAM Disk wird beim Booten auch geladen [...] RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize [...] RAMDISK: Compressed image found at block 0 aber der SCSI Adapter Treiber wird, aus welchen Gründen auch immer, mit dem 2.4.2 Kernel trotzdem nicht geladen, mit dem 2.2.14er Suse Standard Kernel hingegen schon: Uncompressing... done. Loading module sym53c8xx... done. Wollte heute abend eigentlich nochmal eine Anfrage in die Mailingliste stellen mit allerlei Details zu der Problematik aber nach Deiner Mail habe ich da irgendwie keine Lust mehr drauf. Werde dann wohl den SCSI Adapter Treiber dazukompilieren und die MMC Card Reader Treiber auch gleich, damit gibt's nämlich das gleiche Problem, nix mit automatischem Laden nach Eintrag in /etc/modules.conf. Servus Thomas -----Ursprüngliche Nachricht----- Von: David Haller [mailto:david@dhaller.de] Gesendet: Donnerstag, 19. Juli 2001 09:39 An: suse-linux@suse.com Betreff: Re: Sinn einer initrd [Was: Re: mk initrd nach Änderung von rc.config: "failed to mount image"] On Mit, 18 Jul 2001, Konrad Neitzel wrote:

...

ich haette da mal ne grundlegende Frage. Welchen Sinn macht denn eine initrd bei einem selbsgebastelten Kernel? Ein

_Das_ frage ich mich auch des oefteren in letzter Zeit...

...

noetig macht? :-) In letzter Zeit lese ich gerade hier auf der Liste aber immer mehr, dass Leute initrd ein- setzen. Ist das irgendwie gerade "in"? Koennte mir das mal jemand erklaeren, wenn es nicht zu viele Umstaende macht?

Stell Dir vor, Du hast einen PC, der keine doofe 08/15 Hardware hat. Nehmen wir zum Beispiel einmal an, Du hast einen PC ohne IDE Platten und statt dessen schöne SCSI Platten mit 10.000 UPM ...

Ok. *ding* eingeloggt.

Nun könnte ich mir einen Kernel zusammenstellen, der auch meinen SCSI-Controller mit drinnen hat. Wenn das ein exotisches Teil war, dann musste ich bisher das Teil selbst bauen. Und das ist im Massenmarkt einfach nicht unbedingt forderbar!

Ok. Aber du brauchst ein Modul fuer den Controller. Ich weiss nicht, ob Suse Module fuer alle moeglichen mitliefert, aber gehen wir davon mal aus, dann ist initrd sinnvoll (wenn man den SuSE Kernel verwendet, sonst nicht!).

(Wenn jetzt jemand sagt, dass dem doch so ist: Dann veralgemeinert das auch auf KDE und so ... Laut LinuxMagazin (oder war es LinuxUser?) benötigt ein P3-700MHz um 2 Tage reine kompilierzeit für das ganze KDE ... Nett ... Wird man wohl nicht fordern wollen!).

Aehm, wuerdest du mich bitte aufklaeren, was der Kernel, bzw. spezifisch ein SCSI-Treiber mit KDE zu tun hat??? Der Kernel 2.4.x ist bei mir (K7-500) in gut 10 min durch, das konfigurieren dauert ggfs. etwas laenger...

So aber habe ich einen Bootloader, der das BIOS nutzt. Das heisst, dass LILO sowohl den Kernel als auch das initrd Image laden kann ... Der Kernel wird entpackt ... dieser lädt sich dann einfach das Modul zu dem SCSI Controller und schon kann er sich / mounten ...

Ja, und wo ist das Argument? Wenn du den Kernel eh selber baeckst (und darum geht es (siehe gaaanz oben), dann kannst du den Treiber gleich fest einbauen und musst dich nicht um die initrd kuemmern...

Das ist nur ein Anwendungsgebiet für die initrd - aber wohl mit das Hauptanwendungsgebiet ... denkbar sind aber auch noch ganz viele andere Dinge ...

JA? Da bin ich mal gespannt... Wie gesagt: Es geht um _selbstgebackene_ Kernel, nicht um fertig kompilierte!

Also Sinn der initrd: - keine unnötigen treiber im Kernel halten

Unnoetig == braucht man nicht immer == muss nicht in die initrd (und erst recht nicht in die boot.local), sondern wird als Modul konfiguriert und dann in der modules.conf korrekt eingetragen. Ergo: dein Argument > /dev/null. Nochmal zum Mitmeisseln: FUER MODULARITAET DES KERNELS BRAUCHT MAN WEDER NE INITRD NOCH MUSS MAN MODULE IN DER boot.local LADEN!!!

- keine hundert Kernel, wo mans ich dann den richtigen auswählen muss (uahhh ... wer kennt nicht noch diese Zeit ... welche Bootdisk brauche ich? Waren ja nur 10 unterschiedliche zur Auswahl ... und wehe man hatte SCSI Platten und Mitsumi CD-ROM oder sowas in der Art ... Alle Kombinationen gab es auch nicht immer ... oder es war dann so viel im Kernel, dass er im "autoprobing" hing ... ach ja ...)

Ack. Das _ist_ ein Argument... Fuer eine Distri. Aber hier geht's wie schon erwaehnt, um selbstgebackene Kernel, ergo: Thema verfehlt und dein Argument == irrelevant.

Ich hoffe, ich konnte etwas zur klärung beitragen.

Nein. -dnh P.S: *scnr* PPS: Das ist alles nicht persoenlich gemeint, auch wenn ich es scharf oder persoenlich formuliert habe, es ist halt nur wirklich auffallend, wie sinnentfremdet Module (und initrd/boot.local) hier immer wieder verwendet werden... PPPS: Und ja, auch ich habe noch _NIE_ ne initrd gebraucht. OK, ich habe ein IDE System, der suse-installations-kernel kommt also ohne Module hoch... Aber wenn ich mir schon selbst einen Kernel backe, dann baue ich verdammt noch eins auch die zum booten noetigen Module fest ein. Denn geladen werden muessen sie immer. Die initrd ist dafuer schlicht und einfach nicht gedacht! -- Networks are like sewers ... My job is to make sure your data goes away when you flush, and to stop the rats climbing into your toilet through the pipes. (Tanuki, describing network administration.) -- Um die Liste abzubestellen, schicken Sie eine Mail an: suse-linux-unsubscribe@suse.com Um eine Liste aller verfügbaren Kommandos zu bekommen, schicken Sie eine Mail an: suse-linux-help@suse.com

brauche eben nicht automatisch geladen, obwohl ich ihn in /etc/modules.conf als "alias scsi-hostadapter sym53c8xx eingetragen hatte. Das manuelle Nachladen mittels modprobe oder insmod funktioniert hingegen problemlos.

Du solltest Dir noch einmal durch den Kopf gehen lassen, was initrd genau macht und ist! initrd ist sowas wie ein erstes Root-Fs! Also wird initrd mitgeladen und als root-Filesystem gemountet ... dann wird ein Script / Programm initrd gestartet, welches irgendwelche Dinge macht ... wenn a) das Modul nicht in der initrd drin ist oder b) in der initrd das modul nicht geladen wird, dann wird das Modul nicht geladen! /etc/modules.conf interessiert da überhaupt nicht! (Maximal wenn Du irgendwelche Automatismen benutzt, die die /etc/modules.conf auswertet und daraus deine initrd zusammenbastelt. Das nur noch einmal als kleiner Hinweis zur Funktionalität. Hier gibt es aber zu initrd bei SuSE auch einiges an Dokumentation ... auch im Handbuch! Konrad Neitzel -- Konrad Neitzel Frankfurt / Main

Michael Schulz wrote:

[Sinn einer initrd]

Für mich gibt es nur einen Grund und der ist für Distributionen. Da sehe ich eine initrd ja noch ein, aber sonst?

Ich hatte ja die urspruengliche Frage gestellt, und mich nach der ersten Antwort von Konrad auch nochmal privat mit ihm unterhalten. Mein Fazit, was ich daraus gezoegen habe, war, dass eine initrd nur Sinn macht, wenn ein und derselbe Kernel auf moeglichst breiter Hardwarebasis laufen soll -- das passt dann eben zu den diversen Distributionen o.ae.. Das Kernel- Compilieren geht mit den heutigen Rechnern so schnell, dass es fuer mich kein Problem darstellt, auf allen Rechnern hier einen eigenen angepassten Kernel zu installieren. Ich denke, ich werde also auch in Zukunft ohne eine initrd auskommen :-) Gruesse aus KA und Dank an alle, die zu meiner Erleuchtung beigetragen haben! Thomson -- Thomas Hertweck, Geophysicist Geophysical Institute, Karlsruhe University (TH) Hertzstr. 16, D-76187 Karlsruhe, Germany