Kernel Kopieren

Hi,
ich würde gerne unter SLES11 einen neuen Kernel haben. Da es wahrscheinlich nicht ganz trivial ist einen Kernel neu zu Kompilieren, würde ich gerne einen bestehenden einfach kopieren. Geht das? Wenn ja wie?

Einen Kernel kopieren?? Was genau meinst du damit? Einen Kernel aus den SLES11 Repos installieren?

Es ist besser den Kernel zu kompillieren. Was soll den an der Kompilierung des Kernels Trivial sein?

Ich werde einige Testreihen durchführen und dazu erhebliche Veränderungen am Kernel vornehmen. Die unterschiedlichen Test und die Kernelkonfigurationen sollen sich nicht stören. Deswegen würde ich den Unveränderten Kernel von der SLES11 Installation gerne x mal Kopieren um jeweils die gleiche Ausgangskonfiguration zu haben. Das ist der Hintergrund... Von mir aus kann ich ein ein Kernel.rpm Installieren wenn das geht. Nur würde ich gerne um eine neukompilierung rum kommen weil das

1) Bestimmt nicht trivial ist
2) Ich nich weis welche Einstellungen beim Standard SLES11 Kernel getroffen wurden und so nicht die gleichen Testbedingungen gegeben sind

Irgendwie werde ich das Gefühl nicht los, du willst da etwas machen ohne das du die Grundlagen dazu auch nur ansatzweise kennst. Warum sagst du uns nicht einfach erstmal was du warum genau machen willst.

Ansonsten gilt folgendes:
Kernelquellcode : Der Kernel und die dazugehörigen Module werden aus dem Kernelquellcode gewonnen. Der Quellcode kann mit Patches verändert werden. Dieses kann, aber muss nicht (zwangsläufig bei jeder kleinsten Änderung) unbedingt immer zu einer Änderung der Kernel-Version führen.

Kernel: Der Kernel besteht im wesentlichen aus der binären Kerneldatei die beim Start des BS geladen wird. ( Diese Kerneldatei kann verschiedene Formate haben, sie kann zB komprimiert sein, oder auch nicht. Inhalt und Funktion ist das Selbe, Größe und Name aber unterschiedlich.) Zusätzlich gehören zu jedem Kernel zwingend eine größere Menge an genau für diesen Kernel erzeugte Kernelmodule, die nur mit genau diesem Kernel funktionieren. Man sollte noch einige Dateien dazugezählen die indirekt dazugehören, wie zb eine Konfigurationsdatei (siehe unten) und Dateien die genaue Positionen der einzelnen Funktionen des Kernels in der binären Kerneldatei und in den Modulen beschreiben. Diese Dateien werden für die Funktion des Kernels nicht zwingend benötigt sind auch nicht in jedem Falle vorhanden und könnten auch aus dem Kernel neu erstellt werden. Bei der Installation des Kernels im System werden dann noch weitere Dateien erzeugt, die im erweiterten Sinne dann auch zum Kernel jetzt aber schon Systembezogen dazugehören. Das ist zB die initrd und die globale Modulkonfiguration ohne die die Module nicht automatisch geladen werden können. Die Kerneldatei eventuelle config, map-Dateien und sym-Dateien sowie die initrd liegt typisch unter /boot/ die Module und alles was dazu gehört, findet man unterhalb von /lib/modules/$KERNELNAMEN
Unterschieden und verglichen wird der Kernel und seine dazugehörigen Module am internen Kernelnamen der sich aus der eigentlichen Kernelversion des Quelltextes und einer Versionserweiterung die beim Konfigurieren festgelegt werden kann, zusammensetzt. auslesen kannst du das am laufenden kernel mit "uname -r" . Ob dann eine binare Kerneldatei auch dieses Komplett im Dateinnamen mit sich führt, ist zwar typisch aber für die Funktion nicht zwingend erforderlich. Das Modulverzeichnis muss jedoch zwingend so benannt sein.

private Kernelmodule Weiterhin gibt es auf vielen Systemen noch weitere Kernelmodule die nicht aus dem Kernelquelltext übersetzt werden. Das können bestimmte Treiber sein, aber auch Module von Applikationen. Diese Module sind ebenso eindeutig an die Kernelversion und Kernel-Konfiguration gebunden und gehören somit auch zum Kernel und müssen zB nach jedem Kernelwechsel wieder neu kompiliert werden. Wie das erfolgt ist unterschiedlich, machmal funktioniert das automatisch in den Startscripten, machmal auch auch nur per Handarbeit. Wo die Module liegen ist nicht definiert, oft werden sie auch bei den anderen Modulen in einem separatem Unterverzeichnis abgelegt. Sie können aber durchaus auch in einem Unterverzeichnis der Applikation, für die sie benötigt werden, liegen. Das ist dann vor allem dann zu erwarten, wenn die Module nicht automatisch sondern nur von der Applikation selbst geladen werden.

Kernelkonfiguration: Das ist im Grunde nur eine einzige Datei die jeder Kernel bei Suse auch im "Bauch" mit sich führt. Du kannst sie bei Susekernel auch "aus dem Bauch" auslesen mit
Es ist eine automatisch generierte make config Datei. Diese enthält die genauen Optionen mit denen der Kernel übersetzt wurde. Das ist wie eine Art Bauplan für genau diesem Kernel. Mit dieser Datei läßt sich mit dem selben Compiler und dem selben (ungeänderten) Kernelquellcode immer wieder genau der selbe Kernel und die selben dazugehörigen Module herstellen. Bei neuem oder geänderten Kernelquellcode läßt sich daraus auch die Konfiguration für einen analog konfiurierten und damit analog funktionierenden Kernel einer anderen Version herstellen. Für verschieden Spezialfälle und bei Suse auch die typischen SuSE Konfigurationen liegen auch noch mal irgendowo im Archiv des Quellcodes, solche configs haben dort aber unterschiedliche Namen jedoch immer ein "config" enthalten. Benötigt wird die Konfiguration beim Kompilieren im Hauptverzeichnis des Quellcodes als ".config" also als versteckte Datei.

