ubuntuusers.de

ich hab da mal eine Verständnisfrage. Bislang habe ich immer einen eigenkompilierten Kernel verwandt, der ohne initrd kompiliert wurde und bei dem z.B. alle gängigen SATA/PATA-Treiber fest drin sind. Auf die Weise ist mein System schon mehrmals auf neue Hardware umgezogen. Jetzt bin ich soweit, dass ich den Ubuntu-Kernel benutzen möchte. Ich möchte aber auch weiterhin die Möglichkeit haben, die Platte einfach zu klonen und das System auf anderer Hardware einzusetzen.

Soweit ich das initrd-Konzept verstanden habe, sind die zum Booten benötigten Kerneltreiber in der initrd drin. Die bei der Jaunty-Installation erzeugte initrd.img-2.6.28-11-generic ist bei mir 7,2 MB groß, bei Hardy sieht es kaum anders aus. In der /etc/initramfs-tools/initramfs.conf steht MODULES=most. Laut Beschreibung bedeutet "most": Add all framebuffer, acpi, filesystem, and harddrive drivers.

Heisst dass, die initrd hat zunächst mal auf jedem neu installierten System den gleichen Inhalt? Dann wäre das ja im Ergebnis das gleiche, als wenn man die Module gleich fest in den Kernel einkompilieren würde. Wo liegt also der Vorteil dieser Methode?

http://blog.rootserverexperiment.de/2008/04/29/eeepc-ubuntu-804-initramfs-tuning/ legt nahe, dass durch das Entpacken und Testen sämtlicher Module in der initrd der Bootprozess unnötig verlangsamt wird,, und das die Verkleinerung auf die tatsächlich benötigten Module den Rechner schnellen Hochfahren lässt.

Die Kunst ist nun, die benötigten Module richtig zu ermitteln. Mir stellt sich hier die Frage, warum das Ubuntu-installscript hier nicht bereits im Rahmen der Hardwareerkennung tätig wird. Meine Idee ist, dass dann standardmässig nur ein exakt auf den Rechner angepasstes initrd.img geladen wird, und nur der recovery-Eintrag in der /boot/grub/menu.lst auf ein mit "most" erstelltes initrd.img verweist.

Gibt es vielleicht bereits ein (Tuning)-Tool oder ein HowTo zur Ermittlung der für die initrd erforderlichen Module eines Systems? Oder ist die Reduzierung der Bootzeit so minimal, dass sich dieser Ansatz doch nicht lohnt?

keiner eine Meinung?

na ja, im Nachhinein wäre es vielleicht auch besser eine Frage für Ubuntu-Entwicklung gewesen. Kann ein Mod diesen beitrag evtl. dahin verschieben?

Dr._Seltsam schrieb:

Ich möchte aber auch weiterhin die Möglichkeit haben, die Platte einfach zu klonen und das System auf anderer Hardware einzusetzen.

Die Initrd hat alles dabei was auch installiert ist. Installiert man also RAID Tools bekommt man automatisch diese auch in die Initrd.

Heisst dass, die initrd hat zunächst mal auf jedem neu installierten System den gleichen Inhalt?

Genau

Dann wäre das ja im Ergebnis das gleiche, als wenn man die Module gleich fest in den Kernel einkompilieren würde.

Nein, es werden nur die Treiber geladen wo auch benötigt werden. Hast du alle einkompiliert ist der Kernel somit immer so groß wie alle Module zusammen! Und man kann nur relativ umständlich an einkompilierte Treiber Optionen weitergeben....

...und das die Verkleinerung auf die tatsächlich benötigten Module den Rechner schnellen Hochfahren lässt.

Klaro, das kostet Zeit. Aber macht das System sehr Modular! Und so extrem viel Zeit ist es nicht, da geht mehr wegen dem Rest drauf als wegen der initrd!

warum das Ubuntu-installscript hier nicht bereits im Rahmen der Hardwareerkennung tätig wird.

Und was ist wenn $USER sein System ändert? Dann bootet es nicht mehr, obwohl es eigentlich gehen würde!

Oder ist die Reduzierung der Bootzeit so minimal, dass sich dieser Ansatz doch nicht lohnt?

Es wird sich nur selten lohnen. Ist das initrd mal geladen (was kaum länger als 5 Sekunden dauert) geht alles Ruckzuck...

mfg Betz Stefan

encbladexp schrieb:

Dann wäre das ja im Ergebnis das gleiche, als wenn man die Module gleich fest in den Kernel einkompilieren würde.

Nein, es werden nur die Treiber geladen wo auch benötigt werden. Hast du alle einkompiliert ist der Kernel somit immer so groß wie alle Module zusammen! Und man kann nur relativ umständlich an einkompilierte Treiber Optionen weitergeben....

na ja, der Kernel ist kleiner aber die initrd riesig. Würde man alles fest einkompilieren, wäre der Kernel vermutlich nicht größer als der heutige Kernel + initrd zusammen. Das mit den Optionen ist natürlich ein Argument!

warum das Ubuntu-installscript hier nicht bereits im Rahmen der Hardwareerkennung tätig wird.

Und was ist wenn $USER sein System ändert? Dann bootet es nicht mehr, obwohl es eigentlich gehen würde!

in dem Fall könnte der User dann den recovery-Kernel mit der vollständigen initrd laden. Und danach sucht er dann hier im Forum nach Lösung seines Problems ... na ja, ist vielleicht doch nicht so breitentauglich die Idee ...

Oder ist die Reduzierung der Bootzeit so minimal, dass sich dieser Ansatz doch nicht lohnt?

Es wird sich nur selten lohnen. Ist das initrd mal geladen (was kaum länger als 5 Sekunden dauert) geht alles Ruckzuck...

5 Sekunden finde ich eigentlich schon recht viel.

Ist es tatsächlich so, dass es zeitlich einen Unterschied macht, ob alle Module aus der initrd geladen und getestet werden, oder ob sie fest im Kernel drin sind? Testet der Kernel fest einkompilierte Treiber nicht? Ich habe zumindest nie einen Unterschied festgestellt, ob ich einen "schlanken" angepassten Kernel oder einen fetten Kernel boote. Zusätzlich mit einkompilierte Treiber, die nicht benötigt werden, schienen nie "getestet" zu werden. Deswegen war ich recht erstaunt als ich in dem Artikel las, dass bei Verwendung einer initrd "die vielen enthaltenen Treiber einzeln geladen werden und nach der für sie bestimmten Hardware suchen"

Dr._Seltsam schrieb:

na ja, ist vielleicht doch nicht so breitentauglich die Idee ...

Eben, viele Leute sind einfach Neuinstallation gewöhnt... was ja eigentlich nicht sein sollte!

5 Sekunden finde ich eigentlich schon recht viel.

Mein BIOS hier braucht schon locker 10 Sekunden (AHCI usw...)....

oder ob sie fest im Kernel drin sind? Testet der Kernel fest einkompilierte Treiber nicht?

Ja, er ist aber nicht so extrem groß. Hauptgrund ist einfach der Speicherverbrauch.

Der Kernel verwendet nur die Treiber wo er braucht.

mfg Betz Stefan