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.)