Kernel ohne initial ramdisk

[pil]

Kein Kernel ohne initrd mehr möglich, wenn man SCSI-Emulation verwendet?

Meiner Erfahrung nach ist das Booten deutlich schneller, wenn der selbst erstellte Kernel kein extra Image als initial ramdisk verwendet.

Bislang habe ich meine Kernels niemals mit einer initrd ausgestattet. Ich verfüge sogar noch über das alte Lenny-System mit Kernel 3.2.19, das wesentlich schneller bootet als das neue Wheezy (auf demselben Rechner).

Ich habe deshalb versucht, mit Kernel 3.2.21 die initrd zu verhindern:

# CONFIG_BLK_DEV_INITRD is not set

# CONFIG_BLK_DEV_RAM is not set

Es wurde trotzdem ein initrd.img angelegt, und natürlich auch zum Booten verwendet.

Ich nehme an, das liegt an der SCSI-Emulation. Die Kernels ohne initrd waren nämlich alle mit den alten ide-Treibern ausgestattet.

[KBDCALLS]

Was soll SCSI damit zu tun haben? Damit man ohne initrd auskommt, müssen zumindest die Treiber in den Kernel kompiliert werden , die benötigt werden um auf das Rootdateisystem zuzugreifen. Also für den Hostadapter, für SCSI und fürs Dateisystem

[pil]

Damit man ohne initrd auskommt, müssen zumindest die Treiber in den Kernel kompiliert werden , die benötigt werden um auf das Rootdateisystem zuzugreifen. Also für den Hostadapter, für SCSI und fürs Dateisystem

Ahh, gut das zu wissen.

Ich habe bei der Kernel-Konfiguration darauf geachtet, dass die gesamte SCSI-Emulation in den Kernel einkompiliert wird. Auch der Dateisystem-Zugriff für ext4 ist fest einkompiliert. Es kann sich nur um einen verbliebenen Hostadapter-Treiber handeln.

Ich brauche eigentlich nur zu schauen, welcher Hostadapter als Modul geladen wird, und den dann fest einkompilieren?

[KBDCALLS]

Im Prinzip ja . Aber einige Treiber brauch dann noch zusätzliche Treiber. Weil sie auf andere aufbauen. Der pata_jmicron braucht dann noch libata nur mal als Beispiel. Manche Treiber lassen sich auch erst fest einkompilieren wenn das andere Teil davon auch mit drin ist. Würde ansonten auch keinen Sinn machen. Wodrauf man sich aber nicht verlassen sollte. Das sieht man aber mit lsmod oder auch mit modinfo ebenfalls, und einiges mehr.

[pil]

Ja, so einfach ist es noch aus einem weiteren Grund nicht. Debian funkt einem da kräftig dazwischen, auch wenn man einen Kernel erstellt, der ohne eigene ramdisk perfekt läuft.

Beim Ausführen von make install in /usr/src/linux wird automatisch eine ramdisk angelegt - so dass es den Anschein erweckt, als ob das alles von den Kernel-Sourcen ausginge.
Tut es aber nicht, denn die Kernel-Sourcen stammen direkt von kernel.org.

Um einen Kernel ohne ramdisk zu erstellen, muss man auf Wheezy mindestens das package initramfs-tools loswerden, oder alles manuell erledigen, also das fertige Kernel-Image und System.map von Hand nach /boot kopieren.

[catdog2]

make install macht man schon mal gar nicht: kernel-package

[pferdefreund]

Also ich mach meine Kernel grundsätzlich ohne initrd und - Schande über mich - installiere die händig nach /boot usw.
Lilo Eintrag auch manuell - und es funktioniert auf diese Weise egal, welches Linux man gerade probiert.
Soviel Aufwand ist das ja dann auch nicht.
Wenn man seinen Kernel eh selbst backt, muß man sich natürlich auch dann selbst um die Updates kümmern und im
Regelfall weis man auch, was man tut (hoffe ich).

[pil]

Ich habe das jetzt so gelöst:

Ich lasse initramfs-tools weiter die ramdisk erstellen. (Die Tools sind gut.)
Der Kernel ist jedoch geeignet sowohl mit als auch ohne ramdisk-Datei zu booten.

Um mit oder ohne ramdisk zu booten, braucht man in /boot/grub.cfg nur eine Zeile (aus)kommentieren:

# initrd /boot/initrd.img-3.2.21

Auf diese Weise habe ich die größtmögliche Flexibilität.
Jetzt muss nur noch verhindert werden, dass bei make install jedes Mal automatisch update-grub aufgerufen wird.
Und grub.cfg wird nach jedem Kernel-Update von Hand angepasst.

[pferdefreund]

Wenn eh schon händig - dann halt einfach Makefiles nach grub-Aufruf durchsuchen und mit # auskommentieren.

[pil]

Wenn eh schon händig - dann halt einfach Makefiles nach grub-Aufruf durchsuchen und mit # auskommentieren.

Nein, so einfach ist das nicht. Denn die originalen Kernel-Sourcen wissen nichts von grub. update-grub wird - genau wie die Erstellung der ramdisk - von parasitären Routinen aufgerufen, die sich an make install angehängt haben.

Diejenigen, die es brauchen, haben einen klaren Vorteil, weil sie Zeit sparen, und der ganze Vorgang sozusagen in einem Aufwaschen erledigt wird.

Aber diejenigen, die es nicht haben wollen, haben einen klaren Nachteil, weil sie erst mal vor einem unerwarteten Ergebnis stehen und ergründen müssen, wie es zustande kam - und am Ende wieder von Vorne anfangen müssen.

Ich bezeichne das deshalkb als Injektion oder Infektion: Das Eindringen von parasitären Routinen. Das ganze udev-Zeugs etwa beruht auf diesem Prinzip.

Diese parasitären Routinen zeichnen sich v.a. durch Intransparenz im nicht-technischen Sinn aus, also durch Undurchsichtigkeit.

Und sie sind mit Nebenwirkungen behaftet. Eine davon ist z. B., dass die ohnehin hohe Komplexität noch weiter erhöht wird: Wenn irgend etwas schief läuft, weiss man zunächst nicht, wo etwas schief gelaufen ist (bei den Originalroutinen oder bei einer seiner Parasiten).


Die ramdisk wird von update-initramfs generiert, und update-grub wird von run-parts aufgerufen. Die Konfigurations-Dateien dafür befinden sich in /etc/kernel/postinst.d