Modulparameter weiterhin gibt es eine aus mehreren Dateien bestehenden Modul- Paramameterkonfiguration im Betriebsystem. Darin werden uA für bestimmte Module bestimmte Aliasnamen und Parameter für die Module festgelegt die beim automatischen Laden verwendet werden sollen. Da gibt es dann auch zB eine schwarze Liste mit Modulen, die nicht verwendet werden dürfen. usw. Zu dieser Konfiguration dazu zu zählen, ist uA auch die Modul-Konfiguration für die initrd.

dynamische Kernelparameter einige Kernel- und Modulparameter lassen sich während der Laufzeit des Kernel ändern. Beim Kompilieren des Kernels werde zwar Defaultwerte gesetzt, die aber im laufenden Kernel geändert werden können. Dafür gibt es wiederum System Konfigurationen und Scripte die diese beim Booten in den Kernel laden. Auslesen kannst du die aktuelle Konfiguration übrigens mit
sysctl -a

Bootparameter des Kernel Diese legen schon beim Laden des Kernels Kernelparameter und Eigenschaften des Kernels fest. Diese Konfiguration ist natürlich in der Bootkonfiguration zu finden.

igendwas ? wie zB die interne Firewall die theoretisch auch noch zu den dynamischen Kernelkonfigurationen zählt. Ähnlich könnten bestimmte kommerzielle Applikationen wie Datenbanken uÄ bestimmt auch noch in die dynamische Konfiguration eingreifen

Kernel Neukompilierung ist vom Prinzip her eine ganz triviale Angelegenheit. Sie wird im Wesentlichen vom im Kernelquelltext vorhandenen Konfigurationen für zB make gesteuert. Man benötigt nur den Quellcode und eine Konfiguration (.config) dazu. Die Konfiguration kann man auch mit mehreren Methoden aus einer alten Konfiguration neu gewinnen oder eine vorhandene Ändern, oder eine ganz neue selbst zusammenstellen. (Je mehr man dort ändern will, desto mehr Ahnung sollte man allerdings mitbringen.) Dabei müssen je nach Ausgangslage und gewünschtem Endergebniss nur 3 bis 5 make Befehle ausgeführt werden. (Endergebniss könnte dabei zum Beipiel nur das nackte Kompilieren aber auch das Installieren oder auch ein Installations-Paket sein )
Je nach Rechenleistung des Rechners (und dem Geschick des Users das Kompilieren auch mit mehr als nur einer vorhandenen CPU zu erledigen), dauert der eigentliche gesamte Kompiliervorgang eine Zigarettenpause bis mehrere Stunden. Aber Befehle braucht man dazu wie gesagt nur ganz wenige.

So und was willst du jetzt davon alles ändern, oder sichern?
Wenn du nur andere Kernels testen willst, warum installierst du diese nicht paralell dazu. dann kannst du im Bootloader auswählen welcher jetzt gestartet wird. Die Kernel und deren Module kommen sich überhaupt nicht ins Gehege solange sie unterschiedliche eindeutige Kernelnamen tragen, außer eventuelle private Kernelmodule. Beim mkinitrd solltest du dann allerdings ein bisschen aufpassen, das dann nicht jedesmal für alle Kernel die initrd neu gebaut wird.


robi

DamnNation schrieb:

Ich nich weis welche Einstellungen beim Standard SLES11 Kernel getroffen wurden und so nicht die gleichen Testbedingungen gegeben sind

Zum Vergrößern anklicken....

das läßt sich leicht regeln, Kopiere die .config-Datei deines benutzen Kernels in /boot nach /usr/src/linux/.config. Herausfinden läßt sich das mit dann solltest du als erstes ein ausführen, falls du einen neueren Kernel benutzt. Dieser vergleicht die zwischenzeitlich eingetretenen Änderungen und fragt nach ob du diese übernehmen willst? Wichtiger Hinweis:Alte Symlinks auf /usr/src/linux solltest du vorher gelöscht haben, bevor du neue anlegst.

robi schrieb:

Das ist zB die initrd und die globale Modulkonfiguration ohne die die Module nicht automatisch geladen werden können. Die Kerneldatei eventuelle config, map-Dateien und sym-Dateien sowie die initrd liegt typisch unter /boot/ die Module und alles was dazu gehört, findet man unterhalb von /boot/modules/$KERNELNAMEN.

Zum Vergrößern anklicken....

Falsch, die liegen in /lib/modules/... Das ist alles in Thomas Hertwecks Doku erklärt.

jengelh schrieb:

Falsch, die liegen in /lib/modules/... Das ist alles in Thomas Hertwecks Doku erklärt.

Zum Vergrößern anklicken....

stimm natürlich ps: ps: ps: war wohl Schreibfehler oder noch ne besserer Ausrede, ich wollte nur mal so testen, ob ihr meine Mammutbeiträge überhaupt noch durchlest

robi

robi schrieb:

stimm natürlich ps: ps: ps: war wohl Schreibfehler oder noch ne besserer Ausrede, ich wollte nur mal so testen, ob ihr meine Mammutbeiträge überhaupt noch durchlest

robi

Zum Vergrößern anklicken....

Wer deine technischen Hintergrundinformationen nicht liest ist selber schuld.